Toegankelijk bouwen wordt vaak verward met gebruiksvriendelijkheid. Maar er is toch echt verschil tussen deze twee onderwerpen.

Bij gebruiksvriendelijk bouwen zorg je er voor dat de bezoeker geen strobreed in de weg wordt gelegd tijdens het bezoek aan je site. En bij toegankelijk bouwen concentreer je je juist op de dingen die er voor zorgen dat zo veel mogelijk bezoekers op je site kunnen komen. De overeenkomst tussen beide begrippen kan wel zijn dat ze beiden onnodig veel lelijke sites hebben opgeleverd.

Zowel gebruiksvriendelijkheid als toegankelijkheid hebben onterecht een slechte naam gekregen. Die slechte naam is grotendeels te danken aan de mensen die ons vertellen dat we rekening moeten houden met gebruiksvriendelijkheid en toegankelijkheid en hoe we dat moeten doen. Vaak adviseren ze heel dwingend en houden ze weinig rekeningen met de compromissen die je nu eenmaal moet sluiten wanneer je voor een klant werkt die toch écht zijn huisstijl terug wil zien in de site. De voorbeelden van gebruiksvriendelijke sites zijn bovendien vaak slaapverwekkend saai, en veel toegankelijke sites zijn te lelijk voor woorden. Zo, dat is er uit. Het is dus niet vreemd dat binnen veel organisaties toegankelijk bouwen geen hoge prioriteit heeft.

Het is mijn stellige overtuiging dat het goed mogelijk is om toegankelijke sites te maken met behoud van het opgebouwde imago van de opdrachtgever. En ik denk ook dat het een vergissing is om te denken dat je site goed is op het moment dat hij niet afgekeurd wordt door een online tool dat de toegankelijkheid beoordeelt. En een “goedgekeurde” toegankelijke site hoeft nog helemaal niet makkelijk in het gebruik te zijn voor degene waarvoor je de toegankelijkheid nu juist in gedachten had.

Toegankelijk bouwen... waarom zou je?

Er is in Nederland geen instantie die je bestraft als je niet toegankelijk bouwt. Je kunt zelfs veilig de intentieverklaring van Drempels Weg tekenen zonder dat je op het matje geroepen wordt op het moment dat je de site toch niet helemaal toegankelijk maakt.

Maar ik neem aan dat je geen stok achter de deur – in de vorm van een bestraffende instantie – nodig hebt als je de voordelen van een toegankelijke site kent:

• Door toegankelijk te bouwen maak je een site die ook door verouderde browsers prima bezocht kan worden.
• Een zoekmachine kan een toegankelijk gebouwde site meestal makkelijker indexeren, en dus wordt je daarna beter gevonden.
• De site is ook door bijv. PDA’s te bezoeken.
• En mensen met een handicap kunnen dan natuurlijk ook prima uit de voeten met de door jou gemaakte site.

Kortom, meer mensen kunnen gebruik maken van je site. Dat zijn dus meer (potentiële) klanten, betere mond-tot-mond reclame, meer omzet (hé opdrachtgever, bent u daar nog? MEER OMZET!?). Dat betekent dat iedere ontoegankelijke site minder resultaat zal halen uit de investering die gedaan is in de website. En zo simpel is het.

Toegankelijk bouwen geeft je als bouwer de gelegenheid om weer eens stevig na te denken. Het geeft je als ontwerper de gelegenheid om te laten zien dat je meer kunt dat een leuk plaatje maken. En het geeft je als account manager gelegenheid om een goed verhaal te houden over het rendement uit investeringen. Dat is toch wat je wilt, of niet soms?

De praktijk

Hoe vertaal je toegankelijk bouwen naar de praktijk, zonder concessies te doen aan het imago dat de klant wil uitstralen? Hoe zorg je er met relatief kleine ingrepen voor dat je de toegankelijkheid een flink stuk vergroot?

Plaatjes

Een zeer grote slag sla je door het toevoegen van een relevante alt-tekst aan het beeld dat je gebruikt in je site. Hier moet ik even duidelijk zijn. Het gaat om een relevante tekst! Dat betekent dat je het beeld beschrijft voor degene die de afbeelding niet (kunnen) laden of zien. Daarbij hou je rekening met het verschil tussen de alt-tag en de title-tag. Zoals ook in een eerder artikel gezegd bestaat de alt-tekst uit een goed alternatief voor het beeld. Met de title-tag zorg je er voor dat er een tooltip verschijnt.

Laten we kijken naar wat voorbeelden, zonder dat ik aangeef om welke sites het hier gaat. Dit artikel is immers niet bedoeld als schandpaal.

Voorbeeld 1

Met beeld:

Zonder beeld:

Je ziet dat hier aanwijzingen zijn gegeven in de alt-tekst over het interactieve karakter van het plaatje. Mensen die gebruik maken van een screenreader krijgen voordat de tekst wordt uitgelezen de melding dat het een link betreft. Toevoegingen zoals “klik hier”, “link naar” of “klik voor een reactie” zijn overbodig. Het resultaat is immers dat het volgende wordt uitgelezen: “link klik hier...” of “link link naar...”.

Voor deze mededelingen is de title-tag een veel geschiktere plek. Binnen de title-tag kun je extra informatie kwijt waar de bezoeker iets aan heeft. Door gebruik te maken van de alt-tag voor deze boodschap maak in feite gebruik van een foutje in Internet Explorer. De alt-tag hoort namelijk niet als tooltip te verschijnen. Zodra deze browser dit corrigeert zal er ook geen tooltip meer verschijnen als alleen de alt-tekst is ingevuld.

Voorbeeld 2

Zonder beeld:

Met beeld:

Op deze site wordt de alt-tekst duidelijk automatisch gegenereerd: hij is hetzelfde als de kop van het stukje. Maar dat is geen goed idee. Hier zou je bijvoorbeeld de indruk kunnen krijgen dat de kamer bestaat uit kleuters: de alt-tekst is geen beschrijving van wat je ziet op de foto. Maar het is vervelend voor de bezoeker met een screenreader of een tekstbrowser. De screenreader zal tweemaal de kop van het artikel uitlezen en de tekstbrowser zal ’m tweemaal laten zien.

Voorbeeld 3

Met beeld:

Zonder beeld:

Maar dit is toch correct? Hoezo is deze dan ook weer niet goed? Welnu, stel je voor dat je afhankelijk bent van eens screenreader en je krijgt op iedere pagina tenminste vijf keer “streep, streep, streep, streep, streep, streep, streep, streep” voorgelezen. Ik weet zeker dat deze zin al geen verademing was om te lezen, laat staan dat je ’m vijf keer voorgelezen krijgt. Simpel “streep” zou hier volstaan. Je kunt in dit geval ook de alt-tekst leeg laten, zo’n streep bevat meestal geen informatie die je niet zou mogen missen.

Kortom, het toevoegen van alt-teksten lijkt vooralsnog mensenwerk te zijn. En het enkele feit dát je een alt-tekst hebt gedefinieerd geeft geen enkele garantie op een toegankelijke en bruikbare site. We kunnen in dit geval ook best een stap verder gaan. Je kunt jezelf namelijk de vraag stellen of een beeld relevant is voor het document of slechts een decoratieve functie heeft. Als het beeld slechts een decoratieve functie heeft zal dit beeld namelijk hoogstwaarschijnlijk bij de volgende restyling verloren gaan (in het geval van het derde voorbeeld ligt dit wel voor de hand). Daar kun je je op voorbereiden.

Werk een beeld met slechts een decoratieve functie weg in de achtergrond. Dat is heel simpel: CSS geeft je alle kansen om beeld in de achtergrond te zetten. Je kunt het koppelen aan vrijwel ieder element uit je HTML. Als je dit doet dan zal het beeld ook niet geladen hoeven worden bij de mensen die zonder of met een gedeeltelijke CSS ondersteuning je site bezoeken (denk hierbij aan Netscape4, maar ook aan PDA’s en screenreaders). Grote winst, en daarbij wordt de volgende restyling een fluitje van een cent. Dubbele winst dus. Voor jou en voor je opdrachtgever.

“Spring naar...” en CSS

De term is gevallen, en we gaan nog even door over CSS. Het gebruik van CSS in je site kan prettig zijn voor het onderhouden van je site, want daar gaat meestal een stuk minder tijd in zitten (zie ik hier jouw opdrachtgever een lichte glimlach onderdrukken? Minder tijd = Minder kosten). En het werkt vaak makkelijker om een heldere structuur in je code houden.

Mooi, dan hebben we een duidelijke structuur, we hebben alle opmaak in de CSS gezet, dan zijn we klaar toch? Nee! Want er kan bijvoorbeeld een lange reeks items in de navigatie-structuur staan.

Het maakt voor de toegankelijkheid niet veel uit of je gebruik maakt van CSS of tabellen voor je opmaak. Het gaat er om dat je handig omgaat met de beschikbare middelen. Het is op een groot aantal sites niet te voorkomen dat er een lange lijst met menu-items op iedere pagina terecht komt. Dat is ook helemaal niet erg, tenzij je geen muis kunt besturen of de pagina voorgelezen krijgt. Als je iedere keer dat je naar een nieuwe pagina gaat het hele menu moet uitzitten voordat je bij de relevante content kunt komen wordt snel een vervelende en tijdrovende bezigheid.

Als je kunt ‘springen’ in de pagina voegt dat veel toe voor de bezoeker. Je kunt hiervoor accesskeys toevoegen of een tabindex meegeven aan je links, maar dit kan al snel gecompliceerd worden bij een site waar de content snel wisselt.

Je kunt gemakkelijk teruggrijpen naar een simpele oplossing... Zet een “spring naar menu” of “spring naar content” linkje in de code en verberg deze in je CSS door er “display:none” aan mee te geven. Zo doet Drempels Weg het immers ook, en veel van de sites met het Drempels Weg-waarmerk, en dat voorbeeld kunnen we wel volgen, toch?

Nee, ik ga niet zeuren over direct met een k en ook niet dat je bij zo’n reeks bijna een linkje nodig hebt om al die “Ga direkt naar” over te kunnen slaan. Ik wil het zelfs niet hebben over de toevoeging van een title-tag die hier onnodig is. De title-tag geeft immers de zelfde informatie als de link zelf. Waar ik het wel over wil hebben is dat je de naam “screenreader” vrij letterlijk kunt nemen: een screenreader leest uit wat er op het scherm wordt getoond. Door het (via CSS) verbergen van de links voor het scherm verberg je ze ook voor de screenreader, als de bezoeker niet de optie van het gebruik van CSS heeft uitgeschakeld. Het lijkt er hier dus op dat je de visueel gehandicapte bezoeker een dienst bewijst, maar dat is in veel gevallen niet zo. Hiervoor is wel een eenvoudige oplossing beschikbaar: je kunt je stylesheet importeren, in plaats van het aan je document te linken.

Hiermee help je echter alleen de visueel gehandicapte bezoeker en de bezoeker met een browser die geen of weinig CSS ondersteunt. Wat denk je van de mensen die geen muis kunnen besturen (RSI-klachten, pols gebroken of het touchpad van hun notebook is er simpelweg mee opgehouden)? Houdt toegankelijk bouwen op bij de blinde bezoeker? Het zichtbaar maken van zo’n “spring naar ...” link heeft een belangrijke functie. Voordat je nu direct roept: “MAAR DAT IS HEEL LELIJK!!!”, hou je adem nog even in.

Het is mogelijk om “spring naar” te verbergen tot het gebruikt moet worden. Tom Gilder kwam met een even briljante als simpele oplossing.

a.skip {
position: absolute;
overflow: hidden;
width: 0;
height: 0;
}

a.skip:active, a.skip:focus {
position: absolute;
overflow: visible;
width: auto;
height: auto;
}

Dat is alles... Hoe het werkt kun je in dit voorbeeld zien als je met toetsenbord (tab-toets) van link naar link gaat. De oplossing werkt (nog) niet in iedere browser, maar je zult er een grote groep mensen mee helpen.

Tenslotte

Toegankelijk bouwen is veel meer dan je site laten testen met een online tool. Een site wordt pas toegankelijk als je de beslissingen die je neemt ook kunt verdedigen omdat ze ten dienste staan van iedere bezoeker. Het maakt niet veel uit of er een icoon of waarmerk van toegankelijkheid op de site aanwezig is. Zou jij je laten tegenhouden om informatie op te zoeken of artikelen te kopen op sites zonder waarmerk? Toegankelijk bouwen doe je niet om een award of een waarmerk te krijgen. Toegankelijk bouwen doe je om iedere euro die geïnvesteerd wordt in een website maximaal te benutten.

Meer Lezen

• Accessible Web Sites
• Building Accessible Websites
• Struikelblok - de voordelen van toegankelijk bouwen

• Home
• Artikelen
• Colofon