Hoe webtoegankelijkheid te testen: geautomatiseerde tools, handmatig testen en schermlezers

De cijfers zijn moeilijk te negeren. Volgens het WebAIM Million-rapport van 2026 detecteerden geautomatiseerde scans van één miljoen homepages meer dan 56 miljoen afzonderlijke toegankelijkheidsfouten — een gemiddelde van 56,1 fouten per pagina, meer dan 10% hoger dan het jaar ervoor. En omdat geautomatiseerde tools slechts ongeveer 30–40% van de mogelijke WCAG-overtredingen kunnen opsporen, is de werkelijke omvang van het probleem aanzienlijk groter. Als je toegankelijkheidsteststrategie begint en eindigt met één enkele scan via een browserextensie, zie je slechts een fractie van de barrières waar je gebruikers dagelijks mee te maken hebben.

Waarom een meerlaagse teststrategie onmisbaar is

Webtoegankelijkheid testen is geen eenmalige gebeurtenis — het is een discipline die tools, menselijk oordeel en geleefde ervaring omvat. De Web Content Accessibility Guidelines (WCAG) zijn gebaseerd op vier fundamentele principes, vaak samengevat als POUR: content moet Perceivable (waarneembaar), Operable (bedienbaar), Understandable (begrijpelijk) en Robust (robuust) zijn. Geautomatiseerde tools kunnen verifiëren dat een afbeelding een alt-attribuut heeft, maar ze kunnen niet beoordelen of die alt-tekst de afbeelding daadwerkelijk zinvol beschrijft. Een script kan bevestigen dat een knop een label heeft, maar het kan je niet vertellen of een schermlezergebruiker in de context begrijpt wat er gebeurt als je erop drukt.

Dit is waarom elk serieus toegankelijkheidsprogramma drie verschillende benaderingen stapelt: geautomatiseerde scanning om systematische, herhaalbare overtredingen op schaal te vinden; handmatig testen om beoordelingsafhankelijke criteria te evalueren die een menselijk brein vereisen; en testen met ondersteunende technologie — met name schermlezers — om de echte gebruikerservaring te valideren van mensen die dagelijks van deze tools afhankelijk zijn. Elke laag compenseert de blinde vlekken van de andere. Als je er één overslaat, blijven er gaten over die uiteindelijk naar boven komen als gebruikersklachten, mislukte audits of juridische risico’s.

WCAG 2.2, de huidige W3C-standaard sinds eind 2023, legt meer nadruk op bruikbaarheid voor toetsenbordnavigatie, touch-interacties en cognitieve toegankelijkheid, terwijl alle bestaande WCAG 2.1-vereisten behouden blijven. Ertegen testen is voor de meeste organisaties niet optioneel — het wordt in toenemende mate verplicht door regelgeving, van de ADA in de Verenigde Staten tot de European Accessibility Act, die in juni 2025 van kracht werd. Begrijpen hoe je moet testen is de praktische basis die naleving haalbaar maakt.

Geautomatiseerd testen: je eerste verdedigingslinie

Geautomatiseerde tools versnellen het testproces en integreren naadloos in CI/CD-pijplijnen, waardoor teams toegankelijkheidsfouten vroeg en vaak kunnen opsporen en corrigeren. Je kunt ze het beste zien als een filter — ze zullen niet alles vinden, maar ze sporen de meest voorkomende, best meetbare overtredingen betrouwbaar op en met een snelheid die geen enkele menselijke reviewer kan evenaren. Zie ze als een spellingscontrole: essentieel, maar geen vervanging voor een vaardige redacteur.

De meest voorkomende categorieën problemen die geautomatiseerde tools betrouwbaar detecteren, zijn onder andere ontbrekende of lege alt-tekst bij afbeeldingen, onvoldoende kleurcontrastverhoudingen, formuliervelden zonder gekoppelde labels, lege link- of knoptekst, ontbrekende taaldeclaraties op de pagina en dubbele of ontbrekende kopstructuren. Volgens de WebAIM Million-data valt 96,4% van de gedetecteerde fouten in slechts zes categorieën — wat betekent dat geautomatiseerde tools, consequent toegepast, al een aanzienlijke deuk kunnen slaan in je aantal overtredingen voordat een menselijke reviewer de interface überhaupt bekijkt.

Belangrijke geautomatiseerde testtools

axe-core / axe DevTools (Deque Systems) is waarschijnlijk de meest gebruikte toegankelijkheidstestengine in de sector. De open-source kern is ingebed in tientallen andere tools en testframeworks. De browserextensie werkt in Chrome, Firefox en Edge en geeft ontwikkelaars directe feedback op de gerenderde DOM. Voor engineeringteams integreert axe-core met Cypress, Playwright, Selenium en Jest, waardoor het eenvoudig is om toegankelijkheidscontroles rechtstreeks in je bestaande testsuite op te nemen.

WAVE (WebAIM) is een browserextensie en online evaluatietool die visuele feedback in de pagina geeft met kleurgecodeerde iconen die direct over je content worden gelegd. Het is bijzonder geschikt voor content editors en niet-technische stakeholders die toegankelijkheidsproblemen moeten begrijpen zonder code te lezen. WAVE markeert fouten, waarschuwingen, structurele elementen en ARIA-rollen op een manier die de relatie tussen markup en gebruikerservaring direct zichtbaar maakt.

Google Lighthouse is direct ingebouwd in Chrome DevTools en voert toegankelijkheidsaudits uit naast performance-, SEO- en best practice-controles. Het is uitstekend voor snelle front-end audits tijdens ontwikkeling en kan via de command line worden uitgevoerd voor CI-integratie. De toegankelijkheidsscore wordt onder de motorkap aangedreven door axe-core, waardoor het overlappende maar niet identieke gebieden bestrijkt.

Pa11y is een command-line tool en Node.js-bibliotheek die is ontworpen voor integratie in pijplijnen. Het ondersteunt zowel axe als de HTML_CodeSniffer-engine, kan meerdere URL’s testen vanuit een configuratiebestand en genereert machineleesbare rapporten die geschikt zijn voor dashboards of ticketsystemen. Het is bijzonder nuttig voor het monitoren van grote sites of voor organisaties die regelmatig URL’s in bulk moeten auditen.

axe integreren in je CI/CD-pijplijn

De meest effectieve manier om regressies in toegankelijkheid te voorkomen, is ze te behandelen als elke andere bug — vang ze voordat ze productie bereiken. axe-core integreren in je CI-pijplijn betekent dat elke pull request automatisch wordt gescand, en builds kunnen zo worden geconfigureerd dat ze falen wanneer het aantal overtredingen de acceptabele drempels overschrijdt. Hier is een minimaal voorbeeld met Playwright en het @axe-core/playwright-pakket:

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test.describe('Homepage accessibility', () => {
  test('should have no automatically detectable WCAG violations', async ({ page }) => {
    await page.goto('https://your-site.com/');
    const results = await new AxeBuilder({ page })
      .withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
      .analyze();
    expect(results.violations).toEqual([]);
  });
});

Deze test navigeert naar je applicatie, draait axe-core op de gerenderde pagina, beperkt tot WCAG 2.x Level A- en AA-regels, en faalt als er overtredingen worden gevonden. Je kunt dit koppelen aan een GitHub Actions-workflow zodat het bij elke push naar main of bij elke pull request wordt uitgevoerd. Houd er rekening mee dat je, wanneer je voor het eerst geautomatiseerde toegankelijkheidstests toevoegt aan een volwassen project, mogelijk tientallen bestaande problemen ontdekt. In plaats van alle deploys direct te blokkeren, configureer je een baseline voor het aantal overtredingen en trek je de drempel geleidelijk aan strakker terwijl je ze oplost.

Belangrijke beperking: Geautomatiseerde tools vangen ongeveer 30–40% van de WCAG-overtredingen. Ze zijn noodzakelijk maar niet voldoende. Handmatig testen is essentieel om de volledige omvang van toegankelijkheidsbarrières bloot te leggen.

Handmatig testen: wat machines niet kunnen beoordelen

Handmatig testen vult de gaten op die geautomatiseerde tools structureel niet kunnen dichten. Het vereist een tester — idealiter iemand die is getraind in WCAG en vertrouwd is met ondersteunende technologieën — die pagina’s en interacties doorloopt met een gedefinieerde methodologie. Het doel is niet om opnieuw te verifiëren wat de geautomatiseerde scanner al heeft gevonden, maar om de criteria te evalueren die menselijk oordeel vereisen: Is de leesvolgorde logisch? Is het focusbeheer logisch nadat een modal opent? Is de foutmelding echt behulpzaam, of staat er alleen "ongeldige invoer"?

Een praktische handmatige testsessie bestrijkt verschillende afzonderlijke gebieden. Het eerste is navigatie met alleen het toetsenbord. Koppel je muis los en navigeer je volledige interface met alleen Tab, Shift+Tab, Enter, Spatie en pijltjestoetsen. Elk interactief element — links, knoppen, formuliervelden, dropdownmenu’s, datepickers, modals, tabs — moet bereikbaar en bedienbaar zijn zonder muis. De focus mag nooit vast komen te zitten (tenzij opzettelijk, zoals in een modal die de focus moet vasthouden). De zichtbare focusindicator moet duidelijk genoeg zijn om te volgen. WCAG 2.2 voegde Succescriterium 2.4.11 Focus Appearance toe, dat een minimale grootte- en contrastvereiste voor focusindicatoren vastlegt — dit is bijna altijd een handmatige controle.

Het tweede gebied is review van content en structuur. Lees de pagina door met een kritische blik op de koppenhiërarchie. Koppen moeten de structuur van de pagina weergeven — <h1> voor de paginatitel, <h2> voor hoofdsecties, <h3> voor subsections — zonder niveaus over te slaan. Controleer of linktekst op zichzelf beschrijvend is ("Download het Jaarverslag 2025" is goed; "klik hier" niet). Controleer of afbeeldingen met betekenisvolle inhoud een accurate alt-tekst hebben, en of decoratieve afbeeldingen een leeg alt-attribuut hebben (alt=''). Bekijk formulierlabels: elke invoer moet een programmatisch gekoppeld label hebben, niet alleen een placeholder.

Het derde gebied is dynamische interacties en ARIA. JavaScript-intensieve interfaces — single-page applications, modals, live zoekresultaten, carrousels, accordeons — creëren toegankelijkheidsuitdagingen die statische scanners regelmatig missen. Wanneer een modal opent, verplaatst de focus zich er dan naartoe? Wanneer hij sluit, keert de focus dan terug naar het element dat hem opende? Wanneer een live region wordt bijgewerkt (een aantal zoekresultaten, een formulier-validatiebericht), wordt dit dan aangekondigd aan ondersteunende technologieën? Verkeerd gebruikte ARIA is een van de meest voorkomende bronnen van regressies in toegankelijkheid. De WebAIM Million-data laat consequent zien dat pagina’s die ARIA-attributen gebruiken gemiddeld aanzienlijk meer fouten hebben dan pagina’s zonder — niet omdat ARIA slecht is, maar omdat het vaak verkeerd wordt geïmplementeerd.

Een praktische checklist voor handmatig testen

• Toetsenbordnavigatie: Tab door elk interactief element; bevestig een logische volgorde, geen focus traps en zichtbare focusindicatoren die voldoen aan WCAG 2.2 SC 2.4.11.
• Kopstructuur: Verifieer een logische hiërarchie zonder overgeslagen niveaus met een browserextensie zoals HeadingsMap of de WAVE-toolbar.
• Link- en knoptekst: Bevestig dat alle interactieve elementen beschrijvende, unieke toegankelijke namen hebben — niet "klik hier" of "meer info" tientallen keren herhaald.
• Formuliertoegankelijkheid: Controleer dat elk veld een expliciet label heeft, foutmeldingen specifiek en programmatisch gekoppeld zijn, en verplichte velden worden aangegeven op een manier die ondersteunende technologieën kunnen overbrengen.
• Kleur en contrast: Controleer handmatig alle tekst of UI-componenten die door geautomatiseerde tools als onzeker zijn gemarkeerd. Tekst met laag contrast werd gevonden op 83,9% van de homepages in het WebAIM Million-rapport van 2026 — het is de meest voorkomende toegankelijkheidsfout.
• Touchdoelgrootte: WCAG 2.2 SC 2.5.8 vereist dat interactieve doelen minimaal 24×24 CSS-pixels zijn (met aanbevolen best practice op 44×44 pixels). Inspecteer kleine knoppen, links met alleen een icoon en mobiele navigatie-elementen.
• Zoom en reflow: Test bij 200% en 400% browserzoom. Content moet bij 400% opnieuw vloeien zonder horizontaal scrollen (WCAG SC 1.4.10).

Schermlezertesten: de beste benadering van echte gebruikerservaring

Schermlezertesten is het meest veeleisende onderdeel van een toegankelijkheidsprogramma, en ook het meest onthullende. Een schermlezergebruiker ervaart een webpagina als een lineaire stroom van tekst en semantische informatie — de visuele lay-out is irrelevant. Koppen, landmarks, lijsten, tabellen, formulierlabels en ARIA-rollen vormen het navigatieskelet. Als dat skelet gebroken of afwezig is, wordt de pagina onbruikbaar, ongeacht hoe goed hij door geautomatiseerde checks komt.

Volgens de WebAIM Screen Reader User Survey, uitgevoerd eind 2023 en begin 2024, blijft JAWS de meest genoemde primaire desktopschermlezer met 40,5% van de respondenten, met NVDA kort daarachter op 37,7%. VoiceOver heeft 9,7% van de primaire desktopmarkt, maar is veruit de dominante schermlezer op mobiele apparaten, waarbij 70,6% van de mobiele schermlezergebruikers erop vertrouwt. Dit betekent dat een uitgebreid testprogramma minimaal het volgende moet dekken: NVDA met Chrome op Windows, JAWS met Chrome op Windows en VoiceOver met Safari op iOS.

De belangrijkste schermlezers in één oogopslag

JAWS (Job Access With Speech), ontwikkeld door Freedom Scientific, is al decennia de gouden standaard in enterprise-omgevingen. Het biedt diepe integratie met Microsoft Office, geavanceerde scripting voor niet-standaard applicaties en AI-gestuurde afbeeldingsbeschrijving. JAWS vereist een betaalde licentie (ongeveer $1.000 voor een standaardlicentie, of $95/jaar voor een thuisabonnement), wat het minder toegankelijk maakt voor informeel testen maar essentieel voor het valideren dat workflows op enterpriseniveau werken voor professionele schermlezergebruikers.

NVDA (NonVisual Desktop Access) is gratis, open-source en wordt door miljoenen vertrouwd. De functionaliteit is uitgegroeid tot een niveau dat voor de overgrote meerderheid van dagelijkse webtaken vergelijkbaar is met JAWS, en de draagbaarheid — het kan vanaf een USB-stick op elke Windows-machine draaien — maakt het de praktische keuze voor de meeste developmentteams die beginnen met schermlezertesten. NVDA met Chrome is de op één na meest voorkomende combinatie van schermlezer en browser in de praktijk.

VoiceOver is ingebouwd in elk macOS- en iOS-apparaat en vereist geen installatie. Op desktop werkt het het beste met Safari. Op iPhone en iPad is het met grote voorsprong de dominante schermlezer. Als je site aanzienlijk mobiel verkeer heeft — en dat geldt voor de meeste — is VoiceOver op iOS een verplicht onderdeel van je testmatrix. Het gebaren-gebaseerde navigatiemodel op touchscreens verschilt wezenlijk van toetsenbordnavigatie op desktop, wat betekent dat mobiele toegankelijkheidsproblemen alleen kunnen worden gevonden door te testen op een echt iOS-apparaat.

TalkBack is Google’s schermlezer voor Android en wordt gebruikt door ongeveer 35% van de mobiele schermlezergebruikers. Als je doelgroep Android-gebruikers omvat, moet TalkBack-testen deel uitmaken van je mobiele toegankelijkheidsprogramma.

Hoe je een effectieve schermlezertest uitvoert

Begin met je monitor uit te zetten of je ogen te sluiten. Het doel is de ervaring te simuleren van iemand die het scherm niet kan zien. Navigeer de pagina uitsluitend met schermlezercommando’s. Voor NVDA en JAWS zijn de belangrijkste navigatiepatronen: de pagina lineair doorlezen met de pijltjestoetsen of de read-all-opdracht; tussen koppen springen met H; navigeren op landmarks met D (NVDA) of ; (JAWS) om te springen tussen main-, navigatie- en footerregio’s; alleen door interactieve elementen tabben; en de forms mode gebruiken om met invoervelden te werken.

Vraag jezelf tijdens het navigeren af: Is de leesvolgorde logisch? Maakt de paginatitel sense wanneer die wordt aangekondigd? Worden afbeeldingen zinvol beschreven, of kondigt de schermlezer "afbeelding" aan zonder context? Kondigen formuliervelden hun label, type en huidige waarde aan? Wanneer je een formulier met fouten verstuurt, worden de foutmeldingen dan aangekondigd en zijn ze gemakkelijk te vinden? Wanneer dynamische content wordt bijgewerkt — een notificatiebanner, een laadstatus, een aantal zoekresultaten — wordt de update dan aangekondigd zonder dat de gebruiker terug hoeft te navigeren om die te vinden?

Schermlezers laten gebruikers op verschillende manieren interageren — leesmodus, formuliermodus en applicatiemodus — en kunnen in elke modus heel verschillende resultaten opleveren. Een element dat in de ene modus correct werkt, kan in een andere stil falen. Test altijd dezelfde interactie in meerdere navigatiemodi.

Een van de meest voorkomende en meest schadelijke fouten in moderne webapplicaties is gebroken focusbeheer. Wanneer een modaldialoog opent, moet de focus ernaartoe verplaatsen; wanneer hij sluit, moet de focus terugkeren naar het element dat hem activeerde. Wanneer een single-page application naar een nieuwe view gaat, moeten de paginatitel en de hoofdheading worden aangekondigd. Wanneer er een fout optreedt tijdens het versturen van een formulier, moet de focus naar de foutsamenvatting of het eerste ongeldige veld gaan. Deze patronen kunnen door geen enkele geautomatiseerde tool worden gevalideerd — ze vereisen een tester met een schermlezer open.

Een toegankelijkheidstestprogramma opbouwen dat blijft werken

De meest voorkomende fout die organisaties maken, is toegankelijkheidstesten behandelen als een eenmalige audit. Een site die vandaag slaagt, ontwikkelt morgen nieuwe overtredingen naarmate content wordt gepubliceerd, features worden uitgerold en scripts van derden worden bijgewerkt. Toegankelijkheid moet als een continu gebruik in de ontwikkelcyclus worden ingebed, niet als een periodieke checkbox.

Een duurzaam programma heeft drie lagen die parallel draaien. De geautomatiseerde laag draait bij elke codecommit en vangt regressies voordat ze productie bereiken. De handmatige laag draait per sprint wanneer nieuwe features worden ontwikkeld — niet als poort aan het einde, maar als controle tijdens de ontwikkeling. De laag met ondersteunende technologie draait als onderdeel van acceptatietesten voor elke feature met belangrijke interactiepatronen: formulieren, navigatiewijzigingen, modals, dynamische content en gebruikersflows. Voor de meeste teams betekent dat in elk geval NVDA met Chrome en VoiceOver op iOS.

Prioritering is belangrijk. Als je audit vijftig problemen oplevert, zijn die niet allemaal even zwaarwegend. WCAG-overtredingen worden gecategoriseerd op impact — kritieke issues die content volledig ontoegankelijk maken voor sommige gebruikers moeten worden opgelost vóór ernstige issues, die op hun beurt voorrang hebben op matige en kleine problemen. Richt je eerst op patronen die hele paginatypen beïnvloeden: als je navigatie kapot is voor toetsenbordgebruikers, repareer dan de navigatietemplate en je lost het overal tegelijk op. Als je foutafhandeling in formulieren ontoegankelijk is, los je met het patroon elke form op.

Documentatie is niet optioneel voor compliance managers. Houd een logboek voor toegankelijkheidstesten bij waarin staat welke pagina’s zijn getest, welke tools en ondersteunende technologieën zijn gebruikt, welke overtredingen zijn gevonden en welke oplossingen wanneer zijn toegepast. Deze documentatie wordt van onschatbare waarde tijdens toegankelijkheidsaudits of juridische procedures, omdat ze een voortdurende inspanning te goeder trouw aantoont om conformiteit te bereiken en te behouden.

De rol van overlay-widgets in je teststrategie

Toegankelijkheidsoverlay-widgets, zoals de Accsible SDK, spelen een betekenisvolle rol in een gelaagde toegankelijkheidsstrategie — vooral voor organisaties die onmiddellijke verbeteringen aan bestaande content moeten bieden terwijl diepere remediatie nog loopt. Een goed geïmplementeerde overlay kan ondersteunende tools voor gebruikers zichtbaar maken, zoals tekstvergroting, contrastaanpassing en verbeteringen voor toetsenbordnavigatie, die veelvoorkomende barrières aanpakken zonder dat een volledige herbouw van de site nodig is.

Overlays zijn echter geen vervanging voor testen. Ze vullen een testprogramma aan in plaats van het te vervangen. De meest effectieve aanpak is een overlay gebruiken om de oppervlakkige, presentatielaag-issues aan te pakken die programmatisch kunnen worden opgelost, terwijl je geautomatiseerde scanning, handmatig testen en schermlezervalidatie gebruikt om de structurele problemen te identificeren en op te lossen — gebroken semantiek, ontbrekende ARIA-rollen, ontoegankelijke custom widgets — die codewijzigingen vereisen. Overlays werken het best wanneer de onderliggende codebase is getest en de resterende gaten in de sfeer van gebruikersvoorkeuren liggen in plaats van fundamentele interactiebarrières.

Vraag bij de evaluatie van elke toegankelijkheidstool, overlay of anderszins, of deze is getest met echte schermlezers. Een widget die een zichtbare toegankelijkheidstoolbar creëert maar focus traps of ARIA-conflicten in de pagina introduceert, heeft de situatie verslechterd, niet verbeterd. De testmethodologieën in deze gids zijn van toepassing op toegankelijkheidstools zelf, niet alleen op de sites waarop ze draaien.

Belangrijkste inzichten

• Geen enkele tool is voldoende. Geautomatiseerde scanners vangen slechts 30–40% van de WCAG-overtredingen. Een volledig programma vereist geautomatiseerd testen, handmatige review en echt testen met ondersteunende technologie als complementaire lagen.
• Verplaats toegankelijkheid naar voren in het proces. axe-core of Pa11y integreren in je CI/CD-pijplijn betekent dat overtredingen worden gevonden voordat ze productie bereiken, waar het oplossen ervan exponentieel meer kost in tijd, reputatie en juridisch risico.
• Test met de schermlezers die je gebruikers daadwerkelijk gebruiken. NVDA met Chrome en JAWS met Chrome domineren desktopgebruik; VoiceOver op iOS domineert mobiel. Dek deze combinaties minimaal af en test dynamische interacties — modals, formulierfouten, SPA-routewijzigingen — die geautomatiseerde tools nooit zullen vinden.
• Repareer patronen, niet alleen individuele gevallen. Als je kopstructuur kapot is, repareer dan de template. Als je foutafhandeling in formulieren ontoegankelijk is, repareer dan de component. Systematische fixes leveren exponentieel meer waarde op dan ad-hocoplossingen.
• Maak toegankelijkheidstesten continu, niet periodiek. Een site die vandaag een audit doorstaat, zal afdrijven. Embed testen in je ontwikkelcyclus — geautomatiseerd bij elke commit, handmatig in elke sprint, testen met ondersteunende technologie bij elke belangrijke feature — en toegankelijkheid wordt een onderhouden eigenschap van je product in plaats van een remediatieproject.