Hoe test ik de toegankelijkheid van mijn website?
Top! Je wil testen of je website toegankelijk is voor iedereen. Daarmee help je niet alleen de mensen met een beperking, waarvan er steeds meer zijn in onze vergrijzende maatschappij. Een toegankelijke website is voor iedereen fijner in gebruik, en er zijn nog veel meer goede redenen om met toegankelijkheid aan de slag te gaan.
Geef mij maar een uitdaging!
Je zou de Web Content Accessibility Guidelines (WCAG) door kunnen nemen. Deze richtlijn van het W3C is verankerd in regelgeving en is internationaal de standaard voor toegankelijkheid. Als je dit document tot je wil nemen ben je wel even bezig. WCAG bestaat uit 4 principles met 13 guidelines die onderverdeeld zijn in 78 success criteria. En die gaan dan weer gepaard met een paar honderd "techniques and failures". Je voelt hem misschien al aankomen: de meest gebruikte richtlijn is niet het meest toegankelijke startpunt.
Vijf simpele tests om de toegankelijkheid van mijn website testen
Er zijn vijf relatief simpele checks die veel op kunnen leveren. Deze testjes zorgen ervoor dat je met weinig moeite heel wat problemen kunt onderscheppen. Gebruik hierbij de termen "quick wins" en "laaghangend fruit" en iedereen zal je begripvol aankijken.
Simpele test 1: Kleur en contrast
De tekst op je pagina moet leesbaar zijn voor iedereen. Een goed contrast helpt niet alleen mensen die slechtziend of kleurenblind zijn, maar bijvoorbeeld ook bezoekers die met hun mobieltje in de zon staan of hun scherm gedimd hebben. Het testen van kleur en contrast is dan ook een waardevolle stap naar toegankelijkheid.
WCAG laat voor grote tekst een lagere contrastwaarde toe dan voor kleine tekst. Grote tekst is in dit geval minimaal 24px, of minimaal 19px en bold. Voor grote tekst moet het contrast minimaal 3.0:1 zijn, en voor normale tekst 4.5:1.
Nu kan ik me voorstellen dat je je bij deze getallen niks kan voorstellen. Gelukkig zijn er tal van tools die je precies kunnen vertellen hoeveel contrast er tussen twee kleuren zit. Je kunt twee kleuren invoeren op de website contrast-ratio.com, je Chrome developer tools gebruiken, of een los programma zoals Contrast Analyser downloaden.
Als je eenmaal een tool gekozen hebt kun je alle teksten op je website nagaan.
Simpele test 2: Zoom in en uit
Heel veel mensen zijn erbij gebaat als er fatsoenlijk in te zoomen is op je website. De site mag dan best overspringen naar een tablet of mobiele versie als die er is. De basis van toegankelijkheid is dat iedereen dezelfde inhoud en functionaliteit kan gebruiken, dus let wel op dat je responsive website een volwaardig alternatief is! Dit kun je gemakkelijk testen met de zoomopties in je browser.
Simpele test 3: Gebruik je toetsenbord
Een deel van je bezoekers zal gebruiken maken van zogenaamde assistive technology (AT), ondersteunende technologie. Veel van die technologie communiceert met de browser via de toetsenbord API. Kort gezegd: als je website met een toetsenbord te bedienen is maak je veel mensen blij. Daarbij horen ook bezoekers met een kapotte muis, een gebroken arm en power users.
Test dus even met je toetsenbord of alles werkt. Ga met TAB door je pagina, en weer terug met SHIFT-TAB. Kijk of je al je interactieve elementen (knoppen, links, formulieren, etc) kan bereiken, en of je ze kan bedienen. Let ook goed op of het altijd zichtbaar is welk element de focus van je toetsenbord heeft.
Simpele test 4: Doe een automatische test
Misschien vraag je je af, waarom testen we niet alles automatisch? Een beetje gezonde luiheid kan geen kwaad. Helaas is alles automatisch testen bij toegankelijkheid geen optie. Een test kan bijvoorbeeld wel zien of een afbeelding een tekstalternatief heeft, maar niet of de tekst ook daadwerkelijk de lading dekt.
Het exacte getal varieert afhankelijk van wie je het vraagt, maar ga er van uit dat zo'n 30% van alle issues automatisch getest kan worden. Gelukkig zitten daar wel een aantal veel voorkomende tussen, dus de winst is alsnog flink.
Er zijn verschillende tools die je kan gebruiken. Zelf ben ik een erg tevreden gebruiker van aXe. Deze Javascript library kun je overal in de developer workflow inzetten. Bijvoorbeeld in je linting tool, bij je andere tests, of als browser extension.
De laatste optie is misschien wel de makkelijkste om mee te beginnen. De aXe extensie geeft je developer tools een nieuw tabje met een mooie analyze-knop. Na een druk op de knop krijg je alle issues te zien. Ik zou eerst filteren op "Violations" in plaats van "All issues", dat maakt het een stuk praktischer. Vervolgens krijg je een overzichtelijke lijst met issues inclusief omschrijving, locatie, oplossing en een hele waardevolle "Learn more"-link waar enorm veel nuttige informatie achter zit.
Simpele test 5: Screen reader
Bij assistive technology denken men al snel aan screen readers. Een screen reader is software die kan voorlezen wat er op een scherm te zien is, en hier doorheen kan navigeren. Deze software wordt onder andere door blinden en slechtzienden gebruikt. Zo'n screen reader is een flink andere gebruikerservaring dan de meeste mensen hebben. Zeker als je de eerste keer een screen reader start en je computer begint een heel verhaal, dan kan dat even wennen zijn.
Ervaring leert echter dat je helemaal niet veel van een screen reader hoef te snappen om er praktisch mee te testen. Eigenlijk wil je ongeveer hetzelfde doen als eerder met je toetsenbord. Je navigeert door de pagina om te zien (of horen) of je alles kan bereiken, en of je alles kan bedienen. Extra controlepunt is nu of alle onderdelen die je bereikt een logische naam en rol hebben. Een knop moet bijvoorbeeld voorgelezen worden als "button" en niet als "clickable" of "link". Daarnaast moet de button een naam hebben die past bij de functie. Een menu knop kan bijvoorbeeld voorgelezen worden als "Menu, button".
Wat je met een screen reader hoort, moet overeenkomen met wat visueel aanwezig is.
Op MacOS heb je VoiceOver dat het beste resultaat geeft met Safari. Bekijk de VoiceOver cheatsheet bij Deque.
Op Windows heb je onder andere NVDA dat het beste werkt met Firefox. Bekijk de NVDA cheatsheet bij Deque.
Ok, dan ben ik klaar!
Nee helaas, zo simpel is het niet. Maar je hebt nu wel een stevige basis. Zorg dat je semantische HTML gebruikt, volg standaarden en denk bij alles wat je maakt na of het mogelijk mensen met een beperking beïnvloedt.
En om af te sluiten nog een aantal praktische bronnen voor als je nog meer wil weten toegankelijkheid.
Bronnen
W3C - WAI - Introduction to Web Accessibility
W3C - WAI - Web Accessibility Tutorials
Future Learn - Digital Accessibility
GOV.UK - Dos and don'ts on designing for accessibility
W3C - WAI - How to Meet WCAG 2 (Quick Reference)
Over Erik Kroes 
Erik is onderdeel van het accessibility team van ING. Elke dag probeert hij weer zijn steentje bij te dragen aan de digitale toegankelijkheid van de apps en websites. Daarnaast is hij creatief actief en maakt hij onder andere illustraties voor de Volkskrant.
Donatie: de Hersenstichting
Reacties
- 1 Stomme poes op 10-12-2018 om 13:00 uur:
- Veel mooi tips, het beste is dat de meeste kan gedaan worden door ieder gewone mens zonder iets bijzonders te weten. Vaak krijgen developers het gevoel dat alles met toegankelijkheid heel moeilijk en te gespecialieseerd is om aan te pakken, en weten niet waar ze moeten beginnen. Dit artikel dus!
Behalve een ding (in mijn opinie:)
> Ervaring leert echter dat je helemaal niet veel van een screen reader hoef te snappen om er praktisch mee te testen.
Helaas als tester heb ik zo. veel. slechte. code gezien waarin iemand dacht, zonder echt in te diepen om een software goed te leren kennen of hoe mensen gebruik maken van de software, dat bepaalde dingen moet toegevoegd worden die alles alleen slechter maken; of werken heel erg hard aan bvb het word "clickable" weg te doen (als het Good Practice is om je event listeners op de body element of ander container te zetten, dan kan alles en nog wat op de pagina "clickable" meerdere keren uitroepen. Dit is een bekende (NVDA) bug, maar niet per se bekende door web developers).
Meestal zie ik veel te veel dingen in de tab order gezet ("zodat mensen met schermlezers alle kunnen bereiken"). Heel veel onzichtbare tekst (bedoelde om alles en nog wat uit te leggen aan blinden). Heel veel onnodig ARIA-foo, alsof het een soort oplossingszout voor web toegankelijkheid is...
Zelf zou ik 'testen met een screenreader' alleen aanraden aan developers die wel een beetje tijd kan insteken over hoe een complexe software werkt (hoeft niet alles te kennen, ik bedoel toch alleen de basis!) en hoe mensen ze omgaan met de software (hier ook alleen de basis, want elk gebruiker is natuurlijk anders).
Ik heb wel een mooi voorbeeld gezien bij een grote bedrijf (KaiserPermanente) die wilde wel dat een screen reader door QAE's gebruikt was om toegankelijksfouten te vinden, maar dat was toch na een twee-dagse training met VoiceOver en alleen dan op iOS. Dit was om contractors (die al na 6-8 maanden weg gaan) genoeg basis kennis om te weten wat ze wel en niet moeten opletten. Met zo'n basis training kan ieder developer wel hun eigen code testen met screenreader met goede resultaten. Of kunnen developers zelf laten indiepen, maar dat komt bovenop alle andere dingen die ze in z'n vrije tijd moeten leren (ik wijs naar Toms artikel)... - 2 Roel Van Gils op 10-12-2018 om 14:56 uur:
- Heel heldere 101! 👌