Website-toegankelijkheid testen: automatisch vs. handmatig

Website-toegankelijkheid test je in twee lagen: een automatische scan die snel de meetbare fouten vindt, en een handmatige controle voor alles wat een mens moet beoordelen. Automatische tools zoals axe-core, Lighthouse en WAVE vinden ontbrekende labels, lege links en foutieve ARIA. Of een alt-tekst klopt, of je checkout met alleen een toetsenbord werkt en of een screenreader je formulier logisch voorleest, ziet geen enkele tool.

Dit artikel hoort bij onze complete gids over website-toegankelijkheid. Hier krijg je een eerlijk beeld van wat automatische tools wel en niet kunnen, een handmatige testroutine in stappen, de officiële evaluatiemethode van het W3C en een advies over hoe vaak je test.

De norm waartegen je test is WCAG, de Web Content Accessibility Guidelines van het W3C. In Europa geldt meestal niveau AA als doel. Welke eisen daar precies onder vallen, lees je in WCAG 2.2 uitgelegd.

#Wat kunnen automatische tools wel?

Automatische toegankelijkheidstools controleren regels die je objectief uit de code kunt afleiden, zoals of een afbeelding een alt-attribuut heeft of een invoerveld een label. Ze zijn snel, herhaalbaar en geschikt om bij elke release te draaien. Drie tools kom je het vaakst tegen.

axe-core is de open-source testbibliotheek van Deque. Volgens de README op GitHub heeft axe-core regels voor WCAG 2.0, 2.1 en 2.2 op niveau A, AA en AAA, plus regels voor best practices. Deque streeft naar nul valse meldingen: een fout die axe-core rapporteert, is in principe ook echt een fout. Twijfelgevallen markeert axe-core als "incomplete", met de opmerking dat handmatige beoordeling nodig is.

Lighthouse zit ingebouwd in Chrome DevTools. Volgens de documentatie over de scoreberekening is de toegankelijkheidsscore een gewogen gemiddelde van automatische audits, met gewichten gebaseerd op de impactinschatting van axe. Elke audit verwijst naar een axe-core-regel. Handmatige controles noemt Lighthouse apart, maar die tellen niet mee in de score.

WAVE van WebAIM toont fouten en aandachtspunten als pictogrammen op je pagina. De browserextensie test de pagina zoals die in je browser is weergegeven, dus ook na het uitvoeren van JavaScript. De helppagina van WAVE zegt het zelf duidelijk: WAVE kan je niet vertellen of je content toegankelijk is, alleen een mens kan dat bepalen.

Hoeveel problemen vindt een automatische tool? Deque publiceerde in 2021 een eigen onderzoek op basis van ruim 2.000 audits. Volgens Deque dekte automatisch testen met axe gemiddeld 57 procent van het aantal gevonden problemen. Twee kanttekeningen: het is onderzoek van de leverancier zelf, en het telt problemen naar volume, niet naar succescriteria. Veelvoorkomende fouten wegen dus zwaar mee. Voor jouw site kan het aandeel hoger of lager uitvallen.

#Wat kunnen automatische tools niet?

Automatische tools kunnen niet beoordelen of iets begrijpelijk, logisch of bruikbaar is, en juist daar zitten veel van de zwaarste drempels. Een paar voorbeelden die geen scanner betrouwbaar opvangt:

• Kwaliteit van alt-tekst. Een tool ziet dat er een alt-tekst staat, niet of "IMG_4032.jpg" of "afbeelding" de foto beschrijft.
• Toetsenbordbediening van eigen componenten. Een uitklapmenu dat alleen op een muisklik reageert, of een pop-up waar de focus in vast komt te zitten, merk je pas als je het zelf probeert.
• Logische focus- en leesvolgorde. De code kan geldig zijn terwijl de focus van de koptekst naar de footer springt.
• Zinvolle foutmeldingen. Een tool ziet niet of "Ongeldige invoer" de bezoeker helpt het probleem op te lossen.
• Gedrag bij zoomen en reflow. Overlappende tekst of afgesneden knoppen bij 400 procent zoom zie je alleen op het scherm.
• Inhoud die pas met JavaScript verschijnt, als de tool alleen de ruwe HTML leest.

Kleurcontrast zit ertussenin. axe-core heeft een contrastregel, maar die werkt alleen op een echt weergegeven pagina. Tekst op een achtergrondafbeelding of verloop levert vaak een "incomplete" op. Meet contrast daarom ook handmatig met een contrastmeter.

#Automatisch of handmatig: per type controle

Per type controle verschilt het sterk hoeveel een automatische tool kan vaststellen. Deze tabel geeft een praktisch overzicht voor de meest voorkomende controles.

De conclusie uit de tabel: automatisch testen is een goede eerste filter, maar een groot deel van de criteria vraagt menselijk oordeel. Een overzicht van de fouten die we in beide lagen het vaakst zien, staat in meest voorkomende toegankelijkheidsfouten.

#Een handmatige testroutine in stappen

Een handmatige basistest vraagt geen specialistische software en vindt juist de problemen die scanners missen. Doe deze stappen voor elk type pagina: home, categorie, product, formulier en checkout.

1. Leg je muis weg. Navigeer met Tab, Shift+Tab, Enter, spatie en de pijltjestoetsen. Bereik je elke link, knop en elk veld? Is de focus steeds zichtbaar? Kun je menu's, pop-ups en de cookiebanner openen en weer sluiten zonder vast te lopen?
2. Controleer de volgorde. Volgt de focus de visuele leesvolgorde? Begint de pagina met een skiplink naar de hoofdinhoud?
3. Zoom naar 200 procent. Gebruik de zoom van je browser. Volgens WCAG 2.2 (criterium 1.4.4) moet tekst tot 200 procent te vergroten zijn zonder verlies van inhoud of functie.
4. Test reflow bij 400 procent. Zoom op een venster van 1280 pixels breed naar 400 procent; dat komt overeen met 320 CSS-pixels. Criterium 1.4.10 vraagt dat de inhoud dan zonder horizontaal scrollen leesbaar blijft, behalve bij inhoud zoals tabellen of kaarten.
5. Meet contrast. Gebruik een contrastmeter of de kleurkiezer in DevTools. Normale tekst heeft minimaal 4,5:1 nodig, grote tekst 3:1 (criterium 1.4.3).
6. Luister met een screenreader. Gebruik NVDA op Windows of VoiceOver op een Mac of iPhone. Loop de koppen door, open een formulier en verstuur het met een fout. Worden labels, verplichte velden en foutmeldingen voorgelezen?
7. Controleer formulieren apart. Hebben velden zichtbare labels, kloppen de autocomplete-waarden en verschijnt een foutmelding als tekst bij het juiste veld? Daarover meer in toegankelijke formulieren en checkout.
8. Noteer wat je vindt. Schrijf per probleem de pagina, het criterium, de stappen om het te reproduceren en de ernst op. Die lijst gebruik je ook voor je toegankelijkheidsverklaring opstellen.

Als eerste kennismaking kun je ook de Easy Checks van het W3C volgen. Die waarschuwen zelf dat een pagina deze snelle checks kan doorstaan en toch nog grote drempels kan hebben.

#De WCAG-EM-methode van het W3C

WCAG-EM is de evaluatiemethode van het W3C om vast te stellen in hoeverre een website of digitaal product aan WCAG voldoet. Volgens de overzichtspagina van het W3C is WCAG-EM 2 gepubliceerd op 23 juli 2026, als W3C Group Note. De methode voegt geen nieuwe eisen toe aan WCAG, maar beschrijft hoe je een beoordeling opzet. Versie 2 breidt de aanpak uit van websites naar apps en andere digitale producten.

De methode kent vijf stappen:

1. Bepaal de reikwijdte: wat valt onder de beoordeling, wat is het doel en welk niveau (A, AA of AAA)?
2. Verken het product: welke belangrijke schermen, functies, soorten content en technologieën zijn er?
3. Kies een representatieve steekproef: een gestructureerde selectie aangevuld met willekeurige pagina's, als je niet alles kunt testen.
4. Evalueer de steekproef: toets elke pagina tegen de succescriteria en leg vast hoe je hebt getest.
5. Rapporteer de bevindingen: bundel de resultaten en formuleer je conclusies.

Het W3C biedt hiervoor een gratis WCAG-EM Report Tool aan. Voor een webshop is stap 3 de belangrijkste: neem in elk geval het volledige bestelproces mee, van productpagina tot bevestiging.

#Testen met mensen met een beperking

Gebruikerstests met mensen met een beperking vinden bruikbaarheidsproblemen die een conformiteitstoets tegen WCAG niet aan het licht brengt. Het W3C geeft in Involving Users in Evaluating Web Accessibility een paar duidelijke adviezen.

• Los eerst de voor de hand liggende fouten op, zodat testers niet vastlopen op iets wat je zelf had kunnen vinden.
• Betrek gebruikers al tijdens de ontwikkeling, niet pas aan het eind.
• Ga er niet van uit dat één persoon spreekt voor iedereen met dezelfde beperking.
• Combineer gebruikerstests altijd met een beoordeling tegen WCAG, want gebruikerstests alleen bepalen niet of je site voldoet.

Voor een mkb-webshop hoeft dit geen groot onderzoek te zijn. Drie of vier sessies waarin iemand met een screenreader, een vergrotingsprogramma of alleen een toetsenbord een product bestelt, leveren vaak al concrete verbeterpunten op.

#Hoe vaak test je?

Hoe vaak je test, hangt af van hoe vaak je site verandert, maar een vaste cyclus in drie lagen werkt voor de meeste bedrijven.

Let vooral op wijzigingen die buiten je ontwikkelteam om gaan. Een nieuwe chatwidget, een andere cookiebanner of een betaalstap van een externe partij kan een toegankelijke site in één keer minder toegankelijk maken.

#Waar Flowproof in dit proces past

Flowproof is de automatische eerste laag, geen vervanging van handmatig testen. De toegankelijkheidscontrole draait axe-core op de HTML van je pagina en toetst aan WCAG 2.0, 2.1 en 2.2 op niveau A en AA. Per gevonden regel zie je het succescriterium, het niveau en de ernst.

Wat de scan bewust niet doet: kleurcontrast automatisch meten. Daarvoor is een echte weergave in een browser nodig, dus Flowproof meldt contrast als handmatig te controleren. Bouwt je pagina de inhoud pas met JavaScript op, dan waarschuwt de scan dat alleen de basis-HTML is getest. Daarnaast controleert Flowproof of je een link naar een toegankelijkheidsverklaring hebt, of er een skiplink is en of er geluid automatisch afspeelt. De toegankelijkheidsscore staat los van de GEO-score.

#Zo controleer je dit op je eigen site

1. Draai een automatische scan op je homepage, een categoriepagina, een productpagina, je contactformulier en elke stap van de checkout.
2. Los de fouten met de hoogste ernst eerst op, zoals ontbrekende labels en knoppen zonder naam.
3. Doe de handmatige routine uit dit artikel op dezelfde pagina's: toetsenbord, zoom 200 procent, reflow 400 procent, contrast en een screenreader.
4. Leg je bevindingen vast met pagina, criterium en ernst, en verwerk bekende problemen in je toegankelijkheidsverklaring.
5. Plan de volgende ronde: automatisch bij elke release, handmatig bij nieuwe onderdelen en een volledige beoordeling volgens WCAG-EM eens per jaar.

De toegankelijkheidscontrole van Flowproof zit in de betaalde abonnementen Pro en Business. Je kunt gratis starten en de abonnementen vergelijken op de prijzenpagina.