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
Copyright © 1999
W3C (
MIT,
INRIA,
Keio). Alle rechten
voorbehouden. W3C-regels betreffende
aansprakelijkheid,
handelsmerk,
documentgebruik en
softwarelicentiëring zijn van toepassing.
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.
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