Hoe test je je website op toegankelijkheid?

Sinds 28 juni 2025 is de European Accessibility Act, richtlijn 2019/882, van toepassing.
De richtlijn zelf noemt geen WCAG-versie, maar formuleert functionele eisen.
In de praktijk wordt getoetst tegen EN 301 549, de Europese norm voor ICT-toegankelijkheid, die op zijn beurt naar WCAG teruggrijpt.
De versie die vandaag in het Publicatieblad geciteerd staat, v3.2.1, verwijst naar WCAG 2.1 niveau AA.
Versie 4.1.1, op 2 september 2026 door ETSI gepubliceerd, verwijst naar WCAG 2.2 niveau AA en wordt naar verwachting eind 2026 geciteerd.
Onder de EAA is er tot nu toe geen enkele geharmoniseerde norm geciteerd, dus er is op dit moment ook geen formeel vermoeden van conformiteit.
Ik test standaard tegen WCAG 2.2 niveau AA, omdat dat de meest recente versie is en 2.1 er volledig in zit.
Welke versie voor jouw situatie formeel geldt, laat je juridisch nakijken.
Hieronder de testronde die ik zelf draai: welke tools, in welke volgorde en hoe je de bevindingen ordent.

Wat een tool niet beoordeelt is de inhoud van wat het vindt.
Of de alt-tekst klopt bij de afbeelding, of de koppen de structuur beschrijven in plaats van alleen groot te zijn, of de focusvolgorde klopt met wat je ziet, of een zelfgebouwde dropdown zich gedraagt zoals een gebruiker verwacht, of een foutmelding uitlegt wat er misging.
Een groene score in Lighthouse zegt op zich dus weinig.
Grofweg laten de vier WCAG-principes waarneembaar, bedienbaar, begrijpelijk en robuust zich niet even goed automatiseren: waarneembaar en robuust vindt een tool nog deels, bedienbaar en begrijpelijk vragen bijna altijd handwerk.
Tools voor de basis, handwerk voor de rest.

Laat axe-core of pa11y meelopen in je build, dan komen opgeloste fouten niet terug.
Eén ding werkt niet: een overlay-widget die met één regel JavaScript toegankelijkheid belooft.
Die sleutelt tijdens runtime aan de DOM, maar raakt je broncode en je componenten niet aan en maakt gedrag soms net stuk.

Test per paginatype en per flow, niet per pagina.
Een formulier, een filteroverzicht en het afrekenproces dekken meer af dan honderd artikelpagina's uit hetzelfde template.

Eerlijk daarover: ik gebruik een schermlezer als testinstrument, niet als dagelijks hulpmiddel en dat geldt voor vrijwel elke ontwikkelaar.
Zo'n ronde vindt de harde fouten wel, maar zegt niet of de site fijn werkt voor wie er elke dag op vertrouwt.
Voor dat oordeel test je met echte gebruikers.

Hoe je bevindingen ordent per succescriterium

Eén bevinding is één succescriterium, op één plek, met één manier om het te reproduceren.
Een rapport dat de ruwe export van een scanner doorgeeft is onbruikbaar, want dezelfde fout uit hetzelfde template staat er dan tweehonderd keer in.

Geef elk criterium daarna één van drie statussen: voldoet, voldoet niet, of niet van toepassing.
Die laatste is geen ontsnapping, want je moet uitleggen waarom een criterium niet speelt.
Sorteer op oorzaak in plaats van op pagina, want één aanpassing in een component ruimt vaak tientallen bevindingen op.
Zo houd je de onderbouwing over die je nodig hebt als een toegankelijkheidsverklaring voor jou verplicht is.

Wat een testronde niet afdekt

Een test toetst je site, niet je verplichting.
Vier zaken vallen er structureel buiten.

• De juridische vraag: of je onder de EAA valt hangt af van wat je aanbiedt, dus laat dat juridisch toetsen.
  Lees eerst of de European Accessibility Act voor jouw website geldt.
• Derde partijen: ingesloten video, kaarten, betaalmodules en cookiebanners staan in jouw pagina, niet in jouw codebase.
• Documenten: PDF- en Office-bestanden vallen onder EN 301 549 en vragen een eigen beoordeling.
• De redactie: het resultaat verschuift met elke publicatie, dus een test blijft een momentopname zolang je de uitgangspunten niet in je componenten vastlegt.