Dit document is een Nederlandse vertaling van een Engelstalig document (http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505).

Deze vertaling is tot stand gekomen onder de verantwoordelijkheid van het W3C Kantoor Benelux. Zij is herlezen en gecorrigeerd door en van Accessibility.nl, maar kan nog enkele fouten bevatten. In geval van twijfel verwijzen wij naar de officiële Engelse versie.

Engelse versie:: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
Deze versie:: /Vertalingen/2000/WAI-WEBCONTENT/WAI-WEBCONTENT-NL.html; (platte tekst, PostScript, PDF, gzip tar file van HTML, zip archive van HTML)
Vertaler:: Miente Bakker <Miente.Bakker@cwi.nl>
Auteursrecht:: Copyright © 1999 W3C (MIT, INRIA, Keio). Alle rechten voorbehouden. W3C-regels betreffende aansprakelijkheid, handelsmerk, documentgebruik en softwarelicentiëring zijn van toepassing.

Richtlijnen voor de Toegankelijkheid van Web Content 1.0

W3C Aanbeveling 5-mei-1999

Engelse versie:: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
Deze versie:: /Vertalingen/2000/WAI-WEBCONTENT/WAI-WEBCONTENT-NL.html; (platte tekst, PostScript, PDF, gzip tar file van HTML, zip archive van HTML)
Meest recente Engelse versie:: http://www.w3.org/TR/1999/WAI-WEBCONTENT
Redactie:: Wendy Chisholm, Trace R & D Center, University of Wisconsin - Madison; Gregg Vanderheiden, Trace R & D Center, University of Wisconsin - Madison
Ian Jacobs, W3C

Samenvatting

Deze richtlijnen geven aan hoe je Webcontent toegankelijk kunt maken voor mensen met een handicap. Zij zijn bedoeld voor alle Webcontentontwikkelaars (auteurs van webpagina's en ontwerpers van websites) en voor ontwikkelaars van authoring tools. Het belangrijkste doel van deze richtlijnen is de bevordering van de toegankelijkheid. Een neveneffect zal evenwel zijn dat Webcontent meer binnen handbereik komt van alle gebruikers, ongeacht welke user agent zij gebruiken (bijvoorbeeld een desktopbrowser, een voicebrowser, een mobiele telefoon, een PC in de auto, etc.) en ongeacht de beperkingen waaronder zij werken (bijvoorbeeld lawaaierige omgeving, slecht verlichte of felverlichte ruimten, hands-free bellen, etc.). Verder zal het toepassen van deze richtlijnen gebruikers ook helpen om informatie over het Web sneller te vinden. Deze richtlijnen raden Webcontentontwikkelaars niet af om gebruik te maken van beelden, video etc., maar leggen uit hoe zij multimedia voor een breed publiek toegankelijk kunnen maken.

Dit is een handboek voor de beginselen van toegankelijkheid en voor ideeën met betrekking tot het ontwerpen. Sommige van de strategieën die hier uiteengezet worden betreffen bepaalde problemen bij de internationalisering van het Web en mobiele toegang tot het Web. De hoofdzaak van dit document is evenwel de toegankelijkheid; de bijkomende problemen van andere W3C-activiteiten worden slechts terloops besproken. Voor meer informatie raadplege men de W3C Mobile Access Activity home page en de W3C Internationalization Activity home page.

Dit document wordt geacht niet erg te veranderen en geeft daarom geen specifieke informatie over de ondersteuning van browsers voor andere technologieën, aangezien die informatie snel verandert. Deze informatie wordt daarom gegeven door de Web Accessibility Initiative (WAI) Website (zie [WAI-UA-SUPPORT]).

Dit document bevat ook een appendix die alle ijkpunten indeelt naar onderwerp en prioriteit. De ijkpunten in de appendix verwijzen naar hun definities in dit document. De onderwerpen in de appendix zijn onder meer afbeeldingen, multimedia, tabellen, frames, formulieren en scripts. De appendix is beschikbaar als tabeloverzicht van ijkpunten of als een eenvoudige lijst van ijkpunten.

Een separaat document getiteld "Technieken voor de Richtlijnen Toegankelijkheid Web Content 1.0" ([TECHNIQUES]), geeft aan hoe je de ijkpunten in dit document kunt implementeren. Dit Techniekendocument bepreekt ieder ijkpunt uitvoerig en geeft voorbeelden van het gebruik van de Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), Synchronized Multimedia Integration Language (SMIL) en de Mathematical Markup Language (MathML). In het Techniekendocument staan ook technieken voor het testen en valideren van documenten en een index van HTML-elementen en -attributen (en welke technieken er gebruik van maken). Het Techniekendocument is ontworpen om veranderingen in de technologie op te pikken en zal naar verwachting vaker worden geactualiseerd dan dit document.

NB De kans bestaat dat niet alle browsers of multimediatools de eigenschappen uit deze richtlijnen ondersteunen. In het bijzonder worden nieuwe eigenschappen van HTML 4.0, CSS 1 of CSS 2 mogelijk niet ondersteund.

"Richtlijnen voor de Toegankelijkheid van Web Content 1.0" is onderdeel van een serie richtlijnen uitgegeven door het Web Accessibility Initiative. In deze serie vindt men ook Richtlijnen voor de toegankelijkheid van User Agents ([WAI-USERAGENT]) en Richtlijnen voor de toegankelijkheid van Authoring Tools ([WAI-AUTOOLS]).

Status van dit document

Dit document is de Nederlandse vertaling van een Engelstalig document (http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505) dat is beoordeeld door leden van W3C en andere belanghebbende partijen en goedgekeurd door de directeur van W3C als Aanbeveling van W3C. Dit is een stabiel document dat kan worden gebruikt als naslagmateriaal of waaruit kan worden geciteerd als normatieve referentie vanuit andere documenten. De rol van W3C bij het opstellen van de Aanbeveling is de aandacht vestigen op de specificatie en het bevorderen van zo breed mogelijke verspreiding. Dit verbetert de functionaliteit en het universele karakter van het Web.

De Engelse versie van deze specificatie is de enige normatieve versie. Voor overige vertalingen zie http://www.w3.org/WAI/GL/WAI-WEBCONTENT-TRANSLATIONS.

Zie http://www.w3.org/WAI/GL/WAI-WEBCONTENT-ERRATA voor een lijst van bekende fouten in de Engelse versie. Andere fouten in dit document kunt u melden aan wai-wcag-editor@w3.org.

Voor een overzicht van de huidige W3C-Aanbevelingen en overige technische documenten zie http://www.w3.org/TR.

Dit document is gepubliceerd als onderdeel van het W3C Web Accessibility Initiative. De doelstellingen van de Web Content Guidelines Working Group zijn te vinden in het Working Group charter.

2.1 Zorg voor nette omzetting
2.2 Maak de content begrijpelijk en navigeerbaar
3. Hoe de richtlijnen zijn ingedeeld

3.1 Documentconventies
4. Prioriteiten
5. Conformiteit
6. Richtlijnen voor de Toegankelijkheid van Web Content

1. Lever equivalente alternatieven voor auditieve en visuele content.
2. Vertrouw niet op de kleur alleen.
3. Gebruik opmaak- en style sheets en doe dit op de juiste manier.
4. Geef het gebruik van de natuurlijke taal aan
5. Creëer tabellen die zich netjes laten transformeren.
6. Zorg ervoor dat pagina's die met nieuwe technologieën werken zich zich netjes transformeren.
7. Zorg voor gebruikersbediening bij tijdgevoelige veranderingen in content.
8. Zorg voor directe toegankelijkheid van ingebedde gebruikersinterfaces.
9. Ontwerp voor apparaatonafhankelijkheid.
10. Gebruik interimoplossingen.
11. Gebruik W3C-technologieën en -richtlijnen.
12. Lever informatie over context en oriëntatie
13. Lever duidelijke navigatiemechanismen.
14. Zorg ervoor dat documenten duidelijk en simpel zijn.
Appendix A. - Validatie
Appendix B. - Verklarende woordenlijst
Verantwoording en dank
Literatuur

1. Inleiding

Als je niet op de hoogte bent van toegankelijkheidsaspecten met betrekking tot het ontwerpen van een Webpagina, bedenk dan dat veel gebruikers moeten werken onder geheel andere dan gebruikelijke omstandigheden:

Zij kunnen niet zien, horen of bewegen of ze kunnen sommige soorten informatie moeilijk of helemaal niet verwerken.
Zij hebben problemen met het lezen of begrijpen van tekst.
Zij hebben geen toetsenbord of muis of kunnen die niet gebruiken.
Zij hebben een scherm voor alleen tekst, een klein scherm of een trage Internetverbinding.
Zij spreken of begrijpen de taal waarin het document is geschreven niet als hun moedertaal.
Zij bevinden zich in situaties waarin hun ogen, oren of handen gebonden zijn of gehinderd worden (bijvoorbeeld in de auto op weg naar het werk, werken in een lawaaierige omgeving, etc.).
Zij hebben een oude versie van een browser, een heel andere browser, een voice-browser of een ander operating system

Webontwikkelaars moeten deze verschillende situaties in acht nemen, als ze een pagina ontwerpen. Terwijl er verscheidene situaties zijn waarop je moet letten, komt iedere keus voor een toegankelijk ontwerp in het algemeen ten goede aan diverse groepen gehandicapten tegelijk en daarmee aan de gehele Webgemeenschap. Als je bijvoorbeeld style sheets gebruikt om het type font te sturen en het FONT-element niet gebruikt, heb je als HTML-auteur meer grip op je pagina's en maak je die pagina's toegankelijker voor mensen die minder goed zien; verder zal het gemeenschappelijk gebruik van style sheets de downloadtijd van pagina's voor alle gebruikers verkorten.

De richtlijnen bespreken toegankelijkheidsaspecten en leveren oplossingen voor toegankelijk ontwerp. Zij houden zich bezig met representatieve scenario's (zoals die uit het voorbeeld van het type font) die problemen geven voor gebruikers met handicaps.
De eerste richtlijn bijvoorbeeld legt uit hoe Webontwikkelaars afbeeldingen toegankelijk kunnen maken. Sommige gebruikers kunnen geen afbeeldingen zien, anderen gebruiken browsers voor alleen tekst, die afbeeldingen niet aankunnen en weer anderen hebben de faciliteit voor afbeeldingen uitgezet (bijvoorbeeld vanwege een trage Internetverbinding). De richtlijnen raden niet aan om het gebruik van afbeeldingen te vermijden ter verbetering van de toegankelijkheid. Inplaats daarvan geven ze aan dat het leveren van een tekstequivalent de afbeelding toegankelijk zal maken.

Hoe maakt een tekstequivalent een afbeelding toegankelijk? Beide onderdelen van "tekstequivalent" zijn belangrijk

Tekst kan worden gepresenteerd aan de gebruiker van synthetische spraak, braille en visueel getoonde tekst. Elk van deze drie mechanismen gebruikt een ander zintuig - oren voor de synthetische spraak, tast voor braille en ogen voor visueel getoonde tekst - waarmee de informatie toegankelijk wordt gemaakt voor groepen met een verscheidenheid van zintuiglijke en andere handicaps.
Om van nut te zijn moet de tekst dezelfde functie of hetzelfde doel hebben als de afbeelding. Neem bijvoorbeeld een tekstequivalent voor een foto van de Aarde gezien vanuit de ruimte. Als het doel van de foto voornamelijk decoratief is, zal de tekst "Foto van de Aarde gezien vanuit de ruimte" in de behoefte voorzien. Als het doel is om specifieke geografische informatie over de wereld te geven, zal het tekstequivalent die informatie moeten geven. Als de foto ontworpen is om de gebruiker te zeggen de afbeelding te selecteren (bijvoorbeeld door ze aan te klikken) voor informatie over de aarde, zou het tekstequivalent zijn "Informatie over de aarde". Met andere woorden, als de tekst hetzelfde doel of dezelfde functie heeft voor de gehandicapte gebruiker als de afbeelding voor andere gebruikers, kan de tekst worden beschouwd als tekstequivalent.

Merk op dat tekstequivalenten niet alleen gebruikers met handicaps tot voordeel zijn, maar dat ze ook alle gebruikers kunnen helpen pagina's sneller te vinden, omdat zoekrobots de tekst kunnen gebruiken bij het indexeren van pagina's.
Webontwikkelaars moeten dus tekstequivalenten leveren voor afbeeldingen en andere multimedia-objecten, terwijl het de taak van de user agents (bijvoorbeeld browsers en hulptechnologieën zoals schermlezers , brailleleesregels, etc.) is om de informatie aan de gebruiker aan te bieden

Niet-tekstequivalenten van tekst (bijvoorbeeld icoontjes, ingesproken tekst of een video van iemand die tekst in gebarentaal omzet) kunnen documenten toegankelijk maken voor mensen die problemen hebben met geschreven tekst, onder meer talrijke personen met cognitieve problemen, leerproblemen en doofheid. Niet-tekstequivalenten van tekst kunnen ook behulpzaam zijn voor niet-lezers. Een auditieve beschrijving is een voorbeeld van een niet-tekstequivalent van visuele informatie. Een auditieve beschrijving van het beeldspoor van een multimediapresentatie is van groot nut voor mensen die de visuele informatie niet kunnen zien.

2. Aspecten van toegankelijk ontwerp

De richtlijnen houden zich bezig met twee algemene aspecten: het zorgen voor nette omzetting en het begrijpelijk en navigeerbaar maken van de inhoud van Webpagina's.

2.1 Zorg voor nette omzetting

Als ze deze richtlijnen volgen, kunnen Webontwikkelaars pagina's creëren die netjes zijn om te zetten. Pagina's die netjes zijn om te zetten blijven toegankelijk ondanks de beperkingen beschreven in de inleiding, inclusief lichamelijke, zintuiglijke en cognitieve handicaps en technologische barrières. Hier volgen enige tips voor het ontwerpen van pagina's die netjes zijn om te zetten:

Houd structuur van presentatie gescheiden (wijs op het verschil tusen content, structuur en presentatie).
Lever tekst mee (inclusief tekstequivalenten). Tekst kan worden weergegeven met middelen waarover bijna alle browsers beschikken en die voor bijna alle gebruikers toegankelijk zijn.
Creëer documenten die ook werken, als de gebruiker niet kan zien en/of horen. Lever informatie die voor hetzelfde doel of dezelfde functie dient als audio of video op een wijze die eveneens geschikt is voor alternatieve zintuigen. Dit houdt niet in dat je een ingesproken audioversie moet maken van een hele site om die toegankelijk te maken voor blinde gebruikers. Blinde gebruikers kunnen schermlezertechnologie gebruiken om alle tekstinformatie op één pagina weer te geven.
Creëer documenten die niet van één type hardware afhankelijk zijn. Pagina's moeten bruikbaar zijn voor mensen zonder muis, met kleine schermen, lageresolutieschermen, zwart-wit-schermen, geen schermen, met slechts spraakuitvoer of tekstuitvoer, enz.

In de richtlijnen 1 - 11 worden de aspecten van een nette omzetting behandeld.

2.2 Maak de inhoud begrijpelijk en navigeerbaar

Webcontentontwikkelaars moeten de inhoud van de pagina's begrijpelijk en navigeerbaar maken. Dit houdt niet alleen in dat ze de taal duidelijk en eenvoudig moeten maken, maar dat ze ook begrijpelijke mechanismen moeten leveren voor het navigeren binnen en tussen pagina's. Het leveren van navigatiehulpmiddelen en informatie over de oriëntatie zal de toegankelijkheid en bruikbaarheid maximaliseren. Niet alle gebruikers kunnen gebruik maken van visuele aanwijzingen, zoals icoontjes voor afbeeldingen, proportionele schuifbalken, frames naast elkaar of grafische afbeeldingen die ziende gebruikers van grafische desktopbrowsers begeleiden. Gebruikers verliezen ook informatie over de context als ze slechts een deel van de pagina kunnen zien, hetzij omdat ze de pagina met slechts één woord tegelijk (synthetische spraak of brailleschrift) of één sectie tegelijk (klein scherm of een vergroot scherm) kunnen bekijken. Zonder informatie over de oriëntatie kunnen gebruikers wellicht geen bijzonder grote tabellen, lijsten, menu's enz. begrijpen.
In de richtlijnen 12 - 14 wordt het begrijpelijk en navigeerbaar maken van web-pagina's behandeld.

3. Indeling van de Richtlijnen

Dit document bevat veertien richtlijnen of algemene principes van toegankelijk ontwerp. Elke richtlijn bestaat uit:

Het nummer + titel van de richtlijn.
Navigatielinks voor de richtlijn. Drie links staan navigatie toe: naar de volgende richtlijn (met pijl naar rechts), de vorige richtlijn (met pijl naar links) of de positie van deze richtlijn in de inhoudsopgave (met pijl naar boven).
De tekst van de richtlijn.
De motivatie achter de richtlijn en enige groepen gebruikers die ervan profiteren.
Een lijst van ijkpuntdefinities.

De ijkpuntdefinities in iedere richtlijn leggen uit hoe de richtlijn van toepasing is in representatieve scenario's van Webontwikkeling. Elke ijkpuntdefinitie bestaat uit:

Het nummer van het ijkpunt.
De tekst van het ijkpunt.
De prioriteit van het ijkpunt. IJkpunten met prioriteit 1 worden geaccentueerd door middel van style sheets.
Optionele informatie, verhelderende voorbeelden en kruisverwijzingen naar verwante richtlijnen of ijkpunten.
Een link naar de sectie van "Technieken voor de Richtlijnen Toegankelijkheid Web Content" ([TECHNIQUES]) waar implementaties en voorbeelden van het ijkpunt worden besproken.

Elk ijkpunt wordt geacht zo specifiek te zijn dat iemand die een pagina of site inspecteert kan verifiëren dat aan het ijkpunt is voldaan.

3.1 Documentconventies

De volgende redactionele conventies gelden voor het hele document:

Namen van elementen zijn in hoofdletters.
Namen van attributen worden in kleine letters weergegeven.
Links naar definities worden geaccentueerd door middel van style sheets.

4. Priorititeiten

De Werkgroep heeft aan elk ijkpunt een prioriteit toegekend afhankelijk van het effect van het ijkpunt op de toegankelijkheid.

[Prioriteit 1]: Een Webontwikkelaar moet aan dit ijkpunt voldoen. Anders zal het voor één of meer groepen onmogelijk blijken om toegang te krijgen tot de informatie in het document. Voldoen aan dit ijkpunt is een eerste vereiste voor sommige groepen om Webdocumenten te kunnen gebruiken.
[Prioriteit 2]: Een Webontwikkelaar wordt geadviseerd te voldoen aan dit ijkpunt. Anders zal het voor één of meer groepen moeilijk blijken om toegang te krijgen tot de informatie in het document. Voldoen aan dit ijkpunt zal belangrijke obstakels verwijderen voor sommige groepen om Webdocumenten te kunnen gebruiken.
[Prioriteit 3]: Een Webontwikkelaar mag voldoen aan dit ijkpunt. Anders zal het voor één of meer groepen wat lastig blijken om toegang te krijgen tot de informatie in het document. Voldoen aan dit ijkpunt zal het makelijker maken voor sommige groepen om Webdocumenten te kunnen gebruiken.

Sommige ijkpunten hebben een prioriteit die kan veranderen onder zekere (aangegeven) voorwaarden.

5. Conformiteit

Dit hoofdstuk definieert drie niveaus van conformiteit voor dit document:

Conformiteitsniveau "A": aan alle ijkpunten met Prioriteit 1 is voldaan;
Conformiteitsniveau "Dubbel-A": aan alle ijkpunten met Prioriteit 1 en 2 is voldaan;
Conformiteitsniveau "Driedubbel-A": aan alle ijkpunten met Prioriteit 1, 2 en 3 is voldaan;

NB Conformiteitsniveaus worden in tekst gespeld, zodat ze begrepen kunnen worden, als ze in spraak worden weergegeven.
Claims op conformiteit aan dit document moeten in één van de twee volgende vormen zijn.

Vorm 1: Specificeer:

De titel van de richtlijnen: "Richtlijnen voor de Toegankelijkheid van Web Content 1.0"
De URI van de richtlijnen: http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
Het conformiteitsniveau waaraan voldaan is: "A", "Dubbel-A", of "Driedubbel-A".
Het gebied waarop de claim betrekking heeft (bijvoorbeeld pagina, site of gedefinieerde delen van een site).

Voorbeeld van Vorm 1:

Deze pagina conformeert aan W3C's "Richtlijnen Toegankelijkheid Web Content 1.0", beschikbaar op http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505, niveau Dubbel-A.

Vorm 2: Voeg op iedere pagina die conformiteit claimt één van de drie door W3C geleverde icoontjes in en link het icoontje aan de bijpassende W3C-uitleg van de claim. Informatie over de icoontjes en over hoe je ze in pagina's moet invoegen is beschikbaar op [WCAG-ICONS].

6. Richtlijnen Toegankelijkheid Web Content

Richtlijn 1. Lever equivalente alternatieven voor auditieve en visuele content.

Lever content die bij presentatie aan de gebruiker in essentie dezelfde functie of hetzelfde doel uitdrukt als auditieve of visuele content.

Hoewel sommige mensen (bewegende) beelden, geluiden, applets etc. niet direct kunnen gebruiken, kunnen ze wellicht wel pagina's gebruiken die informatie bevatten die equivalent is aan visuele of auditieve content. De equivalente informatie moet hetelfde doel dienen als de visuele of auditieve content. Zo zou het tekstequivalent voor de afbeelding van een opwaartse pijl die naar een inhoudsopgave linkt kunnen zijn "Naar de inhoudsopgave". In sommige gevallen zou een equivalent ook de verschijningsvorm van visuele content moeten beschrijven (bijvoorbeeld voor complexe grafische afbeeldingen, reclameborden of diagrammen) of het geluid van auditieve content (bijvoorbeeld voor geluidsopnamen die worden gebruikt in het onderwijs).
Deze richtlijn legt de nadruk op het belang om tekstequivalenten te leveren van niet-tekstuele content (beelden, geluidsopnamen, video). De kracht van tekstequivalenten ligt daarin dat zij weergegeven kunnen worden op een wijze die toegankelijk is voor mensen uit verschillende groepen gehandicapten die verschillende technologieën gebruiken. Tekst kan gemakkelijk worden uitgevoerd naar spraaksynthese-apparaten en brailleleesregels en kan visueel worden gepresenteerd (in diverse maten) op computerbeeldschermen en papier. Synthetische spraak is van vitaal belang voor personen die blind zijn en voor veel mensen met de lees problemen die vaak samengaan met cognitieve problemen, leerproblemen en doofheid. Brailleschrift is van essentieel belang voor personen die zowel doof als blind zijn, evenals voor veel personen wier enige zintuiglijke handicap blindheid is. Visueel getoonde tekst is van nut voor gebruikers die doof zijn, evenals voor de meerderheid van de Webgebruikers.

Het leveren van niet-tekstuele equivalenten (bijvoorbeeld afbeeldingen, video-opnamen en geluidsopnamen) van tekst is ook profijtelijk voor sommige gebruikers, in het bijzonder niet-lezers of mensen die problemen hebben met lezen. In films of visuele presentaties wordt visuele actie als lichaamstaal of andere visuele gebaren niet begeleid door voldoende auditieve informatie, die dezelfde informatie overbrengt. Tenzij van deze visuele informatie een verbale beschrijving wordt meegeleverd zullen mensen die de visuele inhoud niet kunnen zien (of bekijken) niet in staat zijn om die informatie waar te nemen.

IJkpunten:

1.1 Lever een tekstequivalent voor elk niet-tekstueel element (bijvoorbeeld via "alt", "longdesc" of in element-content). Dit omvat: afbeeldingen, grafische representaties van tekst (met inbegrip van symbolen), image maps, animaties (bijvoorbeeld GIF-animaties), applets en programma-objecten, ascii-kunst, frames, scripts, afbeeldingen voor bullets, spacers, grafische knoppen, geluiden (met of zonder gebruikersinteractie gespeeld), afzonderlijke geluidsbestanden, geluidssporen van video en video zelf. [Prioriteit 1]

Voorbeeld (in HTML):

Gebruik "alt" voor de elementen IMG, INPUT en APPLET of lever een tekstequivalent mee in de content van het OBJECT- en APPLET-element.
Voor complexe content (bijvoorbeeld een grafiek) waar de "alt"-tekst geen volledig tekstequivalent levert, kan je een extra beschrijving meegeven, bijvoorbeeld "longdesc" met IMG of FRAME of een link binnen een OBJECT-element of een description link.
Voor image maps gebruik je of het "alt"-attribuut met AREA, of het MAP-element met Anchor-elementen (en andere tekst) als content.

Zie ook ijkpunt 9.1 en ijkpunt 13.10.

Technieken voor ijkpunt 1.1

1.2 Lever tekstlinks voor ieder actief gebied van een server-side image map. [Prioriteit 1]

Zie ook ijkpunt 1.5 en ijkpunt 9.1.

Technieken voor ijkpunt 1.2

1.3 Totdat user agents automatisch de tekst van een beeldspoor hardop kunnen voorlezen kan je een auditieve beschrijving geven van de belangrijke informatie van het beeldspoor van een multimediapresentatie. [Prioriteit 1]

Synchroniseer de auditieve beschrijving met het geluidsspoor conform ijkpunt 1.4. Zie ook ijkpunt 1.1 voor informatie over tekstequivalenten voor visuele informatie.

Technieken voor ijkpunt 1.3

1.4 Voor iedere tijdgerelateerde multimediapresentatie, bijvoorbeeld een (animatie)film, kan je equivalente alternatieven synchroniseren (bijvoorbeeld onderschriften of auditieve beschrijvingen van het beeldspoor) met de presentatie. [Prioriteit 1]

Technieken voor ijkpunt 1.4

1.5 Totdat user agents tekstequivalenten voor client-side image map links kunnen weergeven, kan je tekstlinks leveren voor elke actief gebied van een client-side image map. [Prioriteit 3]

Zie ook ijkpunt 1.2 en ijkpunt 9.1.

Technieken voor ijkpunt 1.5

Richtlijn 2. Vertrouw niet op de kleur alleen.

Wees er zeker van dat tekst en grafische afbeeldingen begrijpelijk zijn als je ze zonder kleur ziet.

Als alleen kleur wordt gebruikt om informatie over te brengen, zullen mensen die bepaalde kleuren niet kunnen onderscheiden en gebruikers van apparaten zonder kleurenbeeld of met een nietvisuele afbeelding, die informatie niet ontvangen. Als de voorgrond- en achtergrondkleur te weinig van elkaar verschillen in HUE, vertonen ze wellicht te weinig contrast als ze op monochrome beeldbuizen worden gezien of gezien worden door mensen met diverse types kleurenblinheid.

IJkpunten:

2.1 Zorg ervoor dat alle informatie die met behulp van kleur wordt overgebracht ook beschikbaar is zonder kleur, bijvoorbeeld uit de context of uit de opmaak. [Prioriteit 1]: Technieken voor ijkpunt 2.1
2.2 Zorg ervoor dat combinaties van voorgrond- en achtergrondkleur voldoende contrast geven, als ze gezien worden door iemand met kleurenblindheid of als ze op een zwart-wit beeldscherm zijn te zien. [Prioriteit 2 voor beelden, Prioriteit 3 voor tekst].: Technieken voor ijkpunt 2.2

Richtlijn 3. Gebruik opmaak- en style sheets en doe dit op de juiste manier.

Maak documenten op met de juiste structuurelementen. Stuur de presentatie met style sheets en liever niet met presentatie-elementen en -attributen.

Als je de opmaak incorrect gebruikt - niet volgens de specificatie - hinder je de toegankelijkheid. Als je de opmaak oneigenlijk gebruikt voor een presentatie-effect (bijvoorbeeld als je een tabel gebruikt voor layout of een kop om de fontafmeting te veranderen) maak je het gebruikers met speciale software moeilijk om de indeling van de pagina te begrijpen of om erdoor te navigeren. Bovendien, als je presentatieopmaak gebruikt in plaats van structurele opmaak om structuur over te brengen (bijvoorbeeld als je iets met een PRE-element maakt wat op een tabel moet lijken) maak je het andere apparaten moeilijk om een pagina begrijpelijk weer te geven (zie ook de beschrijving van het verschil tussen content, structuur en presentatie).
Contentontwikkelaars komen wel eens in de verleiding om constructies te gebruiken (of te misbruiken) die op oudere browsers een gewenst formatteringseffect hebben. Zij moeten dan wel bedenken dat deze gewoontes toegankelijkheidsproblemen veroorzaken en zich afvragen of het formatteringseffect wel belangrijk genoeg is om het document ontoegankelijk te maken voor sommige gebruikers.

Aan de andere (uiterste) kant moeten contentontwikkelaars geen geschikte opmaak opofferen omdat een zekere browser of hulptechnologie die niet correct kan verwerken. Zo is het bijvoorbeeld raadzaam om het TABLE-element in HTML te gebruiken om tabelinformatie op te maken, al zullen er oudere schermlezers zijn die parallelle tekst niet correct kunnen verwerken. (zie ook ijkpunt 10.3). Een correct gebruik van TABLE en het creëren van tabellen die zich netjes laten transformeren (zie ook richtlijn 5) maakt het software mogelijk om tabellen anders dan als tweedimensionale roosters weer te geven.

IJkpunten:

3.1 Als er een geschikte opmaaktaal bestaat, gebruik dan liever opmaak dan afbeeldingen om informatie over te brengen. [Prioriteit 2]: Gebruik bijvoorbeeld MathML om wiskundige vergelijkingen op te maken en style sheets om tekst te formatteren en de layout te sturen. Vermijd ook het gebruik van afbeeldingen om tekst weer te geven - gebruik in plaats daarvan tekst en style sheets. Zie ook richtlijn 6 en richtlijn 11.; Technieken voor ijkpunt 3.1
3.2 Creëer documenten die zich conformeren aan een gepubliceerde formele grammatica. [Prioriteit 2]: Sluit bijvoorbeeld aan het begin van een document een documenttypedeclaratie in die verwijst naar een gepubliceerde DTD (bijvoorbeeld strict HTML 4.0 DTD).; Technieken voor ijkpunt 3.2
3.3 Gebruik style sheets om de layout en de presentatie te sturen. [Prioriteit 2]: Gebruik bijvoorbeeld liever de CSS-'font'-eigenschap in plaats van het FONT-element uit HTML om de fontstijlen te bepalen.; Technieken voor ijkpunt 3.3
3.4 Gebruik liever relatieve eenheden dan absolute eenheden als je in markuptalen waarden toekent aan attributen en eigenschappen in style sheets. [Prioriteit 2]: Gebruik bijvoorbeeld in een CSS liever 'em' of percentages van lengtes dan 'pt' of 'cm', wat absolute eenheden zijn. Als je absolute eenheden gebruikt, controleer of de weergegeven content bruikbaar is (zie ook de sectie over validatie).; Technieken voor ijkpunt 3.4
3.5 Gebruik headerelementen om de documentstructuur over te brengen en gebruik ze volgens de specificatie. [Prioriteit 2]: Gebruik bijvoorbeeld H2 in HTML om een subsectie van H1 aan te geven. Gebruik geen headers voor fonteffecten.; Technieken voor ijkpunt 3.5
3.6 Maak lijsten en lijstelementen op de juiste manier op. [Prioriteit 2]: Nest bijvoorbeeld in HTML OL-, UL- en DL-lijsten op de juiste manier.; Technieken voor ijkpunt 3.6
3.7 Opmaak citaten. Gebruik het citaat-element niet om formatteringseffecten te bereiken, zoals inspringen. [Prioriteit 2]: Gebruik daarentegen in HTML de Q- en BLOCKQUOTE-elementen om respectievelijk korte en langere citaten op te maken.; Technieken voor ijkpunt 3.7

Richtlijn 4. Geef het gebruik van de natuurlijke taal aan

Gebruik opmaak die de uitspraak en interpretatie van afgekorte of buitenlandse tekst mogelijk maakt.

Als contentontwikkelaars veranderingen van de natuurlijke taal in een document aangeven, kunnen spraaksynthesizers en brailleapparaten automatisch switchen naar de nieuwe taal, waardoor ze het document toegankelijker maken voor meertalige gebruikers. Contentontwikkelaars moeten de overheersende natuurlijke taal van de inhoud van een document aangeven (door opmaak of HTTP-headers). Contentontwikkelaars moeten ook de volledige uitwerkingen van afkortingen en acroniemen geven.
Behalve dat ze hulptechnologieën van dienst is, geeft opmaak in een natuurlijke taal zoekmachines de gelegenheid keywords te vinden en documenten in een gewenste taal te identificeren. Opmaak in een natuurlijke taal verbetert ook de leesbaarheid van het Web voor alle mensen, inclusief mensen met leermoeilijkheden, cognitieve problemen of mensen die doof zijn.

Als afkortingen en veranderingen in de natuurlijke taal niet worden aangegeven, worden ze mogelijk onontcijferbaar, als ze in brailleschrift of machinaal geluid worden omgezet.

IJkpunten:

4.1 Geef duidelijk veranderingen aan in de natuurlijk taal van de documenttekst en van alle tekstequivalenten (bijvoorbeeld onderschriften). [Prioriteit 1]: Gebruik bijvoorbeeld in HTML het "lang"-attribuut. Gebruik "xml:lang" in XML.; Technieken voor ijkpunt 4.1
4.2 Specificeer de uitwerking van elke afkorting of van elk acroniem in een document waar die het eerst voorkomt. [Prioriteit 3]: Gebruik bijvoorbeeld in HTML het "title"-attribuut van de ABBR- en ACRONYM-elementen. Als je de uitwerking meelevert in de body van het document, bevorder je ook de leesbaarheid van het document.; Technieken voor ijkpunt 4.2
4.3 Geef de voornaamste natuurlijke taal van een document aan. [Prioriteit 3]: Geef in HTML bijvoorbeeld het "lang"-attribuut een waarde bij het HTML-element. Gebruik in XML "xml:lang". Server-operateurs moeten servers zo configureren dat die gebruik maken van contentonderhandelingsmechanismen in HTTP ([RFC2068], sectie 14.13) zodat cliënten automatisch documenten in de gewenste taal kunnen ontsluiten.; Technieken voor ijkpunt 4.3

Richtlijn 5. Creëer tabellen die zich netjes laten transformeren.

Let erop dat tabellen de noodzakelijke opmaak hebben om door toegankelijke browsers en andere user agents getransformeerd te worden.

Tabellen moeten gebruikt worden voor het weergeven van data ("datatabellen"). Contentontwikkelaars moeten het gebruik van tabellen voor de layout van pagina's ("layouttabellen") vermijden. Tabellen voor welk gebruik dan ook leveren ook speciale problemen op voor gebruikers van schermlezers (zie ook ijkpunt 10.3).
Sommige user agents geven gebruikers de gelegenheid om langs tabelcellen te navigeren en de header en andere informatie in de cel te bekijken. Mits ze correct zijn opgemaakt, zullen deze tabellen user agents van de juiste informatie voorzien. (Zie ook richtlijn 3.)

De volgende ijkpunten zijn van direct nut voor mensen die een tabel met auditieve middelen lezen (bijvoorbeeld een schermlezer of een personal computer in de auto) of die slechts een gedeelte van de pagina tegelijk zien (bijvoorbeeld gebruikers met blindheid of met slecht zicht, die auditieve uitvoer gebruiken of braille-uitvoer, of andere gebruikers van apparaten met een klein scherm, etc.).

IJkpunten:

5.1 Voor tabellen met data: geef rij- en kolom-headers aan. [Prioriteit 1]: Gebruik bijvoorbeeld in HTML TD om datacellen aan te geven en TH om headers aan te geven.; Technieken voor ijkpunt 5.1
5.2 Gebruik voor datatabellen met twee of meer logische niveaus van rij- of kolomheaders opmaak om data- en headercellen te associëren. [Prioriteit 1]: Gebruik bijvoorbeeld in HTML THEAD, TFOOT en TBODY om rijen te groeperen, COL en COLGROUP om kolommen te groeperen en de attributen "axis", "scope" en "headers" om complexere relaties tussen data te beschrijven.; Technieken voor ijkpunt 5.2
5.3 Gebruik geen tabellen voor layout, tenzij de tabel ook zinvol is bij linearisering. Lever anders, als de tabel geen betekenis heeft een gelijkwaardig alternatief (bijvoorbeeld een gelineariseerde versie). [Prioriteit 2]: NB Zodra user agents positionering van de style sheet aankunnen, moeten tabellen niet gebruikt worden voor layout. Zie ook ijkpunt 3.3.; Technieken voor ijkpunt 5.3
5.4 Als een tabel wordt gebruikt voor layout, gebruik dan geen structurele opmaak om visueel te formatteren. [Prioriteit 2]: Gebruik bijvoorbeeld in HTML niet het TH-element om de inhoud van een cel (geen tabelheader) gecenterd en vet af te drukken.; Technieken voor ijkpunt 5.4
5.5 Lever samenvattingen voor tabellen. [Prioriteit 3]: Gebruik bijvoorbeeld in HTML het "summary"-attribuut van het TABLE-element.; Technieken voor ijkpunt 5.5
5.6 Lever afkortingen voor headerlabels. [Prioriteit 3]: Gebruik bijvoorbeeld in HTML het "abbr" attribuut van het TH-element.; Technieken voor ijkpunt 5.6

Zie ook ijkpunt 10.3.

Richtlijn 6. Zorg ervoor dat pagina's die met nieuwe technologieën werken zich netjes laten transformeren.

Zorg ervoor dat pagina's toegankelijk zijn, ook als nieuwe technologieën niet worden ondersteund of worden uitgezet.

Hoewel contentontwikkelaars worden aangemoedigd om nieuwe technologieën te gebruiken die problemen oplossen die bestaande technologieën met zich meebrachten, moeten ze er wel op letten dat hun pagina's ook nog werken bij oudere browsers en bij mensen die bepaalde functies uitzetten.

IJkpunten:

6.1 Organiseer documenten zo dat ze zonder style sheets gelezen kunnen worden. Als bijvoorbeeld een HTML-document wordt weergegeven zonder bijbehorende style sheets, moet het nog steeds mogelijk zijn om het document te lezen. [Prioriteit 1]: Als de content logisch is georganiseerd, zal ze op zinvolle wijze worden weergegeven als style sheets worden uitgezet of niet ondersteund worden.; Technieken voor ijkpunt 6.1
6.2 Zorg ervoor dat equivalenten voor dynamische content worden geactualiseerd, als de dynamische content verandert. [Prioriteit 1]: Technieken voor ijkpunt 6.2
6.3 Zorg ervoor dat pagina's bruikbaar zijn, als scripts, applets of andere programma-objects uitstaan of niet worden ondersteund. Als dit niet mogelijk is, lever dan equivalente informatie op een alternatieve toegankelijke pagina. [Prioriteit 1]: Zorg er bijvoorbeeld voor dat links die scripts activeren ook werken als scripts worden uitgezet of niet worden ondersteund (gebruik bijvoorbeeld geen "javascript:" als het linkdoel). Als het mogelijk is de pagina bruikbaar te maken zonder scripts, lever dan een tekstequivalent met het NOSCRIPT-element of gebruik een server-side script in plaats van een client-side script of lever een alternatieve toegankelijke pagina als per ijkpunt 11.4. Zie ook richtlijn 1.; Technieken voor ijkpunt 6.3
6.4 Zorg er in het geval van scripts en applets voor dat event handlers onafhankelijk zijn van het invoerapparaat. [Prioriteit 2]: Zie ook de definitie van apparaatonafhankelijkheid.; Technieken voor ijkpunt 6.4
6.5 Zorg ervoor dat dynamische content toegankelijk is of lever een alternative presentatie of pagina. [Prioriteit 2]: Gebruik bijvoorbeeld in HTML NOFRAMES aan het eind van iedere frameset. Voor sommige applicaties zijn server-side scripts wellicht toegankelijker dan client-side scripts.; Technieken voor ijkpunt 6.5

Zie ook ijkpunt 11.4.

Richtlijn 7. Zorg voor gebruikersbediening bij tijdgevoelige veranderingen in content.

Zorg ervoor dat bewegende, knipperende, scrollende of zelf-updatende objecten of pagina's stopgezet of stilgezet kunnen worden.

Sommige mensen met cognitieve of visuele handicaps zijn niet in staat om bewegende tekst snel genoeg of überhaupt te lezen. Beweging kan ook voor zoveel afleiding zorgen dat de rest van de pagina onleesbaar wordt voor mensen met cognitieve handicaps. Schermlezers zijn niet in staat bewegende tekst te lezen. Mensen met fysieke handicaps zijn mogelijk niet in staat om snel of nauwkeurig genoeg te bewegen om interactief te werken met bewegende objecten.
NB Alle volgende ijkpunten brengen enige verantwoordelijkheid voor de contentontwikkelaar met zich mee totdat user agents hiervoor adequate sturingsmechanismen leveren.

IJkpunten:

7.1 Geef het scherm geen gelegenheid om te flikkeren totdat user agents gebruikers in staat stellen flikkering te sturen. [Prioriteit 1]: NB Mensen met lichtgevoelige epilepsie kunnen een epileptische aanval krijgen die veroorzaakt wordt door flikkeringen of flitsen in het frequentiegebied van 4 - 59 flitsen per seconde (Hertz) met een topgevoeligheid bij 20 flitsen per seconde of door snelle veranderingen van donker naar licht (bij stroboscopisch licht).; Technieken voor ijkpunt 7.1
7.2 Laat de content niet knipperen (i.e. verander de presentatie in een regelmatig tempo, zoals aan- en uitzetten) totdat user agents gebruikers in staat stellen het knipperen te sturen. [Prioriteit 2]: Technieken voor ijkpunt 7.2
7.3 Vermijd beweging in pagina's totdat user agents gebruikers in staat stellen bewegende content te bevriezen. [Prioriteit 2]: Als een pagina bewegende content bevat, lever dan een mechanisme binnen een script of applet, dat gebruikers in staat stelt beweging of updating te bevriezen. Als je style sheets gebruikt met scripting voor beweging, stel je gebruikers in staat om het effect gemakkelijker uit te zetten of ongedaan te maken. Zie ook richtlijn 8.; Technieken voor ijkpunt 7.3
7.4 Creëer geen periodiek zelfverversende pagina's totdat user agents de mogelijkheid bieden die zelfverversing te stoppen. [Prioriteit 2]: Laat bijvoorbeeld in HTML pagina's niet zichzelf verversen met "HTTP-EQUIV=refresh" totdat user agents gebruikers in staat stellen deze functie af te zetten.; Technieken voor ijkpunt 7.4
7.5 Gebruik geen opmaak om pagina's automatisch te redirecten totdat user agents de mogelijkheid leveren om auto-redirect te stoppen. Configureer in plaats daarvan de server om redirects uit te voeren. [Prioriteit 2]: Technieken voor ijkpunt 7.5

NB BLINK- en MARQUEE-elementen zijn in geen enkele W3C-HTML-specificatie gedefinieerd en moeten niet worden gebruikt. Zie ook richtlijn 11.

Richtlijn 8. Zorg voor directe toegankelijkheid van ingebedde gebruikersinterfaces.

Zorg ervoor dat de gebruikersinterface principes van toegankelijk ontwerp volgt: apparaatonafhankelijk toegang tot functionaliteit, toetsenbordbesturing, self-voicing, etc.

Als een ingebed object zijn "eigen interface" heeft, moet de interface - evenals de interface tot de browser zelf - toegankelijk zijn. Als de interface van het ingebedde object niet toegankelijk gemaakt kan worden, moet een alternatieve toegankelijke oplossing worden geleverd.
NB Raadpleeg s.v.p. de User Agent Toegankelijkheids Richtlijnen ([WAI-USERAGENT]) en de Authoring Tool Toegankelijkheids Richtlijnen ([WAI-AUTOOL]) voor informatie over toegankelijke interfaces.

IJkpunt:

8.1 Maak programma-elementen als scripts en applets direct toegankelijk of compatibel met hulptechnologieën [Prioriteit 1 als functionaliteit belangrijk is en niet elders gepresenteerd, anders Prioriteit 2.]: Zie ook richtlijn 6.; Technieken voor ijkpunt 8.1

Richtlijn 9. Ontwerp apparaatonafhankelijkheid.

Gebruik eigenschappen die activering mogelijk maken van pagina-elementen via een verscheidenheid van invoerapparaten.

Apparaatonafhankelijke toegang betekent dat de gebruiker interactief kan werken met de user agent of het document met een invoer- (of uitvoer-) apparaat van zijn keuze - muis, toetsenbord, stem, "hoofdspriet", of iets dergelijks. Als bijvoorbeeld een formulier alleen kan worden ingevuld met behulp van een muis of een ander "aanwijsapparaat", zal iemand zonder gezichtsvermogen die de pagina gebruikt met behulp van steminvoer of met een toetsenbord met een ander invoerpapparaat zonder "aanwijsfuncties", niet in staat zijn het formulier te gebruiken.
NB Het leveren van tekstequivalenten voor image maps of afbeeldingen gebruikt als links maakt het mogelijk voor gebruikers ermee interactief te werken zonder een "aanwijsapparaat". Zie ook richtlijn 1.

In het algemeen zijn pagina's die interactie met het toetsenbord toelaten ook toegankelijk door middel van spraakinvoer of door middel van een opdrachtregel.

IJkpunten:

9.1 Lever client-side image maps in plaats van server-side image maps behalve waar de gebieden niet kunnen worden gedefinieerd met behulp van een beschikbaar geometrisch model. [Prioriteit 1]: Zie ook ijkpunt 1.1, ijkpunt 1.2 en ijkpunt 1.5.; Technieken voor ijkpunt 9.1
9.2 Zorg ervoor dat elk element dat zijn eigen interface heeft aangestuurd kan worden op een apparaatonafhankelijke manier. [Prioriteit 2]: Zie de definitie van apparaatonafhankelijkheid.; Zie ook richtlijn 8.; Technieken voor ijkpunt 9.2
9.3 Specificeer voor scripts liever logische event handlers dan apparaatafhankelijke event handlers. [Prioriteit 2]: Technieken voor ijkpunt 9.3
9.4 Creëer een logische volgorde van tabs door middel van links, formulierbesturing en objecten. [Prioriteit 3]: Specificeer bijvoorbeeld in HTML de volgorde van tabs via het attribuut "tabindex" of zorg voor een logisch paginaontwerp.; Technieken voor ijkpunt 9.4
9.5 Lever voor belangrijke links shortcuts (met inbegrip van die in client-side image maps), formulierbesturingen en groepen van formulierbesturing. [Prioriteit 3]: Specificeer bijvoorbeeld in HTML shortcuts via het attribuut "access key".; Technieken voor ijkpunt 9.5

Richtlijn 10. Gebruik interimoplossingen.

Gebruik interimoplossingen voor de toegankelijkheid zo dat hulptechnologieën en oudere browsers correct werken.

Oudere browsers staan bijvoorbeeld gebruikers niet toe om te navigeren naar lege invoervelden. Oudere schermlezers lezen lijsten van opeenvolgende links als één link. Die elementen zijn daarom moeilijk of helemaal niet toegankelijk. Ook kan het veranderen van het actuele venster of het te voorschijn springen van nieuwe vensters erg desoriënterend werken op gebruikers die niet kunnen zien dat dit is gebeurd.
NB De volgende ijkpunten zijn van toepassing totdat user agents (met inbegrip van hulptechnologieën) deze problemen aankunnen. Deze ijkpunten worden geklassificeerd als "interim", dat wil zeggen dat de Werkgroep Content-Richtlijnen ze als geldig beschouwt en als noodzakelijk voor de toegankelijkheid van het Web vanaf de publicatie van dit document. De Werkgroep verwacht evenwel niet dat deze ijkpunten in de toekomst noodzakelijk zijn, als de Webtechnologieën de verwachte functies of mogelijkheden eenmaal hebben geïncorporeerd.

IJkpunten:

10.1 Totdat user agents gebruikers toestaan om het ongewild openen van nieuwe vensters uit te zetten, is het beter om geen pop-ups of andere vensters te laten verschijnen en het actuele venster niet te veranderen zonder de gebruiker daarover te informeren. [Prioriteit 2]: Vermijd bijvoorbeeld in HTML het gebruik van frames waarvan het doel een nieuw venster is.; Technieken voor ijkpunt 10.1
10.2 Totdat user agents expliciete associaties tussen labels en formulierelementen ondersteunen, is het verstandig om bij alle formulierelementen met impliciet geassocieerde labels ervoor te zorgen dat de label netjes is gepositioneerd. [Prioriteit 2]: De label moet onmiddellijk aan zijn formulierelement voorafgaan op dezelfde regel (en daarbij meer dan één formulierelement/label per regel toestaan) of in de regel staan die aan het formulierelement voorafgaat (en dan slechts één label en één formulierelement per regel). Zie ook ijkpunt 12.4.; Technieken voor ijkpunt 10.2
10.3 Totdat user agents (met inbegrip van hulptechnologieën) parallelle tekst correct weergeven is het verstandig om een lineairetekstalternatief te geven (op dezelfde pagina of een andere) voor alle tabellen die tekst in parallelle kolommen weergeven. [Prioriteit 3]: NB Kijk s.v.p. naar de definitie van een gelineariseerde tabel. Dit ijkpunt is nuttig voor mensen met user agents (zoals sommige schermlezers) die niet in staat zijn om te gaan met blokken tekst die parallel worden weergegeven; dit ijkpunt moet contentontwikkelaars niet ontmoedigen tabellen te gebruiken om informatie in tabellen weer te geven.; Technieken voor ijkpunt 10.3
10.4 Totdat user agents lege invoerelementen correct kunnen verwerken is het beter om plaatsvervangende standaardtekst in invoervelden en tekstvelden neer te zetten. [Prioriteit 3]: Doe dit bijvoorbeeld in HTML voor TEXTAREA en INPUT.; Technieken voor ijkpunt 10.4
10.5 Totdat user agents (met inbegrip van hulpechnologieën) aan elkaar grenzende links apart kunnen weergeven is het beter om tussen aan elkaar grenzende links afdrukbare karakters te zetten die geen link zijn (omgeven door spaties). [Prioriteit 3]: Technieken voor ijkpunt 10.5

Richtlijn 11. Gebruik W3C-technologieën en -richtlijnen.

Gebruik W3C-technologieën (volgens de specificatie) en volg de richtlijnen voor toegankelijkheid. Als het niet mogelijk is om een W3C- technologie te gebruiken of als het gebruik ervan tot materiaal leidt dat niet netjes is te transformeren, is het beter om een alternatieve versie van de content te leveren die toegankelijk is.

De huidige richtlijnen bevelen W3C-technologieën (bijvoorbeeld HTML, CSS, etc.) aan om verschillende redenen:

W3C-technologieën omvatten "ingebouwde" functies voor toegankelijkheid.
W3C-specificaties worden in een vroeg stadium beoordeeld om er zeker van te zijn dat toegankelijkheidsaspecten tijdens de ontwerpfase in acht worden genomen.
W3C-specificaties worden ontwikkeld in een open proces gericht op concensus van de industrie.

Vele niet-W3C formaten (bijvoorbeeld PDF, Shockwave, etc.) vereisen voor het waarnemen óf plug-ins óf stand-alone applicaties. Vaak kunnen deze formaten niet bekeken of genavigeerd worden met standaard user agents (met inbegrip van hulptechnologieën). Als je niet-W3C en niet-standaardfuncties (gepatenteerde elementen), -attributen, -eigenschappen en -extensies vermijdt, zal dat ertoe leiden dat pagina's toegankelijker worden voor meer mensen, die een breder scala van hardware en software gebruiken. Als ontoegankelijke technologieën (gepatenteerd of niet) gebruikt moeten worden, moeten er wel equivalente toegankelijke pagina's geleverd worden.
Zelfs als W3C-technologieën worden gebruikt, dan moet dat gebeuren in overeenstemming met de richtlijnen voor toegankelijkheid. Als je nieuwe technologieën gebruikt, wees er dan zeker van dat ze zich netjes laten transformeren. (Zie ook richtlijn 6).

NB Het converteren van documenten (van PDF, PostScript, RTF, etc.) naar markuptalen van W3C (HTML, XML) resulteert niet altijd in een toegankelijk document. Valideer daarom elke pagina op toegankelijkheid en bruikbaarheid na het conversieproces (zie ook de sectie over validatie). Als een pagina niet gemakkelijk te converteren is, herzie de pagina dan totdat het origineel op de juiste manier converteert of lever een HLML- of plattetekstversie.

IJkpunten:

11.1 Gebruik W3C-technologieën als ze beschikbaar zijn en geschikt voor een klus en gebruik de jongste versies als ze ondersteuend worden. [Prioriteit 2]: Zie ook de literatuurlijst voor informatie met betrekking tot het vinden van de meest recente W3C-specificaties en [WAI-UA-SUPPORT] met betrekking tot user agent support voor W3C-technologieën.; Technieken voor ijkpunt 11.1
11.2 Vermijd afgekeurde eigenschappen van W3C-technologieën. [Prioriteit 2]: Gebruik bijvoorbeeld in HTML geen afgekeurd FONT-element; gebruik in plaats daarvan style sheets (bijvoorbeeld de 'font'-eigenschap in CSS).; Technieken voor ijkpunt 11.2
11.3 Lever informatie zó dat gebruikers documenten kunnen ontvangen volgens hun eigen voorkeur (bijvoorbeeld taal, soort content, etc.) [Prioriteit 3]: NB Gebruik contentonderhandeling waar mogelijk.; Technieken voor ijkpunt 11.3
11.4 Als je ondanks alle inspanningen geen toegankelijke pagina kan creëren, lever dan een link naar een alternatieve pagina die W3C-technologieën gebruikt, toegankelijk is, equivalente informatie (of functionaliteit) heeft en even vaak wordt geactualiseerd als de ontoegankelijke (oorspronkelijke) pagina. [Prioriteit 1]: Technieken voor ijkpunt 11.4

NB Contentontwikkelaars moeten alleen hun toevlucht nemen tot alternatieve pagina's als andere oplossingen niet lukken, omdat alternative pagina's in het algemeen minder vaak worden geactualiseerd dan "primaire" pagina's. Een verouderde pagina is waarschijnlijk even frustrerend als een pagina die ontoegankelijk is, aangezien in beide gevallen de informatie uit de oorspronkelijke pagina niet beschikbaar is. Het automatisch genereren van alternatieve pagina's leidt waarschijnlijk tot een meer frequente actualisering, maar contentontwikkelaars moeten er steeds zorgvuldig op letten dat de gegenereerde pagina's steeds zinvol zijn en dat gebruikers in staat zijn een site te navigeren door volgende links op primaire pagina's, alternatieve pagina's of beide. Voordat je je toevlucht neemt tot een alternatieve pagina, kan je beter het ontwerp van de originele pagina heroverwegen; als je die toegankelijk maakt, verbeter je hem waarschijnlijk voor alle gebruikers.

Richtlijn 12. Lever informatie over context en oriëntatie.

Lever informatie over context en oriëntatie en help daarmee gebruikers complexe pagina's of elementen te begrijpen.

Het groeperen van elementen en het leveren van contextuele informatie met betrekking tot de relaties tussen elementen kan nuttig zijn voor alle gebruikers. Complexe relaties tussen delen van een pagina kunnen moeilijk interpreteerbaar zijn voor mensen met een cognitieve of visuele handicap.

IJkpunten:

12.1 Geef elk frame een titel, zodat je identificatie en navigatie van een frame vergemakkelijkt. [Prioriteit 1]: Gebruik bijvoorbeeld in HTML het attribuut "title" bij FRAME-elementen.; Technieken voor ijkpunt 12.1
12.2 Beschrijf het doel van frames en hoe frames met elkaar te maken hebben, als het niet uit frametitels alleen blijkt. [Prioriteit 2]: Gebruik bij voor beeld in HTML "longdesc," of een description link.; Technieken voor ijkpunt 12.2
12.3 Verdeel grote blokken informatie onder in meer beheersbare groepen, waar dit natuurlijk en juist is. [Prioriteit 2]: Gebruik bijvoorbeeld in HTML OPTGROUP om OPTION-elementen binnen een SELECT te groeperen; groepeer formulierbesturing met FIELDSET en LEGEND; gebruik geneste lijsten waar dit passend is; gebruik headings om documenten te structureren, etc. Zie ook richtlijn 3.; Technieken voor ijkpunt 12.3
12.4 Associeer labels expliciet met hun besturingsmechanismen [Prioriteit 2]: Gebruik bij voor beeld in HTML LABEL en zijn "for"-attribuut.; Technieken voor ijkpunt 12.4

Richtlijn 13. Lever duidelijke navigatiemechanismen.

Lever duidelijke en consistente navigatiemechanismen - oriëntatie-informatie, navigatiebalken, een site map, etc. - en verhoog de kans dat iemand vindt wat hij zoekt op een site.

Duidelijke en consistente navigatiemechanismen zijn belangrijk voor mensen met cognitieve handicaps of blindheid en zijn nuttig voor alle gebruikers.

IJkpunten:

13.1 Identificeer duidelijk het doel van elke link. [Prioriteit 2]: Linktekst moet voldoende betekenis hebben om ook zinvol te zijn als die buiten de context wordt gelezen - hetzij op zichzelf hetzij als deel van een serie links. Linktekst moet ook beknopt zijn.; Schrijf bijvoorbeeld in HTML "Informatie over versie 4.3" in plaats van "klik hier aan". Behalve duidelijke linktekst kunnen contentontwikkelaars het doel van een link verder verduidelijken met een informatieve linktitel (bijvoorbeeld het "title"-attribuut in HTML).; Technieken voor ijkpunt 13.1
13.2 Lever metadata om semantische informatie toe te voegen aan pagina's en sites. [Prioriteit 2]: Gebruik bijvoorbeeld RDF ([RDF]) om de auteur van het document, het soort content, etc. aan te geven.; NB Sommige HTML user agents kunnen navigatiegereedschappen bouwen aan de hand van documentrelaties beschreven door het HTML LINK-element en "rel" of "rev"-attributen (bijvoorbeeld rel="volgende", rel="vorige", rel="index", etc.). Zie ook ijkpunt 13.5.; Technieken voor ijkpunt 13.2
13.3 Geef informatie over de algemene layout van een site (bijvoorbeeld een site map of een inhoudsopgave). [Prioriteit 2]: Als je de layout van de site beschrijft, geef dan speciale aandacht aan de beschikbare toegankelijkheidsfuncties met de nodige uitleg.; Technieken voor ijkpunt 13.3
13.4 Gebruik navigatiemechanismen op een consistente wijze. [Prioriteit 2]: Technieken voor ijkpunt 13.4
13.5 Lever navigatiebalken om navigatiemechanismen te accentueren en toegang ertoe te geven. [Prioriteit 3]: Technieken voor ijkpunt 13.5
13.6 Groepeer gerelateerde links, identificeer de groep (voor user agents) en lever een manier om de groep over te slaan totdat user agents dit ook kunnen. [Prioriteit 3]: Technieken voor ijkpunt 13.6
13.7 Als zoekfuncties worden geleverd, maak dan voor verschillende voorkeuren en niveaus van deskundigheid verschillende zoeksoorten. [Prioriteit 3]: Technieken voor ijkpunt 13.7
13.8 Plaats onderscheidende informatie aan het begin van headings, alinea's, lijsten, etc. [Prioriteit 3]: NB Dit wordt gewoonlijk "front-loading" genoemd; het is in het bijzonder nuttig voor mensen die informatie bekijken met seriële apparaten zoals spraakuitvoer.; Technieken voor ijkpunt 13.8
13.9 Lever informatie over documentverzamelingen (i.e., documenten die meervoudige pagina's bevatten.) [Prioriteit 3]: Specificeer bijvoorbeeld in HTML documentverzamelingen met het LINK-element en de "rel"- en "rev"-attributen. Een andere manier om een verzameling te creëren is het opbouwen van een archief (bijvoorbeeld met zip, tar en gzip, stuffit, etc.) van de meervoudige pagina's.; NB De snelheidsverbetering die het offline verwerken oplevert kan het browsen veel minder duur maken voor mensen met een handicap die mogelijk langzaam browsen.; Technieken voor ijkpunt 13.9
13.10 Lever een middel om ASCII-kunst van meer dan één regel over te slaan. [Prioriteit 3]: Zie ijkpunt 1.1 en het voorbeeld van ASCII-kunst in de verklarende woordenlijst.; Technieken voor ijkpunt 13.10

Richtlijn 14. Zorg ervoor dat documenten duidelijk en simpel zijn.

Zorg ervoor dat documenten duidelijk en simpel zijn zodat ze gemakkelijker begrepen kunnen worden.

Consistente paginalayout, herkenbare grafische afbeeldingen en gemakkelijk verstaanbare taal is van nut voor alle gebruikers. In het bijzonder helpen ze mensen met een cognitieve handicap of mensen die moeilijk kunnen lezen. (Maar zorg ervoor dat afbeeldingen tekstequivalenten hebben voor mensen die blind dan wel slechtziend zijn of voor iedere gebruiker die grafische afbeeldingen niet kan zien of ervoor heeft gekozen die niet te zien. Zie ook richtlijn 1.)
Het gebruik van duidelijke en simpele taal bevordert effectieve communicatie. Toegang tot geschreven informatie kan moeilijk zijn voor mensen met cognitieve handicaps of leerproblemen. Het gebruik van duidelijke en simpele taal is ook nuttig voor mensen wier eerste taal van je eigen eerste taal verschilt met inbegrip van die mensen die primair met tekens communiceren.

IJkpunten:

14.1 Gebruik de duidelijkste en eenvoudigste taal die zich leent voor de content van een site. [Prioriteit 1]: Technieken voor ijkpunt 14.1
14.2 Vul tekst aan met grafische of auditieve presentaties waar ze het begrijpen van de pagina zullen vergemakkelijken. [Prioriteit 3]: Zie ook richtlijn 1.; Technieken voor ijkpunt 14.2
14.3 Creëer een presentatiestijl die consistent is door de pagina's heen. [Prioriteit 3]: Technieken voor ijkpunt 14.3

Appendix A. - Validatie

Valideer toegankelijkheid met automatische tools en menselijke beoordeling. Geautomatiseerde methoden zijn in het algemeen snel en gemakkelijk, maar kunnen niet alle toegankelijkheidsaspecten identificeren. Menselijke beoordeling kan voor duidelijke taal en gemakkelijke navigatie zorgen.
Begin met het gebruiken van validatiemethoden in het vroegste stadium van ontwikkeling. Toegankelijkheidsaspecten die in een vroeg stadium worden geïdentificeerd zijn gemakkelijker te verbeteren en te omzeilen.

Hieronder volgen enige belangrijke validatiemethoden; ze worden gedetailleerd besproken in het hoofdstuk over validering in het Technieken Document.

Gebruik een geautomatiseerde tool voor toegankelijkheid en browservalidatie Denk er s.v.p. om dat software tools zich niet met alle toegankelijkheidsaspecten bezighouden, zoals de zinvolheid van link tekst, de toepasbaarheid van een tekstequivalent, etc.
Valideer de syntaxis (bijvoorbeeld HTML, XML, etc.).
Valideer style sheets (bijvoorbeeld CSS).
Gebruik een plattetekstbrowser of -emulator.
Gebruik meerdere grafische browsers, met:
- geluiden en grafische afbeeldingen geladen,
- grafische afbeeldingen niet geladen,
- geluiden niet geladen,
- geen muis,
- frames, scripts, style sheets, en applets niet geladen.
Gebruik verscheidene browsers, oud en nieuw.
Gebruik een self-voicing browser, een schermlezer, vergrotingssoftware, een klein scherm, etc.
Gebruik spelling- en grammaticacontrole. Iemand die een pagina leest met spraakuitvoer is waarschijnlijk niet in staat om de beste suggestie van de spraakuitvoer voor een woord met een spelfout te ontcijferen. Het uitsluiten van grammaticale problemen vergroot de begrijpelijkheid.
Beoordeel het document op duidelijkheid en eenvoud. Leesbaarheidsstatistieken zoals die door sommige word processors worden gegenereerd, kunnen nuttige aanwijzingen geven met betrekking tot duidelijkheid en eenvoud. Nog beter is het om een ervaren tekstbewerker te vragen om de geschreven content op duidelijkheid te beoordelen. Tekstbewerkers kunnen ook de bruikbaarheid van documenten verbeteren door herkenning van mogelijk gevoelige culturele aspecten die kunnen ontstaan door het gebruik van taal of iconen.
Verzoek mensen met handicaps om documenten te beoordelen. Ervaren en beginnende gebruikers met handicaps zullen waardevolle respons geven over toegankelijkheids- of bruikbaarheidsproblemen en hoe ernstig ze zijn.

Appendix B. - Verklarende woordenlijst

Achterwaarts compatibel

Ontwerp dat blijft werken met eerdere versies van een taal, programma, etc.

Afgekeurd

Een afgekeurd element of attribuut heet zo, omdat het door nieuwere constructies achterhaald is geraakt. Afgekeurde elementen kunnen verouderd raken in toekomstige versies van HTML. De index van HTML-elementen en -attributen in het Technieken-Document geeft aan welke elementen en attributen worden afgekeurd in HTML 4.0.

Auteurs moeten als het even kan geen afgekeurde elementen en attributen gebruiken. User agents moeten ze blijven ondersteunen om redenen van achterwaartse compatibiliteit.

Apparaatonafhankelijk

Gebruikers moeten in staat zijn interactief te werken met een user agent (en het document dat die weergeeft) onder gebruikmaking van de ondersteunde invoer- en uitvoerapparaten van hun keus en in overeenstemming met hun behoeften. Invoerapparaten zijn onder meer aanwijsapparaten, toetsenborden, brailleapparaten, hoofdsprieten, microfoons en dergelijke. Uitvoerapparaten zijn onder meer beeldschermen, spraaksynthesizers en brailleapparaten.

NB "Apparaatonafhankelijke ondersteuning" betekent niet dat user agents elk invoer- of uitvoerapparaat moeten ondersteunen. User agents moeten volledige invoer- en uitvoermechanismen bieden voor die apparaten die ondersteund worden. Als een user agent bijvoorbeeld invoer via de muis of het toetsenbord ondersteunt, moeten gebruikers in staat zijn interactief te werken met alle functies die of het toetsenbord of de muis gebruiken.

Applet

Een programma dat in een Webpagina is ingevoegd.

ASCII-kunst

Onder ASCII-kunst verstaan we tekstkarakters en -symbolen die gecombineerd worden om een afbeelding te creëren. Zo is bijvoorbeeld ":-)" het glimlachicoontje. Hieronder volgt een ASCII-figuur waarin de relatie wordt weergegeven tussen de flitsfrequentie en de fotoconvulsieve reactie bij patiënten met ogen open en dicht. [ sla de ASCII-figuur over of raadpleeg een beschrijving]:

 
  %   __ __ __ __ __ __ __ __ __ __ __ __ __ __   
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
       Flitsfrequentie (Hertz)

Authoring tool

Dit zijn onder meer HTML editors, tools voor documentconversie, tools die Webcontent genereren uit databases. Zie ook de "Guidelines Accessibility Authoring Tools" ([WAI-AUTOOLS]) voor informatie over de ontwikkeling van toegankelijke tools.

Belangrijk

Informatie in een document is belangrijk als het begrijpen van die informatie cruciaal is voor het begrijpen van het document.

Braille

Braille geeft letters en cijfers weer met behulp van één tot zes of acht opstaande punten in verschillende patronen, die blinden met hun vingertoppen kunnen lezen. Het woord "Toegankelijkheid" is in braille:

Een braille display, gewoonlijk een "brailleleesregel" genoemd, genereert patronen van opstaande of neergaande punten in opdracht van een electronisch apparaat, meestal een computer. Het resultaat is een regel met brailleleestekens, die van moment tot moment kan veranderen. Tegenwoordig variëren "brailleleesregels" in omvang van één cel (zes of acht stippen) tot tachtig cellen; meestal bestaat een leesregel uit 40 of 70 - 80 cellen.

Contentontwikkelaar

Iemand die Webpagina's schrijft of Websites ontwerpt.

DocumentContent, -Structuur en -Presentatie

De content van een document is wat het de gebruiker meedeelt via natuurlijke taal, afbeeldingen, filmpjes, animaties, etc. De structuur van een document is hoe het logisch is ingedeeld (bijvoorbeeld per hoofdstuk, met een introductie en een inhoudsopgave, etc.) Een element (bijvoorbeeld P, STRONG, BLOCKQUOTE in HTML) dat de documentstrucuur specificeert heet een structureel element. De presentatie van een document is hoe het document wordt weergegeven (bijvoorbeeld als een afdruk, als een twee-dimensionale grafische presentatie, als een plattetekstpresentatie, als gesimuleerde spraak, als braille, etc.) Een element dat de documentpresentatie specificeert (bijvoorbeeld B, FONT, CENTER) heet een presentatie-element.

Bekijk bijvoorbeeld een document header. De content van de header is wat de header zegt (bijvoorbeeld "Zeilboten"). In HTML is de header een structureel element, dat gemarkeerd wordt door bijvoorbeeld een H2-element. De presentatie van de header zou een vetgedrukt blokje tekst in de kantlijn kunnen zijn, een gecentreerde regel tekst, een titel op een bepaalde manier uitgesproken (als een auditief font) etc.

Dynamisch HTML (DHTML)

DHTML is de marketingterm voor een combinatie van standaarden waaronder HTML, style sheets, het Document Object Model [DOM1] en scripting. Er is evenwel formeel geen W3C-specificatie die DHTML definieert. De meeste richtlijnen zijn waarschijnlijk van toepassing voor applicaties die DHTML gebruiken, maar de volgende richtlijnen concentreren zich op aspecten die verband houden met scripting en style sheets: richtlijn 1, richtlijn 3, richtlijn 6, richtlijn 7 en richtlijn 9.

Element

Dit document gebruikt de term "element" zowel in de stricte SGML-betekenis (een element is een syntactische constructie) als in algemenere zin om een type content aan te geven (zoals video of geluid) of een logische constructie (zoals een header of een lijst). De tweede betekenis accentueert dat een richtlijn geïnspireerd door HTML gemakkelijk toepasbaar is op andere markuptalen.

NB Sommige (SGML-) elementen hebben content die wordt weergegeven (bijvoorbeeld de P-, LI- of TABLE-elementen in HTML), andere worden vervangen door externe content (bijvoorbeeld IMG), weer andere beïnvloeden de verwerkingswijze (bijvoorbeeld STYLE en SCRIPT hebben tot gevolg dat informatie wordt verwerkt door een style sheet of een scriptgenerator). Een element dat ervoor zorgt dat tekstkarakters deel uitmaken van het document heet een tekstelement.

Equivalent

Content is "equivalent" met andere content als beide in essentie dezelfde functie vervullen of hetzelfde nastreven bij presentatie aan de gebruiker. In de context van dit document moet het equivalent in essentie dezelfde functie hebben voor iemand met een handicap (voorzover dat haalbaar is, gegeven de aard van de handicap en de stand van de technologie) als de primaire content heeft voor iemand zonder handicaps. Zo kan bijvoorbeeld de tekst "Volle Maan" dezelfde informatie overbrengen als een afbeelding van een volle maan, als die aan gebruikers wordt gepresenteerd. NB Equivalente informatie concentreert zich op vervulling van dezelfde functie. Als de afbeelding deel is van een link en als begrijpen van de afbeelding cruciaal is om het doel van de link te raden, moet een equivalent ook een idee geven van het doel. Het leveren van equivalente informatie voor ontoegankelijke content is één van de primaire manieren waarop auteurs hun documenten toegankelijk kunnen maken voor mensen met handicaps.

Als onderdeel van de vervulling van dezelfde functie van content kan een equivalent een bechrijving van die content inhouden (d.w.z. waar de content op lijkt of hoe die klinkt). Auteurs zouden bijvoorbeeld de visuele informatie in een complex diagram moeten beschrijven om gebruikers de informatie te laten begrijpen die dat diagram weergeeft.

Aangezien tekstcontent aan de gebruiker gepresenteerd kan worden als synthetische spraak, braille en visueel vertoonde tekst, vereisen deze richtlijnen tekstequivalenten voor grafische en auditieve informatie. Tekstequivalenten moeten zo geschreven worden dat ze alle essentiële content doorgeven. Niet-tekstuele equivalenten (bijvoorbeeld een auditieve beschrijving van een visuele presentatie, een video van iemand die een verhaal d.m.v. gebarentaal vertelt als een equivalent voor een geschreven verhaal, etc.) verbeteren ook de toegankelijkheid voor mensen die geen toegang hebben tot visuele informatie of geschreven tekst, waaronder vele personen met blindheid, cognitieve handicaps, leerproblemen en doofheid.

Equivalente informatie kan op een aantal manieren worden geleverd, waaronder d.m.v. attributen (bijvoorbeeld een tekstwaarde voor het "alt"-attribuut in HTML en SMIL), als onderdeel van de content van het element (bijvoorbeeld het OBJECT in HTML), als onderdeel van het proza van het document of via een gelinkt document (bijvoorbeeld aangegeven door het "longdesc"-attribuut in HTML of een description link). Afhankelijk van de complexiteit van het equivalent is het wellicht noodzakelijk technieken te combineren (gebruik bijvoorbeeld "alt" voor een afgekort equivalent, nuttig voor lezers die al op de hoogte zijn naast een "longdesc" voor een link naar meer volledige informatie, nuttig voor degen die het voor het eerst lezen). De details over hoe en wanneer je equivalente informatie moet geven zijn onderdeel van het Technieken Document ([TECHNIQUES]).

Een teksttranscriptie is een tekstequivalent van auditieve informatie die bestaat uit gesproken woorden en niet gesproken geluiden zoals geluidseffecten.
Een ondertiteling is een teksttranscriptie voor het geluidsspoor van een videopresentatie, die wordt gesynchroniseerd met de video- en geluidssporen. Ondertitels worden doorgaans visueel weergegeven door ze bovenop de video te plaatsen; hiervan profiteren mensen die doof en hardhorend zijn en iedereen die de auditieve infomatie niet kan horen (bijvoorbeeld in een volle kamer is). Een gecollationeerde teksttranscriptie combineert (collationeert) ondertitelingen met tekstbeschrijvingen van video-informatie (beschrijvingen van de acties, lichaamstaal, grafische afbeeldingen en tafereelveranderingen van het videospoor). Deze tekstequivalenten maken presentaties toegankelijk voor mensen die doof-blind zijn en voor mensen die geen films, animaties. etc kunnen afspelen. Ook maakt e.e.a. de informatie beschikbaar voor zoekmachines.

Een voorbeeld van een niet-tekstueel equivalent is een auditieve beschrijving van de voornaamste visuele elementen van een presentatie. De beschrijving is of een vooraf opgenomen menselijke stem of een synthetische stem (opgenomen of voor de vuist weg gegenereerd). De auditieve beschrijving wordt gesynchroniseerd met het geluidsspoor van de presentatie, gewoonlijk tijdens natuurlijke pauzes in het geluidsspoor. Auditieve beschrijvingen bevatten informatie over acties, lichaamstaal, grafische afbeeldingen en tafereelveranderingen.

Hulptechnologie

Software of hardware die speciaal ontworpen is om mensen met handicaps te helpen dagelijkse activiteiten uit te voeren. Hulptechnologie bevat onder meer rolstoelen, leesmachines, grijpers, etc. Op het gebied van Webtoegankelijkheid zijn gewone "software-based" hulptechnologieën onder meer schermlezers, beeldschermvergroters, spraaksynthesizers en spraakherkenningssoftware; deze functioneren in samenwerking met grafische browsers (onder andere user agents). Hardware-hulptechnologieën zijn onder meer alternatieve toetsenborden en aanwijsapparaten.

Image map

Een afbeelding die onderverdeeld is in regio's met geassocieerde acties. Het aanklikken van een actieve regio heeft een actie tot gevolg.

Als een gebruiker een actieve regio van een client-side image map aanklikt, berekent de user agent welke regio werd aangeklikt en volgt de link geassocieerd met de regio. Het aanklikken van een actieve regio van een server-side image map heeft tot gevolg dat de coördinaten van de aangeklikte positie naar de server worden gestuurd, waarop die een of andere actie uitvoert.

Contentontwikkelaars kunnen client-side image maps toegankelijk maken door apparaatonafhankelijke toegang te geven aan dezelfde links geassocieerd met de regio's van de image map. Client-side image maps staan de user agent toe onmiddellijk respons te geven met betrekking tot de vraag of de pointer van de gebruiker wel of niet over een actieve regio gaat.

Linearisering, gelineariseerde tabel

Een tabelpresentatiewijze waarbij de inhoud van de cellen een serie elkaar opvolgende alinea's wordt (bijvoorbeeld van boven naar beneden). De alinea's zullen in dezelfde volgorde optreden als de cellen in het document zijn gedefinieerd. De cellen moeten wel betekenins hebben en moeten structurele elementen bevatten (die alinea's, headers, lijsten, etc. creëren) zodat de pagina ook nog betekenis heeft na linearisering.

Linktekst

De weergegeven tekstcontent van een link.

Natuurlijke taal

Geproken, geschreven of geseinde menselijke talen, zoals Frans, Japans, American Sign Language en braille. De natuurlijke taal van de content kan worden aangegeven met het "lang"-attribuut in HTML ([HTML40], sectie 8.1) en het "xml:lang"-attribuut in XML ([XML], sectie 2.12).

Navigatiemechanisme

Een navigatiemechanisme is elk middel waardoor een gebruiker een pagina of site kan navigeren. Kenmerkende navigatiemechanismen zijn onder meer:

navigatiebalken: Een navigatiebalk is een collectie links naar de belangrijkste delen van een document of site.
site maps: Een site map geeft een globaal overzicht van de organisatie van een pagina of site.
inhoudsopgave: Een inhoudsopgave geeft in het algemeen een lijst van de belangrijkste secties van een document (met links ernaartoe).

Persoonlijke Digitale Assistent (PDA)

Een PDA is een kleine draagbare rekenmachine. De meeste PDA's worden gebruikt om persoonlijke gegevens zoals agenda's, contacten en electronische post bij te houden. Een PDA is in het algemeen een handzaam machientje met een klein scherm dat invoer uit verschillende bronnen kan ontvangen.

Schermlezer

Een programma dat een gebruiker de inhoud van het scherm hardop voorleest. Schermlezers worden primair gebruikt door gebruikers die blind zijn. Schermlezers kunnen gewoonlijk alleen tekst lezen die op het scherm wordt afgedrukt, niet geschilderd.

Schermvergroter

Een programma dat een deel van het scherm vergroot, zodat het gemakkelijker kan worden bekeken. Schermvergroters worden primair gebruikt door personen met een beperkt gezichtsvermogen.

Style sheets

Een style sheet is een verzameling statements die de presentatie van een document specificeren. Style sheets hebben drie mogelijke bronnen van herkomst: geschreven door contentleveranciers, gecreëerd door gebruikers of in user agents ingebouwd. In CSS ([CSS2]) wordt de interactie van style sheets van contentleverancier, gebruiker en user agent cascade genoemd.

Presentatiemarkup is markup die een stylistisch (en geen structurerend) effect heeft, zoals de B- of I-elementen in HTML. Merk op dat de STRONG- en EM-elementen niet als presentatiemarkup worden beschouwd, aangezien ze informatie overbrengen die onafhankelijk is van een bepaalde fontstijl.

Tabelinformatie

Als tabellen worden gebruikt om logische relaties tussen gegevens te representeren - tekst, getallen, afbeeldingen, etc., dan heet die informatie "tabelinformatie" en de tabellen heten "gegevenstabellen. De relates die in de tabel worden uitgedrukt kunnen visueel (gewoonlijk in een twee-dimensionaal rooster) worden weergegeven, auditief (vaak voorafgaand aan cellen met headerinformatie) of in een ander format.

Toegankelijk

Content is toegankelijk als ze gebruikt kan worden door iemand met een handicap.

Totdat user agents ...

In de meeste ijkpunten wordt contentontwikkelaars gevraagd de voor toegankelijkheid van hun pagina's en sites te zorgen. Er zijn evenwel toegankelijkheidsbehoeftes waarin beter voorzien kan worden door user agents (met inbegrip van hulptechnologieën). Op het moment dat dit document werd gepubliceerd leveren nog niet alle user agents of hulpechnologieën de controle over toegankelijkheid die gebruikers verlangen. (Sommige user agents staan bijvoorbeeld gebruikers niet toe knipperende content af te zetten of sommige schermlezers handelen tabellen niet goed af). IJkpunten die de zinsnede "totdat user agents ..." bevatten, verlangen van contentontwikkelaars dat zij extra ondersteuning leveren voor de toegankelijkheid totdat de meeste user agents die hun klantenkring ter beschikking staan de noodzakelijke toegankelijkheidseigenschappen hebben.

NB De W3C WAI Website (zie ook [WAI-UA-SUPPORT]) levert informatie over user agent-ondersteuning voor toegankelijkheidseigenschappen. Contentontwikkelaars wordt vriendelijk verzocht deze pagina na te slaan voor geactualiseerde informatie.

User agent

Programmatuur voor toegang tot Webcontent, met inbegrip van grafische desktopbrowsers, tekstbrowsers, voice-browsers, mobilofoons, multimediaspelers, plug-ins en sommige hulptechnologieën voor software die gebruikt worden in combinatie met browsers, zoals schermlezers, schermvergroters en stemherkenningprogrammatuur.

Verantwoording en dank

Web Voorzitters Werkgroep Content-Richtlijnen:: Chuck Letourneau, Starling Access Services; Gregg Vanderheiden, Trace Research en Development
Contacten W3C Team:: Judy Brewer en Daniel Dardailler
We willen graag de volgende mensen bedanken die hebben bijgedragen aan de totstandkoming van deze richtlijnen, door hun tijd eraan te wijden of door waardevol commentaar:: 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, enJason White

het allereerste concept van dit document is gebaseerd op "The Unified Web Site Accessibility Guidelines" ([UWSAG]) samengesteld door het Trace R & D Center at the University of Wisconsin. Dit document bevat een lijst van verdere medewerkers.

Literatuur

Voor de meest recente versie van elke W3C-specificatie zie de lijst van Technische Rapporten W3C.

[CSS1]: "CSS, level 1 Recommendation", B. Bos, H. Wium Lie, red., 17 december 1996, herziene uitgave op 11 januari 1999. De CSS1-Aanbeveling is: http://www.w3.org/TR/1999/REC-CSS1-19990111.; De meest recente versie van CSS1 is verkrijgbaar bij : http://www.w3.org/TR/REC-CSS1.
[CSS2]: "CSS, level 2 Recommendation", B. Bos, H. Wium Lie, C. Lilley en I. Jacobs, red., 12 mei 1998. De CSS2 Aanbeveling is: http://www.w3.org/TR/1998/REC-CSS2-19980512.
De meest recente versie van CSS2 is verkrijgbaar bij : http://www.w3.org/TR/REC-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 en L. Wood, red., 1 oktober 1998. De DOM Level 1 Aanbeveling is: http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001.
De meest recente versie van DOM Level 1 is beschikbaar op: http://www.w3.org/TR/REC-DOM-Level-1
[HTML40]: "HTML 4.0 Recommendation", D. Raggett, A. Le Hors en I. Jacobs, red., 17 december 1997, herzien 24 april 1998. De HTML 4.0 Aanbeveling is: http://www.w3.org/TR/1998/REC-html40-19980424.
De meest recente versie van HTML 4.0 is beschikbaar op: http://www.w3.org/TR/REC-html40.
[HTML32]: "HTML 3.2 Recommendation", D. Raggett, red., 14 January 1997. De meest recente versie van HTML 3.2 is beschikbaar op: http://www.w3.org/TR/REC-html32.
[MATHML]: "Mathematical Markup Language", P. Ion en R. Miner, red., 7 april 1998. De MathML 1.0 Recommendation is: http://www.w3.org/TR/1998/REC-MathML-19980407.
De meest recente versie van MathML 1.0 is beschikbaar op: http://www.w3.org/TRREC-MathML.
[PNG]: "PNG (Portable Network Graphics) Specification", T. Boutell, red., T. Lane, medered., 1 oktober 1996. De meest recente versie van PNG 1.0 is: http://www.w3.org/TR/REC-png.
[RDF]: "Resource Description Framework (RDF) Model and Syntax Specification", O. Lassila, R. Swick, red., 22 februari 1999. De RDF Recommendation is: http://www.w3.org/TR/1999/REC-rdf-syntax-19990222.
De meest recente versie van RDF 1.0 is beschikbaar op: http://www.w3.org/TR/REC-rdf-syntax
[RFC2068]: "HTTP Version 1.1", R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen en T. Berners-Lee, januari 1997.
[SMIL]: "Synchronized Multimedia Integration Language (SMIL) 1.0 Specification", P. Hoschka, red., 15 juni 1998. The SMIL 1.0 Recommendation is: http://www.w3.org/TR/1998/REC-smil-19980615
De meest recente versie van SMIL 1.0 is beschikbaar op: http://www.w3.org/TR/REC-smil
[TECHNIQUES]: "Techniques for Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, I. Jacobs, red. Dit document legt uit hoe je de ijkpunten in "Web Content Accessibility Guidelines 1.0" kunt implementeren. De meest recente versie van de Techniques is beschikbaar op: http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/
[WAI-AUTOOLS]: "Authoring Tool Accessibility Richtlijnen", J. Treviranus, J. Richards, I. Jacobs, C. McCathieNevile, red. De meest recente Working Draft van deze richtlijnen om toegankelijke authoring tools te ontwerpen is beschikbaar op: http://www.w3.org/TR/WAI-AUTOOLS/
[WAI-UA-SUPPORT]: Deze pagina documenteert welke ondersteuning door user agents (met inbegrip van hulptechnologieën) wordt gegeven aan sommige toegankelijkheidseigenschappen die dit document noemt. De pagina is beschikbaar op: http://www.w3.org/WAI/Resources/WAI-UA-Support
[WAI-USERAGENT]: "User Agent Accessibility Guidelines", J. Gunderson en I. Jacobs, red. De meest recente Working Draft van deze richtlijnen voor het ontwerpen van toegankelijke user agents is beschikbaar op: http://www.w3.org/TR/WAI-USERAGENT/
[WCAG-ICONEN]: Informatie over conformiteit-iconen voor dit document en hoe ze te gebruiken is beschikbaar op: http://www.w3.org/WAI/WCAG1-Conformance.html
[UWSAG]: "The Unified Web Site Accessibility Guidelines", G. Vanderheiden, W. Chisholm, red. De Unified Web Site Guidelines werden verzameld door het Trace R & D Center aan de University of Wisconsin onder subsidie van het National Institute on Disability and Rehabilitation Research (NIDRR), U.S. Dept. of Education. Dit document is beschikbaar op: http://www.tracecenter.org/docs/html_guidelines/version8.htm
[XML]: "Extensible Markup Language (XML) 1.0.", T. Bray, J. Paoli, C.M. Sperberg-McQueen, red., 10 februari 1998. De XML 1.0-aanbeveling is: http://www.w3.org/TR/1998/REC-xml-19980210.; De meest recente versie van XML 1.0 is beschikbaar op: http://www.w3.org/TR/REC-xml.

Laatst bijgewerkt op: 3 mei 2004 12:00