Retningslinjer for tilgjengelegheit på veven, versjon 1.0
Anbefaling frå W3C, 5. mai 1999
- Denne versjonen:
- http://huftis.org/w3c/TR/WAI-WEBCONTENT-NN-NO/wai-pageauth.html
- (rein tekst, PostScript, PDF, gzip tar-arkiv av HTML-versjonen, zip-arkiv av HTML-versjonen)
- Den nyaste engelske versjonen:
- http://www.w3.org/TR/WAI-WEBCONTENT/
- Førre engelske versjon:
- http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990324/
- Forfattarar:
- Wendy Chisholm, Trace R & D Center, University of Wisconsin – Madison
Gregg Vanderheiden, Trace R & D Center, University of Wisconsin – Madison
Ian Jacobs, W3C
Copyright © 1999 W3C (MIT, INRIA, Keio). Alle rettar reservert. Reglar angåande W3Cs ansvar, varemerke, bruk av dokumentet og programvarelisens gjeld.
Desse retningslinjene forklarar korleis ein kan gjera innhald på veven tilgjengeleg for menneske med funksjonshemmingar. Retningslinjene er berekna på innhaldsutviklarar (nettsideforfattarar og -designarar) og for utviklarar av forfattarverktøy. Hovudmålsettinga til desse retningslinjene er å fremma tilgjengelegheit, men viss du følgjer dei, vil du òg gjera innhald på veven meir tilgjengeleg for alle brukarar. Dette gjeld brukarar av forskjellige nettlesarar (f.eks. grafiske nettlesarar, talebaserte nettlesarar (basert på talesyntese og ev. -gjenkjenning) og mobiltelefonar) eller brukarar som arbeider under ulike avgrensingar (f.eks. i eit støyfullt miljø, i mørke eller overopplyste rom eller i eit handfrimiljø). Viss du følgjer desse retningslinjene vil du òg hjelpa andre med å finna informasjon på veven raskare. Retningslinjene skal ikkje avgrensa innhaldsutviklarars bruk av bilde, video og liknande, men vil heller prøva å visa korleis ein kan gjera multimediainnhald meir tilgjengeleg for eit større publikum.
Dette er eit referansedokument for prinsipp og utformingsidear som gjeld tilgjengelegheit. Det blir her drøfta visse spørsmål som gjeld internasjonalisering og mobil tilgang til informasjon, men dette dokumentet fokuserer på tilgjengelegheit. Det vil derfor ikkje detaljert omhandla saker som blir tatt opp av andre W3C-aktivitetar. For meir informasjon om slike spørsmål, sjå W3Cs side om mobil tilgang og W3Cs internasjonaliseringsside.
Dette dokumentet skal vera vera stabilt og gjev derfor ikkje spesifikk informasjon om ulike nettlesarar, og i kva grad dei støttar spesiell teknologi og tekniske løysingar. Sida til W3Cs initiativ for tilgjengelegheit på veven (WAI) gjev derimot slik informasjon (sjå [WAI-UA-SUPPORT]).
Dette dokumentet har eit vedlegg som viser alle punkta som avkryssingspunkt – sortert etter emne og prioritet. Avkryssingspunkta i vedlegget peikar til definisjonane i dette dokumentet. Emne som blir tatt opp i vedlegget er blant anna bilde, multimedia, tabellar, rammer, skjema og skript. Vedlegget finst som eit tabellbasert samandrag og som ei enkel liste.
Eit separat dokument, Tekniske løysingar for bruk av retningslinjene for tilgjengelegheit på veven, versjon 1.0 ([TECHNIQUES]), forklarar korleis ein kan ein kan laga dokument som stemmer overeins med punkta i dette dokumentet. Dette dokumentet diskuterer kvart punkt i meir detalj og gjev eksemplar på korleis ein kan bruka HTML, stilsett (CSS), integrasjon av synkronisert multimedia (SMIL) og det matematiske markeringsspråket MathML for å oppnå måla i retningslinjene.
Dokumentet inneheld òg teknikkar for dokumentvalidering og -testing, og ei oversikt over HTML-element og -attributt (og kva teknikkar som brukar dei). Det har blitt laga for å følgja med endringar i teknologi og vil derfor sannsynlegvis bli oppdatert relativt ofte. Obs. Ikkje alle nettlesarar eller multimediaverktøy støttar alle funksjonane nemnt i desse retningslinjene. Spesielt gjeld dette nye funksjonar i HTML 4.0, CSS 1 og CSS 2.
Retningslinjer for tilgjengelegheit på veven, versjon 1.0 er del av ein serie av retningslinjer for tilgjengelegheit, publisert av W3Cs initiativ for tilgjengelegheit på veven. Denne serien inkluderer òg Retningslinjer for tilgjengelegheit i nettlesarar ([WAI-USERAGENT]) og Retningslinjer for tilgjengelegheit i forfattarverktøy ([WAI-AUTOOLS]).
Dette dokumentet har blitt gjennomgått av medlemmar av W3C og andre interesserte grupper, og har blitt tildelt status som ei W3C-anbefaling. Det er eit stabilt dokument og kan bli brukt som referansemateriale eller sitert som ein normativ referanse frå andre dokument (dette gjeld den engelske versjonen). W3Cs oppgåve er å skapa merksemd om spesifikasjonen og fremma hans bruk. Dette forbetrar funksjonalitet og allmenn bruk av resursar på veven.
Merk at den engelske versjonen av dette dokumentet er den einaste normative versjonen. For ei omsetjing til andre språk, sjå http://www.w3.org/WAI/GL/WAI-WEBCONTENT-TRANSLATIONS.
Ei liste over feil i dette dokumentet kan du finna på http://www.w3.org/WAI/GL/WAI-WEBCONTENT-ERRATA (dette gjeld den engelske versjonen). Eventuelle feil i dette dokumentet kan meldast til wai-wcag-editor@w3.org.
Du kan finna ei liste over anbefalingar og andre tekniske dokument frå W3C på http://www.w3.org/TR/.
Dette dokumentet har blitt produsert som ein del av W3Cs initiativ for tilgjengelegheit på veven. Målsetjinga til arbeidsgruppa for desse retningslinjene blir diskutert i gruppas formålsbeskriving.
Oversikta over avkryssingspunkt er finst som både ein tabell og ei lita liste.
Viss du ikkje er kjent med problem i samband med tilgjengelegheit og utforming av nettsider, bør du vera merksam på at mange brukarar kanskje arbeider under heilt andre forhold enn deg:
- Det er ikkje sikkert dei kan sjå, høyra, røra seg eller kan oppfatta all informasjon så lett, eller i det heile tatt.
- Dei kan ha vanskar med å lesa eller forstå tekst.
- Dei kan kanskje ikkje bruka tastatur eller mus.
- Dei kan ha ein tekstbasert skjerm, ein liten skjerm, eller sein tilgang til Internett.
- Dei snakkar eller forstår kanskje ikkje språket som dokumentet er skriven i.
- Dei kan vera i ein situasjon der augo, øyrene eller hendene deira er opptatt (f.eks. viss dei kjører bil eller arbeider i eit miljø med mykje støy).
- Dei har kanskje ein gammal versjon av ein nettlesar, ein annan nettlesar enn deg, ein talebasert nettlesar eller eit anna operativsystem.
Innhaldsutviklarar må vera merksam på desse ulike situasjonane når dei utformer nettsider. Kvart val du gjer ved utforminga vil ofte hjelpa fleire grupper samtidig, og alle brukarar av veven generelt. For eksempel vil du, ved å bruka stilsett for å kontrollera skriftstilar, kunna unngå bruk av FONT-elementet. Dette vil føra til at du som HTML-forfattar får meir kontroll over sidene, sidene blir meir tilgjengelege til folk med nedsett syn, og ved å dela stilsettet mellom fleire sider vil du ofte kunna få kortare nedlastingstid for alle brukarar.
Retningslinjene diskuterer spørsmål relatert til tilgjengelegheit og gjev løysingar på utformingsproblem. Dei tar opp ulike situasjonar (som eksemplet ovanfor) som kan føra til problem for brukarar med ulike funksjonsvanskar. For eksempel forklarar den første retningslinja korleis innhaldsutviklarar kan gjera bilde meir tilgjengelege. Nokre brukarar kan kanskje ikkje sjå alle bildene, mens andre brukar tekstbaserte nettlesarar som ikkje støttar bilder. Andre igjen, kan ha slått av støtte for bilder (f.eks. på grunn av sein tilgang til Internett). Retningslinjene seier ikkje at ein skal unngå bilde for å forbetra tilgjenglegheita. Dei forklarar heller korleis å gje tekstalternativ til bildene vil gjera dei meir tilgjengelege.
Korleis gjer eit tekstalternativ bildet meir tilgjengeleg? Det viktige er her at alternativet skal vera ekvivalent:
- Innhaldet i teksten kan presenterast til brukaren som talesyntese, blindeskrift eller visuell tekst. Kvar av desse tre måtane brukar ein eigen sans: hørsla ved talesyntese, følesansen på blindeskrift og synet for visuell tekst. Dette gjer informasjonen tilgjengeleg for ulike grupper med funksjonshemmingar.
- For å vera nyttig må teksten formidla same funksjon eller meining som bildet. Eit eksempel er eit fotografi av jorda sett frå verdsrommet. Viss bildet er mest meint som dekorasjon, kan tekstalternativet vera «Fotografi av jorda – sett frå verdsrommet». Viss føremålet til fotografiet er å illustrera spesiell informasjon om jordas geografi, bør tekstalternativet gjenspeila dette. Viss bildet har blitt laga for at brukaren skal kunna velja det (f.eks. ved å klikka på det) for å få meir informasjon om jorda, kan tekstalternativet vera «Informasjon om jorda». Teksten kan altså sjåast på som ekvivalent viss han formidlar same funksjon eller meining til ein brukar med funksjonshemmingar som til andre.
Merk at i tillegg til å hjelpa brukarar med funksjonshemmingar, kan tekstalternativ hjelpa alle brukarar med å finna sidene raskare, sidan søkemotorar kan indeksera bildeteksten òg.
Mens utviklarar av innhald på veven må gje tekstalternativ til bilde og anna multimediainnhald, er det ansvaret til nettlesarane (f.eks. visuelle nettlesarar og hjelpemiddel som skjermlesarar og leselist) å presentera informasjonen til brukaren.
Ikkje-tekstlege alternativ til tekst (f.eks. ikon, tale innspelt på førehand eller eit filmklipp av ein person som omset teksten til teiknspråk) kan gjera dokumenta tilgjengelege til menneske som kan ha problem med å oppfatta tekst. Dette kan vera menneske med kognitive vanskar, lærevanskar eller menneske som er døve. Ikkje-tekstlege alternativ til tekst kan òg vera til hjelp for ikkje-lesarar. Ei talebasert beskriving er eit eksempel på eit ikkje-tekstleg alternativ til visuell informasjon. Ei talebasert beskriving av ein multimediapresentasjons visuelle del kan vera til nytte for folk som ikkje kan sjå denne.
Retningslinjene tar føre seg to hovudtema: å gjera stilfull transformering muleg og å gjera innhaldet forståeleg og lett å finna fram i.
Ved å følgja desse retningslinjene kan innhaldsutviklarar laga sider som kan transformerast stilfullt. Det vil seia at dei forblir tilgjengelege på tross av eventuelle avgrensingar, nemnt i innleiinga. Dette inkluderer fysiske funksjonshemmingar, problem med å oppfatta eller forstå informasjon, avgrensingar i arbeidsmiljøet og teknologiske hinder. Her er nokre metodar som viser korleis du kan utforma sider som blir stilfullt transformert:
- Skil mellom struktur og presentasjon (sjå forskjellen mellom innhald, struktur og presentasjon).
- Hugs å ta med tekst (inkludert tekstalternativ). Teksten kan bli framstilt på måtar som er tilgjengelege i nesten alle nettlesar og for alle brukarar.
- Lag dokument som verkar sjølv om brukaren ikkje kan sjå og/eller høyra. Ta med informasjon som har same føremål eller funksjon som lyd, bilde eller film på måtar som passar til alternative sansekanalar. Dette tyder ikkje at du må laga ei førehandsinnspelt lydfil av ein heil nettstad for å gjera den tilgjengeleg for blinde brukarar. Brukarar som er blinde kan bruka skjermlesarar til å lesa all tekstinformasjon på ei side.
- Lag dokument som ikkje er avhengig av ein spesiell type maskinvare. Sidene bør kunna brukast av menneske utan hjelp av mus, med små skjermar, skjermar med låg oppløysing, svart/kvit-skjermar, ingen skjermar, med berre tale eller vising av tekst osv.
Du kan lesa meir om korleis du kan skapa stilfulle transformeringar i retningslinje 1 til 11.
Innhaldsutviklarar bør gjera innhaldet forståeleg og lett å finna fram i. Dette kan ordnast ved å gjera språket klart og enkelt, men òg ved å gjera det enkelt og forståeleg å navigera i og mellom sider. Ved å ha lettforståelege navigasjonsverktøy og orienteringsinformasjon på sidene vil du maksimera tilgjengelegheita deira og gjera dei lettare å bruka.
Ikkje alle brukarar har nytte av visuelle effektar som bildekart, proporsjonale rullefelt, sidestilte rammer eller grafikk som hjelper sjåande som har grafiske nettlesarar. Brukarar kan òg mista kontekstuell informasjon når dei berre ser ein del av ei side, enten fordi dei berre har tilgang til eit ord om gongen (ved talesyntese eller bruk av leselist), eller ein del av sida om gongen (liten skjerm eller forstørra skjermbilde). Utan orienteringsinformasjon kan brukarar få problem med å forstå veldig store tabellar, lister, menyar osv.
Du kan lesa meir om korleis du kan gjera innhaldet forståeleg og lett å finna fram i i retningslinje 12 til 14.
Dette dokumentet inneheld fjorten retningslinjer eller generelle prinsipp som gjeld utforming av sider slik at dei blir mest muleg tilgjengelege. Kvar retningslinje inneheld:
- Retningslinjas nummer.
- Kva retningslinja gjeld.
- Navigasjonslenkjer for retningslinja. Tre lenkjer gjer det muleg å enkelt flytta seg til neste retningslinje (høgrepilsikon), førre retningslinja (venstrepilsikon) eller den aktuelle retningslinjas plass i innhaldslista (oppilsikon).
- Forklaringa av retningslinja, og oversikt kva brukarar som vil ha nytte av du følgjer ho.
- Ei liste over punkt, med definisjonar.
Definisjonane av punkta i kvar retningslinje forklarar korleis kvar retningslinja kan brukast i ein typisk utviklingssituasjon. Kvar punktdefinisjon inneheld:
- Punktets nummer.
- Kva punktet gjeld.
- Kva prioritet punktet har. Punkt med prioritet 1 er spesielt markert ved bruk av stilsett.
- Eventuelle notat, eksempel og kryssreferansar til andre retningslinjer eller punkt.
- Ei lenkje til ein del av dokumentet som tek opp tekniske løysingar ([TECHNIQUES]) der kvar implementasjon og kvart eksempel blir gjennomgått.
Kvart punkt er meint å vera spesifikk nok til at nokon som går gjennom ei nettside eller ein nettstad kan stadfesta eller avkrefta at punktet har blitt følgt.
I dette dokumentet er det brukt følgjande skrivemåtar:
- Elementnamn blir skrivne med store bokstavar (versalar).
- Attributtnamn står i hermeteikn med små bokstavar.
- Lenkjer til definisjonar blir spesielt markert ved bruk av stilsett.
Kvart punkt har eit prioriteringsnivå basert på kor mykje det påverkar tilgjengelegheita.
- [Prioritet 1]
- Ein utviklar av innhald på veven må følgja dette punktet. Viss ikkje vil ein eller fleire grupper finna det umuleg å få tilgang til informasjon i dokumentet. Å følgja dette punktet er eit minstekrav for at nokre grupper skal kunna bruka dokumentet.
- [Prioritet 2]
- Ein utviklarar av innhald på veven bør følgja dette punktet. Viss ikkje vil ei eller fleire grupper få problem med å få tilgang til informasjonen i dokumentet. Viss du følgjer dette punktet vil du fjerna vesentlege hinder for tilgang til informasjonen i dokumentet.
- [Prioritet 3]
- Ein utviklarar av innhald på veven kan følgja dette punktet. Viss ikkje kan ei eller fleire grupper få enkelte vanskar med å få tilgang til informasjonen i dokumentet. Viss du følgjer dette punktet vil du forbetra tilgangen til dokumentet.
Nokre punkt spesifiserer eit prioriteringsnivå som kan endra seg under visse (markerte) forhold.
Denne delen definerer tre ulike nivå eit dokument kan samsvara med retningslinjene på:
- Nivå «A»: Alle punkt med prioritet 1 er følgde.
- Nivå «Dobbel-A»: Alle punkt med prioritet 1 eller 2 er følgde.
- Nivå «Trippel-A»: Alle punkt med prioritet 1, 2 eller 3 er følgde.
Obs. Nivåa blir skriven som tekst for at dei skal kunna bli forstått ved bruk av f.eks. eit talesynteseprogram.
Viss du angjev at eit dokumentet følgjer retningslinjene i dette dokumentet skal dette bli opplyst om på ein av desse to måtane.
Måte 1: Spesifiser:
- Tittelen til retningslinjene: Web Content Accessibility Guidelines 1.0.
- URI-en til retningslinjene: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/.
- Nivået: «A», «Dobbel-A» eller «Trippel-A».
- Kva som blir dekka av retningslinjene (f.eks. nettsida, heile nettstaden eller ein spesiell del av nettstaden).
Eksempel på måte 1:
Denne sida oppfyller krava i W3Cs Web Content Accessibility Guidelines 1.0, tilgjengeleg frå http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/, nivå «Dobbel-A».
Måte 2: Ha eit av dei tre ikona frå W3C på kvar side som følgjer retningslinjene, og kopl desse til W3C-forklaringa av nivået. Informasjon om ikona og korleis du legg dei inn på sidene dine er finn du på [WCAG-ICONS].
Sjølv om mange menneske ikkje kan bruka bilde, filmklipp, lyd, applettar e.l. direkte, kan dei likevel bruka sider som har ekvivalent informasjon til dette. Denne informasjon må ha same funksjon som lyden eller det visuelle innhaldet. Derfor kan eit tekstalternativ til eit bilde av ei pil som peikar oppover og som er kopla til ei innhaldsliste vera «Innhaldsliste» eller «Gå til innhaldslista». I nokre tilfelle kan det òg vera føremålsmessig å beskriva korleis det visuelle innhaldet ser ut (f.eks. for grafar eller diagram) eller høyrest ut (f.eks. for lydopptak brukt i undervisning).
Retningslinjene legg vekt på at du må gje tekstalternativ til ikkje-tekstleig innhald (bilde, lyd, filmklipp). Styrken til slike tekstalternativ ligg i deira allsidigheit. Det vil seia at dei kan bli brukt av menneske med ulike typar funksjonshemmingar, og som brukar ulik teknologi. Teksten kan bli lest opp av talesynteseprogram og framstilt på ei leselist. Han kan òg bli vist visuelt (i ulike skriftstorleikar) på dataskjermar og òg på vanleg papir. Talesyntese er særs viktig for menneske som er blinde eller har lesevanskar som ofte kjem av vanskar med å forstå, lærevanskar eller på grunn av døvleik. Blindeskrift (oftast braille) er viktig for folk som er både blind og døv, men òg for mange som berre er blind. Tekst vist visuelt er til nytte for brukarar som er døv, såvell som dei fleste andre vevbrukarar.
Å gje ikkje-tekstlege alternativ (f.eks. bilde, filmklipp og førehandsinnspelt lyd/tale) til tekst er òg til nytte for nokre brukarar. Dette gjeld spesielt dei som ikkje kan eller som har problem med å lesa. I filmar og visuelle presentasjonar har ofte kroppsspråk og anna visuell informasjon ikkje nok lyd til fullt ut å formidla same informasjon. Viss ikkje muntlege beskrivingar av dette blir gjeven, vil ikkje folk som ikkje kan sjå (eller sjå på) det visuelle innhaldet kunna oppfatta det.
- 1.1 Ha alltid ekvivalente tekstalternativ til kvart ikkje-tekstlege element (f.eks. ved å bruka «alt»- og «longdesc»-attributtet). Dette gjeld: bilde, grafiske representasjonar av tekst (inkludert symbol), bildekart og spesielle områder på desse, animasjonar (f.eks. animerte GIF-filer), applettar og andre programobjekt, ASCII-kunst, rammer, skript, bilde brukt som punktmerke, plasshaldarar, grafiske knappar, lydar (spelt med eller utan påverknad av brukaren), separate lydfiler, filmklipp og lydspor til filmklipp. [Prioritet 1]
- For eksempel, i HTML:
- Bruk «alt»-attributtet på IMG-, INPUT- og APPLET-elementa, eller gje tekstalternativ i innhaldet til OBJECT- og APPLET-elementa.
- For komplekst innhald (f.eks. ein graf) der «alt»-teksten ikkje fullt ut kan erstatt objektet, bør du gje ekstra beskriving, f.eks. gjennom bruk av «longdesc» på IMG og FRAME, ei lenkje inne i OBJECT-elementet eller ei beskrivingslenkje.
- For bildekart bør du enten bruka «alt»-attributtet på AREA eller bruka MAP-elementet med A-element (og annan tekst) som innhald.
Sjå òg punkt 9.1 og 13.10.
- Tekniske løysingar for punkt 1.1
- 1.2 Inkluder overflødige tekstlenkjer til kvart aktivt område på tenarbaserte bildekart. [Prioritet 1]
- Sjå òg punkt 1.5 og 9.1.
- Tekniske løysingar for punkt 1.2
- 1.3 Til nettlesarar automatisk kan lesa høgt tekstalternativa til ein visuell presentasjon bør du inkludera ei lydbeskriving av det visuelle innhaldet i multimediapresentasjonen. [Prioritet 1]
- Synkroniser lydbeskrivinga med lydsporet som nemnt i punkt 1.4. Sjå punkt 1.1 for informasjon om tekstalternativ til visuell informasjon.
- Tekniske løysingar for punkt 1.3
- 1.4 For tidsstyrte multimediapresentasjonar (f.eks. ein film eller animasjon), bør du synkronisera ekvivalente alternativ (f.eks. undertekster eller lydbeskriving av det visuelle innhaldet) til presentasjonen. [Prioritet 1]
- Tekniske løysingar for punkt 1.4
- 1.5 Til nettlesarar kan framstilla tekstalternativ til klientbaserte bildekart, bør du inkludera overflødige tekstlenkjer til kvart aktivt område av bildekartet. [Prioritet 3]
- Sjå òg punkt 1.2 og 9.1.
- Tekniske løysingar for punkt 1.5
Viss du berre brukar ulike fargar til å formidla informasjon, vil ikkje alle kunna motta informasjonen. Dette gjeld menneske som ikkje kan skilja mellom visse fargar og brukarar av maskiner som ikkje har fargeskjerm eller som har ikkje-visuell framstilling av data. Viss for- og bakgrunnsfargane er for nær kvarandre vil dei ikkje kunna gje nok kontrast når dei blir vist på svart/kvit-skjerm eller for folk som er fargeblinde (av ulik grad).
- 2.1 Sørg for at all informasjon som blir formidla ved bruk av farge også er tilgjengeleg utan, f.eks. frå samanhengen eller gjennom markeringa. [Prioritet 1]
- Tekniske løysingar for punkt 2.1
- 2.2 Sørg for at forgrunns- og bakgrunnsfargekombinasjonen gjer nok kontrast viss den blir sett av fargeblinde eller på ein svart/kvit-skjerm. [Prioritet 2 for bilde, prioritet 3 for tekst].
- Tekniske løysingar for punkt 2.2
Ved å bruka HTML feil – altså ikkje etter spesifikasjonen – vil du øydeleggja for tilgjengelegheita. Å misbruka HTML-markering for å få ein spesiell presentasjonseffekt (f.eks. ved bruk av tabellar til å kontrollera utsjånaden eller ei overskrift for å endra skriftstorleiken) vil gjera det vanskeleg for brukarar med spesialprogramvare å forstå korleis sida er bygd opp og korleis ein kan navigera gjennom ho. I tillegg vil det å bruka presentasjonselement i staden for strukturelement for å formidla strukturen (f.eks.. å laga noko som ser ut som ein tabell ved bruk av PRE-elementet) gjera det vanskeleg å visa ei side korrekt på andre maskiner/nettlesarar. For meir informasjon, sjå beskrivinga av forskjellen mellom innhald, struktur og presentasjon).
Innhaldsutviklarar kan bli freista til å bruka (eller misbruka) løysingar som gjev ein spesiell effekt på eldre nettlesarar. Dei må vera klar over at dette fører til (kanskje kraftig) redusert tilgjengelegheit og må vurdera om effekten er så nødvendig at det er verdt å gjera dokumentet utilgjengeleg for nokre brukarar.
På den andre sida må ikkje innhaldsutviklarar ofra korrekt markering på grunn av at visse nettlesarar eller støtteteknologi ikkje viser dette skikkeleg. For eksempel vil det vera riktig å bruka TABLE-elementet i HTML til å merka opp tabellbasert informasjon, sjølv om nokre eldre skjermlesarar ikkje taklar dette skikkeleg (sjå punkt 10.3). Ved å bruka TABLE korrekt og ved å laga tabellar som transformerast stilfullt (sjå retningslinje 5) gjer du det muleg for programvare å framstilla tabellar på andre måtar ein som todimensjonale rutenett.
- 3.1 Når eit passande markeringsspråk eksisterar bør du bruka dette i staden for bilde til å formidla informasjonen. [Prioritet 2]
- Eit eksempel er å bruka MathML til å presentera matematiske likningar og stilsett til å formatera tekst og kontrollera utsjånad. Du bør òg unngå å bruka bilde til å framstilla tekst – bruk heller tekst og stilsett. Sjå òg retningslinje 6 og 11.
- Tekniske løysingar for punkt 3.1
- 3.2 Lag dokument som kan validerast etter formelle, publiserte validerte dokumentkodingssystem. [Prioritet 2]
- Du bør for eksempel inkludera ein deklarasjon av kva dokumenttype eit dokument høyrer til under i begynnelsen av dokumentet. Ein slik deklarasjon viser til ein publisert DTD (f.eks.. DTD-en til «HTML 4.0 Strict»).
- Tekniske løysingar for punkt 3.2
- 3.3 Bruk stilsett til å kontrollera utsjånad og presentasjon. [Prioritet 2]
- Bruk «font»-eigenskapen i CSS og ikkje FONT-elementet i HTML til å kontrollera skriftstilar.
- Tekniske løysingar for punkt 3.3
- 3.4 Bruk relative og ikkje absolutte einingar til attributt- og eigenskapsverdiar. [Prioritet 2]
- For eksempel bør du bruka «em» eller prosentverdiar i CSS, i staden for å punkt («pt») eller centimeter («cm») som er absolutte einingar. Viss du må bruka absolutte einingar bør du sjå etter at innhaldet er brukbart (sjå validering).
- Tekniske løysingar for punkt 3.4
- 3.5 Bruk overskriftselement til å formidla dokumentstrukturen og bruk dei slik det står i spesifikasjonen. [Prioritet 2]
- I HTML bør du for eksempel bruka H2 til å visa at det er ein underseksjon av H1. Ikkje bruk overskriftselement for å få ein viss visuell effekt (f.eks.. for å endra skriftstorleiken).
- Tekniske løysingar for punkt 3.5
- 3.6 Marker lister og punkt korrekt. [Prioritet 2]
- I HTML bør du bruka OL-, UL-, and DL-elementa til å laga lister. Det er då viktig at desse er plassert korrekt under kvarandre.
- Tekniske løysingar for punkt 3.6
- 3.7 Merk opp sitat. Ikkje bruk sitat-element for å få formateringseffektar som til dømes innrykk. [Prioritet 2]
- I HTML bør du for eksempel bruka Q- og BLOCKQUOTE-elementa til å merka opp respektivt korte og lengre sitat.
- Tekniske løysingar for punkt 3.7
Når innhaldsutviklarar markerer endringar i språket i eit dokument, kan talesynteseprogram og leselister automatisk bytta til det nye språket. Dette er med på gjera dokumentet meir tilgjengeleg til fleirspråklege brukarar. Innhaldsutviklarar bør spesifisera kva for eit naturleg språk som er hovudspråket i dokumentet (gjennom markering eller HTTP-startblokker). Innhaldsutviklarar bør òg inkludera utvidingar av akronym og forkortingar.
I tillegg til å hjelpa brukarar av spesialprogramvare (f.eks.. talesynteseprogram), vil spesifisering av språk også gjera det muleg for søkemotorar å finna nøkkelord og identifisera språket i dokument. Det gjer det lettare for alle brukarar av veven, inkludert menneske med lærevanskar eller som er døve.
Når forkortingar og endringar i språket ikkje blir angjeven kan dei bli uforståeleg i talesynteseprogram eller ved bruk av leselist.
- 4.1 Angje tydeleg endringar i språket til dokumentteksten og i eventuelle tekstalternativ (f.eks.. bildetekster). [Prioritet 1]
- Du kan i HTML bruka «lang»-attributtet til dette. I XML brukar du «xml:lang».
- Tekniske løysingar for punkt 4.1
- 4.2 Spesifiser den utvida forma av kvar forkorting og kvart akronym i eit dokument første gong det kjem. [Prioritet 3]
- I HTML kan du bruka «title»-attributtet på ABBR- og ACRONYM-elementa. Å angje den utvida forma i hovudteksten vil òg hjelpa tilgjengelegheita.
- Tekniske løysingar for punkt 4.2
- 4.3 Angje hovudspråket i eit dokument. [Prioritet 3]
- I HTML kan du bruka «lang»-attributtet på HTML-elementet. I XML kan du bruka «xml:lang». Driftsansvarlege for vevtenarar bør konfigurera desse til å bruka HTTPs mekanismar for innhaldsforhandling ([RFC2068], seksjon 14.13) så klientprogram automatisk kan henta dokumenta i det språket brukaren føretrekk.
- Tekniske løysingar for punkt 4.3
Tabellar skal berre brukast til å merka opp tabellbasert informasjon (datatabellar). Innhaldsutviklarar bør unngå å bruka dei til grafisk utforming av sider (formgjevingstabellar). Uansett korleis tabellar blir brukt, vil dei skapa problem for brukarar av skjermlesarar (sjå punkt 10.3).
Nokre nettlesarar gjer det muleg for brukarar å forflytta seg mellom tabellceller og få tilgang til informasjon frå overskriftsceller. Viss tabellane ikkje er skikkeleg markert vi dei ikkje gje nettlesarane nok og passande informasjon (sjå òg retningslinje 3).
Dei følgjande punkta vil direkte hjelpa menneske som får tilgang til ein tabell gjennom lyd (f.eks.. ein skjermlesar eller ei datamaskin i bil) eller som berre ser ein del av sida om gongen (f.eks.. blinde brukarar, brukarar med nedsett syn som brukar talesyntese eller leselist eller brukarar med små skjermar).
- 5.1 Marker rad- og kolonneoverskrifter i datatabellar. [Prioritet 1]
- I HTML kan du bruka TD til å identifisera dataceller og TH til å markera overskriftsceller.
- Tekniske løysingar for punkt 5.1
- 5.2 Viss du har datatabellar som har to eller fleire logiske nivå med rad- og kolonneoverskrifter bør du bruka markering til å kopla datacellene med overskriftscellene. [Prioritet 1]
- I HTML kan du bruka THEAD, TFOOT og TBODY til å gruppera rader og COL og COLGROUP til å gruppera kolonner. Du bør òg bruka «axis»-, «scope»- og «headers»-attributta til å bekskriva meir komplekse forhold mellom data.
- Tekniske løysingar for punkt 5.2
- 5.3 Ikkje bruk tabellar til grafisk utforming viss ikkje tabellen kan lesast lineært. Viss dette ikkje er muleg bør du gje eit ekvivalent alternativ (som kan vera ein lineær versjon av tabellen). [Prioritet 2]
- Obs. Når nettlesarar støttar plassering via stilsett, bør ikkje tabellar bli brukt til grafisk utforming. Sjå òg punkt 3.3.
- Tekniske løysingar for punkt 5.3
- 5.4 Viss ein tabell blir brukt slik må du ikkje bruka strukturell markering for å oppnå ein viss utsjånad. [Prioritet 2]
- I HTML skal du ikkje bruka TH-elementet for å visa innhaldet av ei vanleg datacelle midtstilt og halvfeit.
- Tekniske løysingar for punkt 5.4
- 5.5 Ha med samandrag av tabellar. [Prioritet 3]
- I HTML kan du bruka «summary»-attributtet på TABLE-elementet.
- Tekniske løysingar for punkt 5.5
- 5.6 Ha med forkortingar av overskriftsceller. [Prioritet 3]
- Du kan bruka «abbr» på TH-elementet i HTML for å oppnå dette.
- Tekniske løysingar for punkt 5.6
Sjå òg punkt 10.3.
Sjølv om du som innhaldsutviklar absolutt bør bruka ny teknologi som løyser eksisterande problem, bør du veta korleis du kan få sidene dine til å verka med eldre nettlesarar og for folk som vel å skru av desse funksjonane.
- 6.1 Lag dokumenta slik at dei kan blir lest utan stilsett. Når eit HTML-dokument blir vist utan noko tilhøyrande stilsett må det framleis vera muleg å lesa og fullt ut forstå dokumentet. [Prioritet 1]
- Når innhaldet er logisk strukturert vil det bli vist på ein meiningsfull måte sjølv når tilhøyrande stilsett ikkje blir brukt (er deaktivert eller ikkje støtta).
- Tekniske løysingar for punkt 6.1
- 6.2 Sørg for at alternativ til dynamisk innhald blir oppdatert når det dynamiske innhaldet blir endra. [Prioritet 1]
- Tekniske løysingar for punkt 6.2
- 6.3 Sørg for at sider er fullt ut brukbare når skript, applettar eller andre programobjekt ikkje er støtta eller støtta er deaktivert. Viss dette ikkje er muleg må du ha ei alternativ side med alternativ, ekvivalent informasjon. [Prioritet 1]
- Du må for eksempel sørgja for at lenkjer som utløyser skript verkar når dette ikkje er støtta eller når støtta er deaktivert (bruk f.eks. ikkje «javascript:» som lenkjemål). Viss det ikkje er muleg å gjera sida brukbar utan skript, bør du ha eit tekstalternativ i NOSCRIPT-elementet eller bruka vevtenarbaserte og ikkje klientbaserte skript, eventuelt ha ei alternativ tilgjengeleg side som nemnt i punkt 11.4. Sjå òg retningslinje 1.
- Tekniske løysingar for punkt 6.3
- 6.4 For skript og applettar må du sjå til at hendingsaktivatorar er uavhengig av maskin- og programvare. [Prioritet 2]
- Sjå definisjonen av maskinvareuavhengig.
- Tekniske løysingar for punkt 6.4
- 6.5 Sørg for at dynamisk innhald er tilgjengeleg eller inkluder ein alternativ presentasjon eller side. [Prioritet 2]
- I HTML kan du bruka på NOFRAMES i slutten av kvart rammesett. For nokre program kan vevtenarbaserte skript vera meir tilgjengelege enn kilentbaserte.
- Tekniske løysingar for punkt 6.5
Sjå òg punkt 11.4.
Nokre menneske med kognitive eller visuelle funksjonshemmingar kan ha problem med å lesa tekst som rørar seg. Rørsle kan òg føra til slik distraksjon at resten av sida blir uleseleg for menneske med kognitive funksjonshemmingar. Skjermlesarar kan ikkje lesa tekst som rører seg. Menneske med fysiske funksjonshemmingar kan ha problem med å røra seg raskt eller nøyaktig nok til å bruka bevegelege objekt på nettsider.
Obs. Alle desse punkta inneber at innhaldsutviklaren har ansvar for at dei fungerer til nettlesarar har gode nok funksjonar for kontroll av dette.
- 7.1 Til nettlesarar gjer det muleg for brukarar å styra flimring må du unngå å få skjermen til å flimra. [Prioritet 1]
- Obs. Menneske med fotosensitiv epilepsi kan få anfall utløyst av flimring eller blinking med frekvensar frå 4 til 59 blink i sekund (Hertz) med eit toppnivå på 20 Hz. Også raske overgangar frå mørke til lys kan føra til anfall.
- Tekniske løysingar for punkt 7.1
- 7.2 Til nettlesarar gjer det muleg for brukarar å kontrollera blinking bør du unngå å få innhaldet til å blinka (f.eks.. ved å endra visinga av eit objekt regelmessig ved å slå den av og på). [Prioritet 2]
- Tekniske løysingar for punkt 7.2
- 7.3 Til nettlesarar gjer det muleg for brukarar å stoppa rørsle av innhald bør du unngå slik rørsle. [Prioritet 2]
- Når ei side har rørleg innhald bør du ha ein mekanisme i eit skript eller i ein applett til å la brukarar stoppa rørsla eller oppdateringa. Ved å bruka stilsett saman med skript til å laga rørsle kan det vera lettare for brukarar å stoppa rørsla. Sjå òg retningslinje 8.
- Tekniske løysingar for punkt 7.3
- 7.4 Til nettlesarar gjer det muleg å stoppa automatiske oppdateringar bør du ikkje ha sider som oppdaterer seg automatisk. [Prioritet 2]
- For eksempel bør du – så lenge det ikkje er muleg for brukarar å slå av dette – ikkje bruka «http-equiv="refresh"» til å få sider til å oppdatera seg automatisk.
- Tekniske løysingar for punkt 7.4
- 7.5 Til nettlesarar gjer det muleg å stoppa automatisk omadressering bør du ikkje bruka markering for automatisk å omadressera sidene. Konfigurer heller vevtenaren til å føreta omadresseringa. [Prioritet 2]
- Tekniske løysingar for punkt 7.5
Obs. BLINK- og MARQUEE-elementa er ikkje definert i nokon HTML-spesifikasjon frå W3C og bør såleis ikkje bli brukt. Sjå òg retningslinje 11.
Når eit innebygd objekt har sitt eiga brukargrensesnitt må dette vera tilgjengeleg for alle. Viss dette ikkje er muleg må alternative, tilgjengelege løysingar vera inkludert.
Obs. For informasjon om tilgjengelege brukargrensesnitt, sjå Retningslinjer for tilgjengelegheit i nettlesarar ([WAI-USERAGENT]) og Retningslinjer for tilgjengelegheit i forfattarverktøy ([WAI-AUTOOL]).
- 8.1 Programobjekt som f.eks. skript og applettar må vera direkte tilgjengelege eller kompatible med tillleggsprogram [Prioritet 1 viss funksjonaliteten er viktig og ikkje finst andre plassar, elles prioritet 2.]
- Sjå òg retningslinje 6.
- Tekniske løysingar for punkt 8.1
Maskinvareuavhengig tilgang tyder at brukaren kan bruka nettlesaren eller dokumentet ved hjelp av den inneinga som han har valt. Dette kan vera mus, tastatur, talegjenkjenning eller anna. Viss for eksempel eit skjemafelt berre kan aktiverast ved bruk av mus eller annan peikereiskap, vil ikkje ein blind person som brukar talegjenkjenning, tastatur e.l. kunna bruka skjemaet.
Obs. Viss du har tekstalternativ til bildekart eller bilde brukt som lenkjer er det muleg for brukarar å bruka desse utan noko peikereiskap. Sjå òg retningslinje 1.
Generelt sett kan sider som kan brukast ved hjelp av tastatur også brukast ved hjelp av talegjenkjenningsprogram eller tekstgrensesnitt.
- 9.1 Ha klientbaserte bildekart i staden for vevtenarbaserte så lenge områdene kan definerast med tilgjengelege geometriske former. [Prioritet 1]
- Sjå òg punkt 1.1, 1.2, og 1.5.
- Tekniske løysingar for punkt 9.1
- 9.2 Sjå til at alle objekt som har sitt eiga brukargrensesnitt kan bli brukt maskinvareuavhengig. [Prioritet 2]
- Sjå definisjonen av maskinvareuavhengig.
- Sjå òg retningslinje 8.
- Tekniske løysingar for punkt 9.2
- 9.3 I skript bør du spesifisera logiske hendingsaktivatorar og ikkje maskinvareavhengige. [Prioritet 2]
- Tekniske løysingar for punkt 9.3
- 9.4 Ha ei naturleg rekkjefølgje på lenkjer, skjemaelement og andre objekt. [Prioritet 3]
- I HTML kan du spesifisera den naturlege rekkjefølgja på visse element ved hjelp av «tabindex»-attributtet.
- Tekniske løysingar for punkt 9.4
- 9.5 Ha hurtigtastar på viktige lenkjer (inkludert dei i klientbaserte bildekart), skjemaelement og grupper med desse. [Prioritet 3]
- I HTML kan du spesifisera hurtigtastar ved å bruka «accesskey»-attributtet.
- Tekniske løysingar for punkt 9.5
For eksempel vil mange eldre nettlesarar ikkje la brukaren gå til tomme skjemafelt. Eldre skjermlesarar les lenkjelister som ei lenkje. Desse aktive elementa er derfor vanskelege eller umulege å få tilgang til. Å endra det aktive vindauget eller automatisk opna nye vindauge kan òg vera veldig forstyrrande og forvirrande for brukarar som ikkje kan sjå dette.
Obs. Dei følgjande punkta gjeld berre til nettlesarar (inkludert støtteteknologi) kan handtera dessa problema. Desse punkta blir rekna som «overgangsløysingar», noko som tyder at arbeidsgruppa for desse retningslinjene såg på dei som gyldige og nødvendige for tilgjengelegheita når dette dokumentet vart laga. Arbeidsgruppa reknar derimot ikkje med at desse punkta blir nødvendige i framtida når teknologien er forbetra òg innehald støtte for dette.
- 10.1 Til nettlesarar gjer det muleg for brukaren å skru av automatisk opna vindauge, bør du ikkje få dette til å skje utan å informera brukaren. [Prioritet 2]
- I HTML bør du unngå å bruka ei ramme som har eit nytt vindauge som mål.
- Tekniske løysingar for punkt 10.1
- 10.2 Til nettlesarar støttar eksplisitt samanheng mellom etikettar og skjemaelement bør du la alle etikettar som er implisitt knytta til skjemaelement vera korrekt plasserte. [Prioritet 2]
- Etiketten må stå rett framfor skjemaelement og på same linje (noko som tillet meir en eitt skjemalement og ein etikett på kvar linje) eller vera på linja framfor skjemalementet (med berre ein etikett og eitt skjemafelt per linje). Sjå òg punkt 12.4.
- Tekniske løysingar for punkt 10.2
- 10.3 Til nettlesarar (inkludert støtteteknologi) viser sidestilt tekst korrekt bør du lineære tekstalternativ (på same eller annan side) til alle tabellar som viser sidestilt tekst i fleire kolonner. [Prioritet 3]
- Obs. Sjå definisjonen av lineær tabell. Dette punktet hjelper folk med nettlesarar (som f.eks. ein skjermlesar) som ikkje kan handtera sidestilte tekstblokker. Punktet ber ikkje innhaldsutviklarar å la vera å bruka tabellar til tabellbasert informasjon.
- Tekniske løysingar for punkt 10.3
- 10.4 Til nettlesarar kan handtera tomme skjemaelement korrekt bør du ha standardverdiar som plasshaldarar til desse. [Prioritet 3]
- I HTML kan du ha dette i TEXTAREA- og INPUT-element.
- Tekniske løysingar for punkt 10.4
- 10.5 Til nettlesarar (inkludert støtteteknologi) kan visa etterfølgjande lenkjer korrekt bør du ha ekstra, visbare teikn mellom lenkjer. [Prioritet 3]
- Tekniske løysingar for punkt 10.5
Desse retningslinjene anbefaler W3C-teknologi (f.eks.. HTML, CSS osv.) av fleire grunnar:
- W3C-teknologi har «innebygde» funksjonar for tilgjengelegheit.
- W3C-spesifikasjonane blir gjennomgått tidleg av andre slik at spørsmål som har med tilgjengelegheit å gjera blir behandla tidleg i utformingsfasen.
- W3C-spesifikasjonane blir utvikla gjennom ein open prosess.
Mange format som ikkje blir utvikla av W3C (f.eks.. PDF, Shockwave) krev at ein installerer innpluggingsmodular eller nye program. Oftast kan ikkje desse formata visast i vanlege nettlesarar (inkludert støtteteknologi). Unngå funksjonar som ikkje finst i standardar frå W3C (nettlesarspesifikke element, attributt, eigenskapar og funksjonar) då desse vil føra til at sidene blir mindre tilgjengelege for brukarar med ulik maskin- og programvare. Når teknikkar som hindrar tilgjengelegheita må bli brukt (enten den er programvarespesifikk eller ei) så må du også inkludera alternative, ekvivalente sider.
Sjølv når teknologi frå W3C blir brukt, må han bli brukt slik han er spesifisert i desse retningslinjene. Når du brukar ny teknologi må du sørgja for at dei kan transformerast stilfullt (sjå òg retningslinje 6.).
Obs. Når du konverterer dokument (frå PDF, PostScript, RTF eller andre format) til markeringsspråk frå W3C (HTML, XML) vil du ikkje alltid få eit tilgjengeleg dokument. Du bør derfor validera alle sidene etter konverteringa (sjå validering). Viss ei side ikkje kan konverterast lett, bør du enten endra sida slik at originalversjonen kan konverterast skikkeleg eller ha ein ekstra versjon i HTML eller rein tekst.
- 11.1 Bruk W3C-teknologi når dei er tilgjengelege og høver for ei oppgåve. Bruk òg den nyaste versjonen når denne er støtta. [Prioritet 2]
- Sjå referanselista for informasjon om kor du kan kan finna dei siste W3C-spesifikasjonane og [WAI-UA-SUPPORT] for informasjon om støtte for W3C-teknologi i nettlesarar.
- Tekniske løysingar for punkt 11.1
- 11.2 Unngå nedgraderte funksjonar i W3C-teknologi. [Prioritet 2]
- I HTML bør du ikkje bruka det nedgraderte FONT-elementet. Bruk heller stilsett (f.eks.. «font»-eigenskapen i CSS).
- Tekniske løysingar for punkt 11.2
- 11.3 Inkluder informasjon slik at brukarar kan motta dokument etter deira preferansar (f.eks.. språk og innhaldstype). [Prioritet 3]
- Obs. Bruk innhaldsforhandling der det er muleg.
- Tekniske løysingar for punkt 11.3
- 11.4 Viss du, etter å ha gjort så godt du kan, ikkje kan laga ei tilgjengeleg side, bør du inkludera ei lenkje til ei alternativ side som brukar W3C-teknologi, er tilgjengeleg og har ekvivalent informasjon (eller funksjonalitet) og blir oppdatert like ofte som den utilgjengelege originalsida. [Prioritet 1]
- Tekniske løysingar for punkt 11.4
Obs. Innhaldsutviklarar bør berre ty til alternative sider når andre løysingar ikkje kan brukast. Dette er fordi alternative sider oftast ikkje blir oppdatert så ofte som «hovudsidene». Ei side som ikkje er oppdatert kan vera like frustrerande som ei som er utilgjengeleg sidan informasjonen på originalsida i begge tilfelle ikkje er tilgjengeleg. Automatisk genererte alternative sider kan føra til oftare oppdatering, men innhaldsutviklarar må likevel passa på at desse sidene fungerer skikkeleg og at brukarar kan forflytta seg mellom ein nettstad ved å følgja lenkjer på hovudsidene, dei alternative sidene eller begge. Før ein bør ty til alternative sider bør utforminga av originalsida tenkjast nøye gjennom. Å gjera den tilgjengeleg vil sannsynlegvis gjera den betre for alle brukarar.
Å gruppera element og gje informasjon om korleis ulike element høyrer saman kan vera nyttig for alle brukarar. Komplekse forhold mellom delar av ei side kan vera vanskeleg for menneske med kognitive eller visuelle funksjonshemmingar å forstå og fatta.
- 12.1 Gje kvar ramme ein eigen tittel for å gjera det lettare å identifisera og forflytta seg mellom dei. [Prioritet 1]
- I HTML kan du bruka «title»-attributtet på FRAME-element.
- Tekniske løysingar for punkt 12.1
- 12.2 Beskriv meininga til rammer og korleis dei høyrer saman viss dette ikkje kan lesast ut frå rammetittelen. [Prioritet 2]
- I HTML kan du bruka «longdesc»-attributtet eller ei beskrivingslenkje.
- Tekniske løysingar for punkt 12.2
- 12.3 Del stor mengder informasjon i mindre delar der dette er naturleg. [Prioritet 2]
- I HTML kan du bruka OPTGROUP til å gruppera OPTION-element inni eit SELECT-element. Du kan òg gruppera skjemfelt med FIELDSET- og LEGEND-elementa. Bruk lister inne i kvarandre når dette passar seg og overskrifter for å strukturera dokument. Sjå òg retningslinje 3.
- Tekniske løysingar for punkt 12.3
- 12.4 Knytt etikettar eksplisitt til skjemafelta dei høyrer til. [Prioritet 2]
- I HTML kan du bruka LABEL-elementet og «for»-attributtet på dette.
- Tekniske løysingar for punkt 12.4
Klare og konsistente navigasjonsmekanismar er viktige for folk med kognitive vanskar eller blinde, og vil hjelpa alle brukarar.
- 13.1 Gjer slik at målet til ei lenkje er tydeleg. [Prioritet 2]
- Lenkjetekster bør vera slik at dei kan bli forstått når dei blir lest ut av samanhengen – enten åleine eller som ein del av ei lenkjeliste. Lenkjeteksten bør òg vera kort og konsis.
- I HTML bør du skriva «Informasjon om versjon 4.3» i staden for «klikk her». I tillegg til klare lenkjetekster kan innhaldsutviklarar gjera lenkjemålet endå meir tydelegt ved å bruk ein lenkjetittel (f.eks.. «title»-attributtet i HTML).
- Tekniske løysingar for punkt 13.1
- 13.2 Inkluder metadata for å gje semantisk informasjon om sider og nettstader. [Prioritet 2]
- Du kan bruka RDF ([RDF]) for å inkludera namnet til forfattaren av dokument, dokumenttypen osv.
- Obs. Nokre nettlesarar for HTML kan bygga opp navigasjonsverktøy basert på dokumentrelasjonar definert av LINK-elementet og «rel»- og «rev»-attributta (f.eks.. rel="next", rel="previous" og rel="index"). Sjå òg punkt 13.5.
- Tekniske løysingar for punkt 13.2
- 13.3 Inkluder informasjon om korleis nettstaden er utforma (f.eks.. eit kart over nettstaden eller ei innhaldsliste). [Prioritet 2]
- Når du forklarar korleis nettstaden er utforma bør du spesielt nemna og forklara funksjonar som gjer han tilgjengeleg.
- Tekniske løysingar for punkt 13.3
- 13.4 Bruk navigasjonsmekanismar konsistent. [Prioritet 2]
- Tekniske løysingar for punkt 13.4
- 13.5 Inkluder navigasjonsstriper for å gje enkel tilgang til navigasjonsmekanismar. [Prioritet 3]
- Tekniske løysingar for punkt 13.5
- 13.6 Grupper relaterte lenkjer, identifiser gruppene (for nettlesarar) og til nettlesarar kan gjera dette bør du ha ein måte å overstyra grupperinga. [Prioritet 3]
- Tekniske løysingar for punkt 13.6
- 13.7 Viss du har søkefunksjonar på sidene bør det kunne vera muleg å føreta ulike typar søk (av meir eller mindre avansert grad) og etter sine eigne preferansar. [Prioritet 3]
- Tekniske løysingar for punkt 13.7
- 13.8 Ha særskilt viktig informasjon i begynnelsen av overskrifter, avsnitt, lister osv. [Prioritet 3]
- Obs. Dette er spesielt nyttig for menneske som får tilgang til informasjonen sekvensielt – f.eks. brukarar av talesynteseprogram.
- Tekniske løysingar for punkt 13.8
- 13.9 Inkluder informasjon om dokumentsamlingar (dokument som består av fleire sider). [Prioritet 3]
- I HTML kan du spesifisera dokumentsamlingar ved å bruka LINK-elemetet saman med «rel» og «rev»-attributta. Ein annan måte å laga slike samlingar er å laga eit arkiv (f.eks.. med zip, tar og gzip eller stuffit) som inneheld sidene.
- Obs. Det kan bli mykje billigare for menneske med funksjonshemmingar som les sakte dersom sidene kan lastast ned og visast fråkopla.
- Tekniske løysingar for punkt 13.9
- 13.10 Inkluder ein måte å hoppa over ASCII-kunst på fleire linjer. [Prioritet 3]
- Sjå punkt 1.1 og eksemplet på ASCII-kunst i ordforklaringa.
- Tekniske løysingar for punkt 13.10
Konsistent formgjeving av sidene, gjenkjenneleg grafikk og eit språk som er lett å forstå vil hjelpa alle brukarar. Spesielt vil det vera til nytte for menneske med kognitive vanskar eller som har lesevanskar. (Hugs likevel å ha tekstalternativ, slik at menneske som er blinde, har nedsett syn eller som av ein annan grunn ikkje kan sjå grafikken (enten dette er frivillig eller ei) likevel kan få tilgang til informasjonen. Sjå òg retningslinje 1.)
Bruk eit klart og enkelt språk som gjer kommunikasjonen betre. Tilgang til skriven informasjon kan vera vanskeleg for menneske som har ulike funksjonshemmingar. Ved å bruka eit klart og enkelt språk hjelper du òg dei som ikkje har same morsmål som deg, inkludert dei som kommuniserer med teiknspråk.
- 14.1 Bruk det klaraste og enklaste språket som høver til nettstadens innhald. [Prioritet 1]
- Tekniske løysingar for punkt 14.1
- 14.2 Inkluder ekstra tekst, grafikk eller lyd for å gjera innhaldet lettare å forstå. [Prioritet 3]
- Sjå òg retningslinje 1.
- Tekniske løysingar for punkt 14.2
- 14.3 Bruk ein presentasjon som er konsistent gjennom alle sidene på ein nettstad. [Prioritet 3]
- Tekniske løysingar for punkt 14.3
Valider tilgjengelegheita med automatiske verktøy og gjennomgang av ein person. Automatiske metodar er oftast raske og enkle, men kan ikkje oppdaga alle problem som har med tilgjengelegheit å gjera. Gjennomgang av andre kan medverka til at språket blir klarare og lettare å forstå, og at sida blir lettare å navigera.
Begynn å bruka valideringsmetodar så tidleg som muleg. Jo tidlegare problem med tilgjengelegheita kan oppdagast, desto lettare er dei å løysa og å unngå seinare.
Her følgjer nokre viktige valideringsmetodar, vidare diskutert i dokumentet med tekniske løysingar, validering.
- Bruk eit verktøy som undersøkjer om eit dokument er tilgjengeleg og korleis dokumentet vil fungere i ulike nettlesarar. Merk at desse verktøya ikkje kan kontrollera alle problem som har med tilgjengelegheit å gjera, som f.eks. meiningsfulle lenkjetekster eller passande tekstalternativ.
- Valider syntaksen (f.eks.. HTML og XML).
- Valider stilsett (f.eks.. CSS).
- Bruk ein tekstbasert nettlesar eller emulator.
- Bruk fleire grafiske nettlesarar, med ulike innstillingar:
- lyd og bilde
- ingen vising av bilde
- ingen framstilling av lyd
- uten mus
- uten rammer, skript, stilsett og applettar
- Bruk fleire nettlesarar, både gamle og nyare.
- Bruk ein talesyntesenettlesar, ein skjermlesar, ein skjermforstørrar, ein liten skjerm osv.
- Bruk stave- og grammatikkontroll. Ein person som får sida lest opp av eit talesynteseprogram kan ha store vanskar med å forstå feilstava ord som ikkje finst i programmets innebygde ordliste. Ved å fjerna grammatikkfeil vil du auka forståinga.
- Les gjennom dokumentet for å kontrollera kor lettlest det er. Lesbarheitsstatistikkar som kan lagast av ulike tekstbehandlingsprogram kan vera nyttig indikatorar på dette. Det er likevel betre å la eit erfare menneske gå gjennom dokumentet. Ein korrekturlesar kan òg hjelpa til med å oppdaga potensielle kulturelle problem som kan oppstå ved spesiell språkbruk o.l.
- La menneske med funksjonshemmingar lesa gjennom dokumenta. Dei kan gje verdifull tilbakemelding på kor tilgjengelege og brukbare dokumenta er for slike.
- Applett
- Eit programobjekt som er innebygd i ei nettside.
- ASCII-kunst
- ASCII-kunst er teikn og bokstavar som blir brukt til å laga eit bilde. For eksempel er ;-) eit emotikon (også kalla ein fjesing eller smiley). Dette er eit eksempel på ein ASCII-teikning som viser forholdet mellom blinkingsfrekvens og samantrekningar hos pasientar med åpne og lukka auge [hopp over ASCII-teikninga eller les ei beskriving av ho]:
% __ __ __ __ __ __ __ __ __ __ __ __ __ __
100 | * |
90 | * * |
80 | * * |
70 | @ * |
60 | @ * |
50 | * @ * |
40 | @ * |
30 | * @ @ @ * |
20 | |
10 | @ @ @ @ @ |
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70
Blinkingsfrekvens (Hertz)
- Bakoverkompatibel
- Utforming som framleis vil verka med tidlegare versjonar av eit språk, program e.l.
- Bilde
- Ein grafisk presentasjon.
- Bildekart
- Eit bilde som har handlingar kopla til ulike område på bildet. Ved å klikka på eit område vil ei handling bli utført.
- Når ein brukar klikkar på eit aktivt område av eit klientbasert bildekart vil nettlesaren sjå kva område brukaren klikka på og så følgja lenkja som høyrer til dette området. Når ein brukar klikkar på eit område på eit vevtenarbasert bildekart blir koordinatane til der brukaren klikka sendt til ein vevtenar, som så utfører ei handling.
- Innhaldsutviklarar kan gjera klientbaserte bildekart tilgjengelege ved laga maskin- og programvareuavhengig tilgang til lenkjene som høyrer til dei ulike områda på bildekartet. Klientbaserte bildekart gjer det muleg for brukaren å få direkte melding om peikaren er over eit aktivt område (som kan veljast).
- Blindeskrift
- Braille er ei blindeskrift brukar seks opphøgde punkt i ulike mønster for å representera bokstavar og tal. Desse kan følast av blinde som brukar fingertuppane til å lesa. Ordet «Accessible» i ser slik ut i braille:
- Ei leselist hever og senkar punktmønster etter elektriske signal, oftast frå ei datamaskin. Resultatet er ei tekstlinje blindeskrift som kan endrast frå ein augneblink til ein annan. Dei vanlegaste leselister har mellom ei celle (seks eller åtte punkt) til åtti celler på ei linje. Dei fleste har mellom tolv og tjue celler på kvar linje.
- Dynamisk HTML (DHTML)
- DHTML er eit marknadsføringsuttrykk for ein blanding av standardar, inkludert HTML, stilsett, dokumentobjektsmodellen [DOM1] og skriptspråk. Det finst likevel ingen W3C-spesifikasjon som definerer DHTML. Dei fleste retningslinjene i dette dokument kan passa til sider som brukar DHTML, men spesielt retningslinje 1, 3, 6, 7 og 9 fokuserer på problem som gjeld bruk av skript og stilsett.
- Ekvivalent
- Eit innhaldet er ekvivalent til eit anna innhald viss begge har same funksjon og meining når dei blir presentert til brukaren. Når det gjeld ordet ekvivalent som brukt i dette dokumentet må det ekvivalente alternativet ha same funksjon for ein person med ei funksjonshemming (så langt dette er muleg, avhengig av funksjonshemminga og tilgjengeleg teknologi) som hovudinnhaldet har for ein person utan nokon funksjonshemming. Teksten «Fullmåne» kan gje same informasjon som eit bilde av ein fullmåne presentert til brukaren. Merk at ekvivalent informasjon fokuserer på å ha same funksjon. Viss bildet er del av ei lenkje og ein må forstå bildet for å skjønna kor lenkja fører må tekstalternativet òg gje brukaren informasjon om dette. Å ha alternativ, ekvivalent informasjon til utilgjengeleg innhald er ein av dei viktigaste teknikkane innhaldsutviklarar kan gjera dokumenta meir tilgjengelege til menneske med funksjonshemmingar.
- Eit ekvivalent alternativ kan ha ei beskriving av innhaldet (f.eks.. korleis innhaldet ser eller høyrest ut). For at brukarar skal kunna forstå informasjonen formilda av eit diagram bør forfattaren beskriva den visuelle informasjonen i diagrammet.
- Sidan teksten kan presenterast til brukaren som f.eks. tale, blindeskrift eller vanleg, visuell tekst krev desse retningslinjene ekvivalente tekstalternativ til alt grafisk innhald og lyd. Tekstalternativa må vera skriven slik at dei formidlar alt det viktige innhaldet. Ikkje-tekstlege alternativ (f.eks.. ikon, førehandsinnspelt tale eller eit filmklipp av ein person som omset teksten til teiknspråk) er òg med på å forbetra tilgjengelegheita for menneske som ikkje kan få tilgang til skriven tekst eller annan visuelle informasjon. Dette gjeld blant anna blinde, menneske med kognitive vanskar, lærevanskar og menneske som er døve.
- Ekvivalent informasjon kan inkluderast på fleire måtar: gjennom bruk av spesielle attributt (f.eks.. tekstverdien til «alt»-attributtet i HTML og SMIL), som ein del av elementinnhaldet (f.eks.. i OBJECT-elementet i HTML), som ein del av teksten eller i eit eksternt dokument (som brukaren kan få tilgang til ved bruk av f.eks. «longdesc»-attributtet i HTML eller ei beskrivingslenkje). Det kan vera nødvendig å kombinera fleire teknikkar (f.eks.. å bruka «alt» for ei kort beskriving for å brukarar som kjenner til innhaldet frå før av og «longdesc» for ei lenkje til meir detaljert og komplett informasjon, for brukarar som les innhaldet for første gang). Meir informasjon om korleis og når ein skal laga ekvivalent informasjon finn du i dokumentet med tekniske løysingar ([TECHNIQUES]).
- Ei tekstavskrift er eit tekstalternativ til lydinformasjon (tale og ulike lydeffektar). Ein undertekst er ei tekstavskrift av lydsporet som er synkronisert med filmen og lyden. Undertekster blir oftast vist grafisk over filmen, noko som hjelper menneske som er døve, har nedsett høyrsel eller ikkje kan høyra lyden av andre grunnar. Ei beskrivande tekstavskrift kombinerar undertekster med beskrivingar av filminformasjon (beskrivingar av handlingar, kroppsspråk, grafikk og sceneendringar på filmsporet). Desse tekstalternativ gjer presentasjonen meir tilgjengeleg til menneske som er både blinde og døve og menneske som ikkje kan køyra film, animasjon o.l. Informasjonen blir òg tilgjengeleg til søkemotorar.
- Eit eksempel på eit ikkje-tekstleg ekvivalent alternativ er ei lydbeskriving av dei vesentlege elementa til ein presentasjonen. Beskrivinga er enten ein førehandsinnspelt stemme eller ein stemme generert av eit talesynteseprogram (enten førehandsinnspelt eller genrert i sanntid). Lydbeskrivinga blir synkronisert med lydsporet til presentasjonen, oftast til naturlege pausar og opphald i lydsporet. Eksempel på lydbeskrivingar er informasjon om handlingar, kroppsspråk, grafikk og sceneendringar.
- Element
- Dettte dokumentet brukar uttrykket «element» både etter SGML-definisjonen (eit element er ein sytakskonstruksjon) og meir generelt om ein type innhald (som video eller lyd) eller ein logisk konstruksjon (f.eks.. ei overskrift eller ei liste). Den andre definisjonen legg vekt på at ei retningslinje som er inspirert av HTML òg kan brukast om og gjelda andre språk.
- Merk at nokre element har innhald som blir vist (f.eks.. P-, LI- og TABLE-elementa i HTML), nokre blir erstatta av innhald som hentast utanfrå (f.eks.. IMG-elementet) og nokre har berre noko å seia for dokumentbehandlinga (f.eks.. vil STYLE- og SCRIPT-elementa føra til at informasjonen blir behandla som eit stilsett eller av ein skriptmotor). Eit element som gjer at tekst (bokstavar, tal og andre teikn) blir vist som ein del av dokumentet blir kalla eit tekstelement.
- Forfattarverktøy
- Redigeringsprogram for HTML, konverteringsverktøy og programvare som genererer nettsider basert på databasar er alle forfattarverktøy. Sjå Retningslinjer for tilgjengelegheit i forfattarverktøy ([WAI-AUTOOLS]) for informasjon om korleis ein kan utvikla tilgjengelege forfattarverktøy.
- Innhald, struktur og presentasjon
- Med innhaldet i eit dokument meiner me det dokumentet fortel gjennom språk, bilde, lydar, filmklipp, animasjonar o.l. Strukturen til eit dokument er korleis det er organisert (f.eks.. inndelt i kapittel, med ei innleiing og ei innhaldsliste). Eit element (f.eks.. P, STRONG eller BLOCKQUOTE i HTML) som markerer ein viss struktur kallar me eit strukturelement. Presentasjonen av eit dokument er korleis dokumentet blir framstilt (f.eks.. som ei utskrift, som ein todimensjonal grafiske presentasjon, ein tekstbasert presentasjon, tale eller blindeskrift). Eit element som spesifiserer ein viss presentasjon av eit dokument (f.eks.. B, FONT eller CENTER) kallar me eit presentasjonselement.
- Eit eksempel på skilnaden mellom desse er ei overskrift. Innhaldet er kva overskrifta seier (f.eks.. «seilbåtar»). I HTML er overskrifta eit strukturelt element som ein kan markera med f.eks. H2-elementet. Presentasjonen av overskrifta kan vera eit stykke halvfeit skrift i margen, ei midtstilt linje tekst eller ein tittel som blir lest med ein spesiell stemme (som ein stemmefont).
- Innhaldsutviklar
- Ein som utviklar nettsider eller nettstader.
- Maskinvareuavhengig
- Ein brukar må kunna bruka ein nettlesarar (og dokumentet denne viser) med sine foretrukne ut- og inneiningar. Eksempel på inneiningar er tastatur, blindeskrifttastatur, utstyr for kontrollering av maskiner ved hjelp av hovudet, andre peikereiskapar og mikrofonar. Eksempel på uteiningar er dataskjermar, talesynteseprogram og leselist.
- Merk at støtte for maskinvareuavhengnad ikkje tyder at ein nettlesar må støtta alle mulege typar inn- og uteiningar. Men om nettlesaren har støtte for både mus og tastatur skal brukaren kunna bruka alle funksjonane i nettlesaren med ein av desse.
- Nedgradert
- Eit nedgradert element eller attributt har blitt forelda på grunn av nyare teknologi. Nedgraderte element kan forsvinna heilt i nyare versjonar av HTML. Oversikta over element og attributt i HTML i dokumentet med tekniske løysingar viser kva element og attributt som er nedgraderte i HTML 4.0.
- Forfattarar bør unngå å bruka nedgraderte element og attributt. Nettlesarar bør likevel fortsetta å støtta desse, grunna bakoverkompatibilitet.
- Lenkjetekst
- Tekstinnhaldet til ei lenkje (blir vist direkte i dokumentet).
- Lineær tabell
- Ein lineær tabelle er når innhaldet i cellene blir vist som ein serie avsnitt (f.eks.. nedover sida). Avsnitta vil vera i same rekkjefølgje som cellene er definert i dokumentkjelda. Det skal vera muleg å forstå cellene når dei blir lest i rekkjefølgje og dei bør innehalda strukturelement (som lagar avsnitt, overskrifter, lister osv.). Då er sida brukbar sjølv når tabellane blir vist lineært.
- Naturleg språk
- Eit språk som blir lest, skriven eller uttrykt på annan måte. Eksempel er fransk, japansk, amerikansk teiknspråk og blindeskrift. Det naturlege språket kan definerast ved bruk av «lang»-attributtet i HTML ([HTML40], 8.1) og «xml:lang»-attributtet i XML ([XML], 2.12).
- Navigasjonsmekanismar
- Ein navigasjonsmekanisme er noko brukaren kan navigera ei nettside eller ein nettstad med. Typiske eksempel på dette er:
- navigasjonsstripe
- Ei navigasjonsstripe er ei samling lenkjer til viktige delar av eit dokument eller ein nettstad.
- kart over nettstaden
- Eit kart over nettstaden gjer eit godt overblikk over korleis han er oppbygd og organisert.
- innhaldsliste
- Ei innhaldsliste har oversikt over (og lenkjer til) dei viktigaste delane av eit dokument.
- Nettlesar
- Programvare som blir brukt til å få tilgang til innhald på veven. Dette inkluderer grafiske nettlesarar, tekst- og talebaserte nettlesarar, mobiltelefonar, multimediaspelarar, innpluggingsmodular og programvarebasert støtteteknologi brukt i samband med nettlesarar (f.eks.. skjermlesarar, skjermforstørrar og talegjenkjenningsprogramvare).
- Personleg, digital assistent (PDA)
- Ein PDA er ei lita, bærbar datamaskin. Dei fleste PDA-ar blir brukt til å halda orden på personlege data og inneheld ofte kalendar, kontaktliste og mulegheit for elektronisk post. PDA-ar er vanlegvis små handheldte maskiner med små skjermar. Du kan bruka maskinene med fleire innieingar som f.eks. elektronisk penn eller tastatur.
- Skjermforstørrar
- Eit program som forstørrar delar av ein skjerm slik at denne blir lettare å sjå. Skjermforstørrar blir oftast brukt av menneske med nedsett syn.
- Skjermlesar
- Eit program som blir brukt til å lesa opp skjerminnhaldet til brukaren ved bruk av talesyntese. Skjermlesarar blir oftast brukt av menneske som er blinde. Skjermlesarar kan vanlegvis berre lesa reint tekst og ikkje tekst som grafikk.
- Stilsett
- Eit stilsett består av eit sett stilreglar som spesifiserer presentasjonen av eit dokument. Stilsett kan koplast til dokument på tre forskjellige måtar. Dei kan vera skriven av nettsideforfattaren, av brukaren eller dei kan vera innebygd i nettlesaren. I CSS ([CSS2]) blir samhandlinga mellom stilsett frå utviklaren, brukaren og innebygd i nettlesaren definert av noko som kallast kaskaden.
- Presentasjonsmarkering er markering som oppnår ein stilistisk (og ikkje strukturell) effekt. Eksempel er B- og I-elementa i HTML. Merk at STRONG- og EM-elementa ikkje er presentasjonsmarkering då formidlar informasjon som er uavhengig av presentasjonen.
- Støtteteknologi
- Program- eller maskinvare som er spesiallaga for å hjelpa menneske med funksjonshemmingar til å utføra ulike aktivitetar. Dette kan vera rullestolar, maskiner for tekstlesing eller andre hjelpemiddel for handikappa. Når det gjeld tilgjengelegheit på veven er eksempel på ofte brukt støtteprogramvare skjermlesarar, skjermforstørrarar, talesyntese- og talegjenkjenningsprogram som fungerer saman med grafiske nettlesarar. Maskinvare for dette formålet kan vera spesialtastatur og anna utstyr for å styra skjermpeikaren/-markøren.
- Tabellbasert informasjon
- Når tabellar blir brukt til å presentera logiske forhold mellom data – tekst, tal, bilde osv. – blir informasjonen kalla «tabellbasert» og tabellane «datatabellar». Dette forholdet kan bli framstilt grafisk (oftast som eit todimensjonalt rutenett), som lyd (ofte blir innhaldet i overskriftcellene lest før kvar datacelle) eller i andre format.
- Til nettlesarar …
- I dei fleste punkta blir innhaldsutviklarar bedt om å sørgja for at sidene deira er tilgjengelege. Der finst likevel ting som har med tilgjengelegheit å gjera som er avhengige av nettlesarar (inkludert støtteteknologi). Når dette dokument var ferdig kunne mange nettlesarar og støtteteknologi ikkje handtera alle funksjonar for tilgjengelegheit som brukarar har behov for (f.eks. er det ikkje muleg å slå av blinkande tekst i alle nettlesarar og nokre skjermlesarar har problem med tabellar). Punkt som inneheld uttrykket «til nettlesarar …» krev at innhaldsutviklarar må sørgja for ekstra støtte for tilgjengelegheit. Dette gjeld til dei fleste nettlesarane som er tilgjengelege for brukarane av sidene inneheld nødvendige funksjonar for tilgjengelegheit.
- Obs. W3Cs sider om tilgjengelegheit (sjå [WAI-UA-SUPPORT]) gjev informasjon om graden av støtta for tilgjengelegheit i ulike nettlesarar. Innhaldsutiklarar bør regelmessig sjå på denne sida for oppdatert informasjon om dette.
- tilgjengeleg
- Innhaldet er tilgjengeleg når det kan bli brukt av folk med ulik grad av funksjonshemmingar.
- Viktig
- Informasjonen i eit dokument er viktig viss det er nødvendig å forstå informasjonen for å forstå sjølve innhaldet dokumentet.
- Leiarar for arbeidsgruppa for desse retningslinjene:
- Chuck Letourneau, Starling Access Services
- Gregg Vanderheiden, Trace Research and Development
- Kontaktar på W3C:
- Judy Brewer og Daniel Dardailler
- Me ønskjer å takka desse menneska som har medverka til å skapa desse retningslinjene med tid og verdifulle kommentarar:
- Harvey Bingham, Kevin Carey, Chetz Colwell, Neal Ewers, Geoff Freed, Al Gilman, Larry Goldberg, Jon Gunderson, Eric Hansen, Phill Jenkins, Leonard Kasday, George Kerscher, Marja-Riitta Koivunen, Josh Krieger, Scott Luebking, William Loughborough, Murray Maloney, Charles McCathieNevile, MegaZone (Livingston Enterprises), Masafumi Nakane, Mark Novak, Charles Oppermann, Mike Paciello, David Pawson, Michael Pieper, Greg Rosmaita, Liam Quinn, Dave Raggett, T.V. Raman, Robert Savellis, Jutta Treviranus, Steve Tyler, Jaap van Lelieveld og Jason White
Førsteutkastet til dette dokumentet er basert på The Unified Web Site Accessibility Guidelines ([UWSAG]) som er samansett av Trace R & D-senteret på Wisconsin-universitetet. I det dokumentet vil du finna ei liste over andre bidragsytarar.
For ei liste over dei nyaste versjonane av W3C-spesifikasjonar, sjå W3Cs tekniske rapportar.
- [CSS1]
- CSS, level 1 Recommendation, B. Bos, H. Wium Lie, red., 17. desember 1996, revidert 11. jaunuar 1999. CSS1-anbefalinga finst på adressa: http://www.w3.org/TR/1999/REC-CSS1-19990111.
Den nyaste utgåva av CSS1 er tilgjengeleg frå: http://www.w3.org/TR/REC-CSS1/.
- [CSS2]
- CSS, level 2 Recommendation, B. Bos, H. Wium Lie, C. Lilley, and I. Jacobs, red., 12. mai 1998. CSS2-anbefaling finst på adressa: http://www.w3.org/TR/1998/REC-CSS2-19980512/.
Den nyaste utgåva er tilgjengeleg frå: http://www.w3.org/TR/CSS2/.
- [DOM1]
- Document Object Model (DOM) Level 1 Specification, V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, and L. Wood, red., 1. oktober 1998. DOM Level 1-anbefalinga finst på adressa: http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/.
Den nyaste utgåva er tilgjengeleg frå: http://www.w3.org/TR/REC-DOM-Level-1/
- [HTML40]
- HTML 4.0 Recommendation, D. Raggett, A. Le Hors, og I. Jacobs, red., 17. desember 1997, revidert 24. april 1998. HTML 4.0-anbefalinga finst på adressa: http://www.w3.org/TR/1998/REC-html40-19980424.
Den nyaste utgåva er tilgjengeleg frå: http://www.w3.org/TR/REC-html40/.
- [HTML32]
- HTML 3.2 Recommendation, D. Raggett, red., 14. januar 1997. Den nyaste utgåva finst på adressa: http://www.w3.org/TR/REC-html32.
- [MATHML]
- Mathematical Markup Language, P. Ion and R. Miner, red., 7. april 1998. MathML 1.0-anbefalinga finst på: http://www.w3.org/TR/1998/REC-MathML-19980407/.
Den nyaste utgåva er tilgjengeleg frå: http://www.w3.org/TR/REC-MathML/.
- [PNG]
- PNG (Portable Network Graphics) Specification, T. Boutell, red., bidrag frå T. Lane, 1. oktober 1996. Den nyaste utgåva er tilgjengeleg frå: http://www.w3.org/TR/PNG/.
- [RDF]
- Resource Description Framework (RDF) Model and Syntax Specification, O. Lassila, R. Swick, red., 22. februar 1999. RDF-anbefaling finst på adressa: http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/.
Den nyaste utgåva er tilgjengeleg frå: http://www.w3.org/TR/REC-rdf-syntax/
- [RFC2068]
- HTTP Version 1.1, R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen og T. Berners-Lee, januar 1997.
- [SMIL]
- Synchronized Multimedia Integration Language (SMIL) 1.0 Specification, P. Hoschka, red., 15. juni 1998. SMIL 1.0-anbefalinga finst på adressa: http://www.w3.org/TR/1998/REC-smil-19980615/
Den nyaste utgåva er tilgjengeleg frå: http://www.w3.org/TR/REC-smil/
- [TECHNIQUES]
- Techniques for Web Content Accessibility Guidelines 1.0, W. Chisholm, G. Vanderheiden, I. Jacobs, red. Dette dokumentet forklarar korleis ein kan utføra punkta definert i dette dokumentet. Den nyaste utgåva av dokumentet finst på adressa: http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/
- [WAI-AUTOOLS]
- Authoring Tool Accessibility Guidelines, J. Treviranus, J. Richards, I. Jacobs, C. McCathieNevile, red. Det siste utkastet til desse retningslinjene som forklarar korleis ein kan laga tilgjengelege forfattarverktøy finst på adressa: http://www.w3.org/TR/WAI-AUTOOLS/
- [WAI-UA-SUPPORT]
- Dette dokumentet fortel om i kor stor grad nettlesarar (inkludert støtteteknologi) har støtte for funksjonane for tilgjengelegheit som er nemnt i dette dokumentet. Sida er tilgjengeleg på: http://www.w3.org/WAI/Resources/WAI-UA-Support
- [WAI-USERAGENT]
- User Agent Accessibility Guidelines, J. Gunderson and I. Jacobs, red. Det nyaste utkastet til desse retningslinjene for korleis ein kan laga tilgjengelege nettlesarar finst på adressa: http://www.w3.org/TR/WAI-USERAGENT/
- [WCAG-ICONS]
- Informasjon om ikon du kan bruka for å visa at sidene er tilgjengelege som spesifisert i dette dokument er tilgjengelege på adressa: http://www.w3.org/WAI/WCAG1-Conformance.html
- [UWSAG]
- The Unified Web Site Accessibility Guidelines, G. Vanderheiden, W. Chisholm, red. Desse retningslinjene vart sett saman av Trace R & D-senteret på Wisconsin-universitetet etter finansiering frå National Institute on Disability and Rehabilitation Research (NIDRR), U.S. Dept. of Education. Dette dokumentet er tilgjengeleg frå adressa: http://trace.wisc.edu/redirects/htmlgide/version8.htm
- [XML]
- Extensible Markup Language (XML) 1.0., T. Bray, J. Paoli, C.M. Sperberg-McQueen, red., 10. februar 1998. XML 1.0-anbefalinga finst på adressa: http://www.w3.org/TR/1998/REC-xml-19980210.
Den nyaste utgåva er tilgjengeleg frå: http://www.w3.org/TR/REC-xml/
