Reeds in een vroeg stadium hield ik mij bezig met de semantiek van websites. Het was zelfs -in 2006- de tweede artikel ooit van mijn hand. Naast mijn backend werkzaamheden, is de affiniteit voor de frontend en daarmee ook toegankelijkheid van websites, niet verloren gegaan.
Stichting Accessibility
In het verlengde van die interesse, heb ik mijn afstudeerstage in 2009 bij Stichting Accessibility plaats laten vinden. Stichting Accessibility houdt zich bezig met toegankelijkheid van websites en apps in de breedtste zin. Denk bijvoorbeeld aan self-service palen van de NS, online games, video's en uiteraard websites. Hier heb ik veel kennis opgedaan omtrent toegankelijkheid in het algemeen en heeft er voor gezorgd dat de semantiek van HTML en daarmee websites altijd in een hoog vaandel bleef staan.
Toegankelijkheid: een valkuil
Met een verschuiving naar de backend kant van webapplicaties, wordt de toegankelijkheid van een web-omgeving makkelijk een valkuil. De doelgroep is soms beperkt en soms dusdanig specifiek, dat hier geen aandacht naar uit hoeft te gaan. Door echter semantisch te blijven werken, hoeft de stap naar een volledig toegankelijke website niet groot te zijn. En hoe gaan frameworks om met toegankelijkheid?
Webrichtlijnen verplicht
Maar ook bij websites is de toegankelijkheid vaak een valkuil. Voor websites van overheidsinstanties, geldt dat ze reeds sinds 1 januari 2015 moeten voldoen aan de webrichtlijnen. Alhoewel het onrealistisch is deze wet in zijn geheel voor alle websites uit te rollen, zou er op zijn minst in een aanbestedingstraject bij stil gestaan moeten worden. In praktijk wordt de aandacht vooral gelegd op het visuele aspect. De eenvoudig te implementeren thema's binnen CMS'en als Wordpress, werkt dit in de hand. Dit terwijl op technisch vlak veel te winnen valt.
Toegankelijkheid testen
Het testen kan gewoonweg vanuit je bureaustoel. Mijn eerste stap was het downloaden van de Chrome pluginAccessibility Developers Tool. Daarnaast heb ik mijn website door online tests gegooid. Via de volgende websites kun je een webpagina testen:
- tenon.io (overzichtelijke feedback);
- acchecker.ca (kaart ook potentiele issues aan);
- wave.webaim.org (goed gevisualiseerd);
- powermapper.com (gaat in verhouding meer in op CSS gebruik)
Een test in tenon.io leverde in de basis enkele eenvoudig te tackelen zaken op, zoals het gebruik van correcte hyperlinks en meer verduidelijking van links/knoppen. Zo had de link die je aantreft bij mouseover over de kop "Toegankelijkheid testen", geen beschrijvende tekst, waar het doel van deze link voor mensen zonder screenreader, snel duidelijk zal zijn (namelijk, een vaste verwijzing naar het betreffend subonderdeel binnen dit artikel).
Toegankelijkheid gaat verder dan een automatisch test
Toegankelijkheid gaat echter verder dan enkel automatische tests. Een test kan niet daadwerkelijk menselijke handelingen, of een screenreader nabootsen. Soms kun je meer beschrijving mee geven aan knoppen dan je denkt. Ook worden soms te veel zaken aangekaart (zoals acchecker.ca).
Een tool dat dan ook niet kan ontbreken in het testen, is een screenreader. Voor Nederlandse websites zijn de opties onder meer JAWS (betaald) of NVDA. Ga na hoe screenreader-gebruikers een webpagina voorgelezen krijgen. Valt er uberhaupt te navigeren wanneer je enkel gebruik maakt van je toetsenbord? En hoe krijg je informatie voorgelezen? Zijn visueel vormgegeven knoppen ook werkelijk selecteerbaar?
WAI ARIA
Daar waar de semantiek van HTML te kort schiet om hierin te voorzien, kun je de WAI ARIA specificatie er op na slaan. Hierin vind je gebruik van attributen en rollen terug, om HTML elementen te verrijken met bijvoorbeeld aanvullende uitleg en statussen. Ook wanneer je reeds semantisch te werk gaat, zal het gebruik van aria-attributen een aanvulling zijn.
