Webtoegankelijkheid voor gevorderden

Braille displayVeel webmasters en developers zijn inmiddels wel bekend met de 16 basis-toegankelijkheidsrichtlijnen van het W3C, in Nederland beter bekend als het waarmerk Drempelvrij. Derek Featherstone, een autoriteit op het gebied van webtoegankelijkheid, gaf vorige week op de IA Summit 2007 een workshop voor ‘gevorderden’. Featherstone had veel praktijkvoorbeelden en goede tips, die ik hier graag deel. In een aantal gevallen gaat het om zaken die technisch gezien wel toegankelijk zijn, maar toch onwerkbaar zijn voor bepaalde groepen gebruikers.

Beste bedoelingen met een onbewuste drempel

Voorbeeld 1

Voorbeeld van plaatje met tekstlabel
Fout: <img ... alt="Alle producten" title="" />
Goed: <img ... alt="Alle producten" />

Deze constructie wordt regelmatig gebruikt door developers. De reden: design. Het voorkomt dat in Internet Explorer de alt-text wordt getoond als je met je muis boven het plaatje zweeft. Maar helaas hebben slechtziende mensen daar last van. Omdat ze niet blind zijn, hoeven ze geen screenreader te gebruiken, maar ze maken de tekst op het scherm zo groot mogelijk en gebruiken vaak ook software waarmee ze met een soort vergrootglas op een deel van het scherm kunnen inzoomen. Helaas schalen plaatjes niet mee, dus als het verschijnen van de alt-tekst wordt onderdrukt door het title-attribuut, kunnen deze mensen het label dus niet lezen.

Voorbeeld 2

Voorbeeld van plaatje met tekstlabel
Fout: <a href="..." mce_href="..."><img ... alt="Producten"></a>
Goed: <a href="..." mce_href="..."><img ... alt="Alle producten"></a>

Als je een hyperlink maakt van een plaatje met daarop een tekst (b.v. een knop), maak dan de alt-tekst identiek aan de tekst in het plaatje. Mensen die b.v. lichamelijk gehandicapt zijn en spraakherkenningssoftware gebruiken, zullen de tekst oplezen die ze op het plaatje zien. Maar de spraakherkenningssoftware reageert alleen op de link-tekst, in dit geval de alt-tekst van het plaatje.

Voorbeeld 3

Fout: <a href="..." mce_href="...">[PDF]</a>
Goed: [<a href="..." mce_href="...">PDF</a>]

Wie heeft dit niet gebruikt? Helaas, ook dit kan problemen opleveren. Op zich zijn screenreaders in staat om bepaalde karakters zoals de blokhaak te negeren bij het voorlezen. Tot zover geen probleem. De gebruiker hoort gewoon “link. PDF”. Maar als hij vervolgens de lijst met alle hyperlinks op de pagina opvraagt (en dat kan in veel screenreaders), staat de hyperlink niet onder de ‘P’ van PDF. Heel verwarrend voor een blinde.

Voorbeeld 4

Fout: <a href="#top">Naar begin</a>
Goed: <a href="#content">Naar begin</a>

We plaatsen niet voor niets een “direct naar de content”-link in onze code. Het stelt gebruikers van screenreaders (blinden) in staat om alle tijdrovende navigatie-elementen over te slaan. Maar als we in de content een #top-link gebruiken, gaat die weer helemaal terug naar het begin van de code, dus voor de navigatie. Waarom linken we niet naar waar de content begint? Dat is in negen van de tien gevallen waar we in de praktijk eigenlijk altijd naar terug willen als we de #top-link gebruiken.

Formulieren

Voorbeeld 5

Voorbeeld van een formulier met labels, invoervelden en invultips

Dit is een formulierlayout die regelmatig gebruikt wordt: een label, een invoerveld en een hint hoe het invoerveld in te vullen. In veel gevallen worden formulieren wel in technische zin toegankelijk gebouwd, maar missen de blinden de invoerhints. Hoe komt dat?

Wellicht weet je al dat de W3C-richtlijnen voorschrijven dat je labels expliciet moet koppelen aan invoervelden, namelijk als volgt:

<label for="uname">Username</label>
<input id="uname" … />

Maar net als iedereen gebruiken screenreader-gebruikers de ‘tab’ om van veld naar veld te navigeren. Sterker nog, sommige screenreaders hebben een ‘formulier’-modus die alleen formulier-elementen toont. Dus in beide gevallen missen blinden de hints als we die pas na het input-element plaatsen. De oplossing: neem het op in het label. Zo link je het semantisch aan het veld.

<label for="uname">
    Username
    <em>Mag geen spaties bevatten</em>
</label>

Hetzelfde geldt voor foutmeldingen:

<label for="uname">
    Username
    <strong>Fout: bevat spaties</strong>
</label>

En voor de layout hoef je het niet te laten. Met CSS kun je de ‘em’ en ‘strong’ elementen eenvoudig rechts, boven of onder het veld uitlijnen. Voor meer uitleg, zie http://simplyaccessible.org/article/form-error-messages.

Maar zelfs als je met JavaScript direct na het weg-tabben de foutmelding presenteert, is de kans groot dat een screenreader-gebruiker de melding niet ziet. De focus is immers al op het volgende veld. Een goede strategie hiervoor is dat je met JavaScript niet alleen de foutmelding in het label zet, maar ook “Fout: veldnaam” in het legend-attribuut van de fieldset. Die wordt nl. meteen voorgelezen als die verandert. Andere mogelijkheden zijn: de tekst in de paginatitel en/of in de statusbalk veranderen, of een (expliciet) label toevoegen aan de submit-knop.

Het is wellicht opgevallen dat ik het woord ‘JavaScript’ al twee keer gebruikt heb. De W3C-richtlijnen zeggen dat alles ook moet werken zonder JavaScript. Maar het feit is dat de meeste screenreaders prima met bovenstaande oplossing omgaan en het vergroot enorm de usability van het formulier voor de gebruikers van die software. En wat betreft de richtlijnen: zonder JavaScript voldoet je formulier gewoon aan de richtlijnen.

Nog een paar tips betreffend formulieren:

  • Als je 3 invoervelden hebt die eigenlijk aan hetzelfde label moeten hangen, zoals datum: dag/maand/jaar: Maak een extra fieldset om deze velden heen getiteld ‘Datum’ en maak expliciete labels per veld (“dag”, “maand”, “jaar”) die je met CSS buiten het zichtbare scherm positioneert (b.v. -900em). Op die manier belast je ziende mensen niet met overtollige labels en presenteer je aan screenreaders wel die labels. En het is semantisch helemaal correct.
  • Als je in een formulier twee kolommen gebruikt, of velden achter elkaar plaatst, denk dan aan het toevoegen van een zoom layout voor mensen met tunnelvisie (zie voorbeeld).
  • Gebruik geen JavaScript om bij het laden de cursor direct naar een invoerveld te brengen, want dan kan de gebruiker niet de backspace-toets gebruiken om terug te gaan naar de vorige pagina. De enige uitzondering hierop vormen specifieke pagina’s als een inlogpagina.
  • Gebruik geen vooringevulde invoervelden (zoals “Typ hier uw trefwoord”) die je met JavaScript leegmaakt zodra de gebruiker op dat veld focust, want dat geeft problemen als de gebruiker het veld heeft ingevuld, door-tabt naar het volgende veld en met shift+tab weer terugspringt. Vaak wordt de invoer dan weer door diezelfde JavaScriptie-functie gewist.

In deel 2: Toegankelijkheidstips voor zoeken en navigeren. Plus aandacht voor AJAX.