Een checklist voor toegankelijkheidsaudits is een gestructureerd document dat je door elke verificatiestap leidt om te bevestigen dat je website werkt voor mensen met een beperking. In plaats van een vaag beloof om dingen toegankelijk te maken, zet een checklist compliance om in concrete ja-of-nee-vragen. Heeft dit beeld alt-tekst? Kan een toetsenbordgebruiker elk interactief element bereiken? Voldoet het kleurcontrast aan de 4,5:1 verhouding? Deze gids biedt meer dan 50 controlepunten georganiseerd volgens de vier WCAG-principes. Of je je nu voorbereidt op de Europese Toegankelijkheidswet (EAA) die sinds juni 2025 van kracht is, of gewoon een beter product wilt bouwen, deze checklist geeft je de structuur om het te doen.
Waarom je een gestructureerde audit-checklist nodig hebt
Een toegankelijkheidsaudit uitvoeren zonder checklist is alsof je een gebouwinspectie uit je hoofd doet. Je vindt de voor de hand liggende problemen en mist de subtiele die gebruikers daadwerkelijk blokkeren.
Geautomatiseerde scantools zijn een goed startpunt, maar ze detecteren slechts ongeveer 30 tot 40 procent van de WCAG-problemen. De rest vereist menselijk oordeel.
De juridische dimensie is aanzienlijk verscherpt. De Europese Toegankelijkheidswet (EAA) is afdwingbaar sinds 28 juni 2025. In Nederland is de wet geimplementeerd via nationale wetgeving met bijbehorende sancties. In andere EU-landen lopen boetes op tot 300.000 euro in Spanje en 250.000 euro in Frankrijk.
Naast wettelijke vereisten is er een sterke business case. Toegankelijke websites presteren doorgaans beter in zoekmachines, converteren meer gebruikers en genereren minder supporttickets.
Voor je begint: je audit opzetten
Een goede audit begint met het definiëren van de scope. Elke pagina van een grote site testen is onpraktisch en onnodig. Focus op deze categorieën:
Pagina's met veel verkeer: je homepage, belangrijkste landingspagina's en de top 10 pagina's op bezoekersaantal.
Belangrijke gebruikersflows: registratie, inloggen, checkout, zoeken en meerstapsformulieren.
Unieke templates: als je site 8 verschillende layouts gebruikt, test dan minstens een representatieve pagina per template.
Content-rijke pagina's: blogartikelen, documentatie en kennisbank-artikelen.
Voor een typische bedrijfswebsite van 50 tot 200 pagina's dekt het auditen van 10 tot 15 representatieve pagina's de overgrote meerderheid van variaties.
Benodigde tools
Je hebt geen dure enterprise-software nodig voor een grondige audit.
Geautomatiseerde scanner: Gebruik onze gratis toegankelijkheidschecker op web-accessibility-checker.com voor een direct WCAG 2.2 conformiteitsrapport.
Browser DevTools: Chrome en Firefox bevatten beide toegankelijkheidsinspectiepanelen.
Screenreader: NVDA is gratis op Windows. VoiceOver is ingebouwd in macOS en iOS. TalkBack is ingebouwd in Android.
Toetsenbord: Je fysieke toetsenbord. Ontkoppel je muis en probeer je belangrijkste flows te voltooien met alleen Tab, Shift+Tab, Enter, Spatie en pijltjestoetsen.
Contrastanalysator: De Colour Contrast Analyser van TPGi is gratis.
PDF-checker: Gebruik PAC 2024 voor het controleren van de toegankelijkheid van PDF-documenten.
Principe 1: Waarneembaar
Het eerste WCAG-principe vraagt: kunnen gebruikers de content waarnemen?
Afbeeldingen en niet-tekstuele content
Elke informatieve afbeelding moet alt-tekst hebben die dezelfde informatie overbrengt. Decoratieve afbeeldingen moeten lege alt-attributen hebben.
Controleer dat complexe afbeeldingen zoals grafieken en infographics uitgebreide beschrijvingen hebben.
CAPTCHA's moeten alternatieven bieden.
Video- en audiocontent
Vooraf opgenomen video's hebben gesynchroniseerde ondertiteling nodig. Vooraf opgenomen audiocontent heeft een teksttranscriptie nodig. Video's hebben audiobeschrijvingen nodig voor visuele informatie die niet door het bestaande geluidsspoor wordt overgebracht.
Tekst en leesbaarheid
Normale tekst heeft een contrastverhouding van minimaal 4,5:1 ten opzichte van de achtergrond nodig. Grote tekst heeft minimaal 3:1 nodig.
De pagina moet functioneel en leesbaar blijven wanneer tekst tot 200 procent wordt vergroot.
Gebruik geen afbeeldingen van tekst wanneer echte tekst hetzelfde visuele effect kan bereiken.
Controleer dat content niet alleen op kleur vertrouwt om informatie over te brengen.
Principe 2: Bedienbaar
Kunnen gebruikers de interface bedienen? Elke functie moet werken voor mensen die toetsenborden, screenreaders, spraakcommando's of schakelaars gebruiken.
Toetsenbordtoegankelijkheid
Elk interactief element moet bereikbaar en bruikbaar zijn met alleen het toetsenbord.
Controleer op toetsenbordvallen. Een val treedt op wanneer je met Tab in een element kunt komen maar er niet uit kunt.
Controleer dat de tabvolgorde een logische leesvolgorde volgt.
Focuszichtbaarheid
Elk interactief element moet een zichtbare focusindicator hebben. Volgens WCAG 2.2 criterium 2.4.11 mag het gefocuste element niet volledig verborgen zijn achter sticky headers of zwevende widgets.
Verwijder nooit focusomlijningen zonder een even zichtbare vervanging te bieden.
Doelgrootte en aanraking
WCAG 2.2 criterium 2.5.8 vereist dat interactieve doelen minimaal 24 bij 24 CSS-pixels zijn.
Voor drag-and-drop functionaliteit vereist WCAG 2.2 criterium 2.5.7 een alternatief met enkele aanwijzer.
Tijdslimieten en beweging
Als content automatisch beweegt, knippert of scrollt gedurende meer dan 5 seconden, moeten gebruikers het kunnen pauzeren of stoppen.
Niets op de pagina mag meer dan drie keer per seconde knipperen.
Bij tijdslimieten moeten gebruikers deze kunnen uitschakelen, aanpassen of verlengen.
Principe 3: Begrijpelijk
Kunnen gebruikers de content en werking van de interface begrijpen?
Taal en leesbaarheid
De pagina moet haar taal declareren in het HTML lang-attribuut. Voor Nederlandse pagina's gebruik je lang nl.
Navigatiemenu's moeten op dezelfde relatieve positie verschijnen op alle pagina's.
Controleer dat instructies niet alleen afhankelijk zijn van zintuiglijke kenmerken.
Formulieren en foutafhandeling
Elk formulierveld heeft een zichtbaar, programmatisch gekoppeld label nodig. Placeholder-tekst alleen is geen label.
Bij fouten moeten specifieke velden worden geidentificeerd en problemen worden beschreven.
WCAG 2.2 criterium 3.3.7 vereist dat eerder ingevoerde informatie wordt vooringevuld.
Voor authenticatie vereist WCAG 2.2 criterium 3.3.8 dat wachtwoordmanagers niet worden geblokkeerd.
Principe 4: Robuust
Kunnen hulptechnologieen de content correct interpreteren?
Semantische HTML en ARIA
Gebruik semantische HTML-elementen: header, nav, main, footer, article, section, aside.
Koppen moeten een logische hierarchie volgen. Een H1 per pagina.
Alle interactieve elementen moeten toegankelijke namen hebben.
Gebruik ARIA-rollen alleen wanneer native HTML de benodigde semantiek niet biedt.
Controleer dat dynamische content-updates worden aangekondigd via aria-live regio's.
De complete checklist: snelreferentie
Hier is de volledige checklist in een scanbaar formaat.
Waarneembaar: - Alle informatieve afbeeldingen hebben beschrijvende alt-tekst - Decoratieve afbeeldingen hebben lege alt-attributen - Video's hebben gesynchroniseerde ondertiteling - Tekstcontrast is minimaal 4,5:1 - Pagina is bruikbaar bij 200% zoom - Content vertrouwt niet alleen op kleur
Bedienbaar: - Alle interactieve elementen zijn per toetsenbord bereikbaar - Geen toetsenbordvallen aanwezig - Zichtbare focusindicatoren aanwezig - Interactieve doelen minimaal 24x24 CSS-pixels - Auto-geanimeerde content heeft pauzeknop - Skip-navigatielink aanwezig
Begrijpelijk: - Paginataal gedeclareerd in lang-attribuut - Navigatie consistent op alle pagina's - Alle velden hebben zichtbare labels - Foutmeldingen zijn specifiek - Authenticatie blokkeert geen wachtwoordmanagers
Robuust: - Semantische HTML-landmarks gebruikt - Koppenhierarchie is logisch - Alle interactieve elementen hebben toegankelijke namen - ARIA correct en alleen waar nodig gebruikt
Problemen prioriteren na de audit
Kritieke problemen blokkeren gebruikers volledig. Los deze eerst op.
Hoge problemen veroorzaken aanzienlijke moeilijkheden maar hebben workarounds.
Middelmatige problemen beinvloeden de bruikbaarheid zonder taakvoltooing te verhinderen.
Lage problemen zijn best-practice verbeteringen.
Documenteer elk bevinding met ernst, getroffen pagina-URL, relevant WCAG-criterium en aanbevolen oplossing.
Doorlopende monitoring automatiseren
Een audit is een momentopname. Websites veranderen constant. Zonder doorlopende monitoring sluipen toegankelijkheidsregressies binnen weken in.
Stel geautomatiseerd scannen in op een schema. Onze toegankelijkheidschecker maakt regelmatige scans mogelijk.
Integreer toegankelijkheidscontroles in je ontwikkelworkflow met bibliotheken als axe-core.
Plan driemaandelijkse handmatige reviews. Train je contentteam.
Wettelijke vereisten in 2026
De Europese Toegankelijkheidswet (EAA) is van kracht sinds 28 juni 2025. In Nederland is deze geimplementeerd via nationale wetgeving. De technische standaard is EN 301 549, die verwijst naar WCAG 2.1 Level AA.
In Duitsland voorziet het BFSG in boetes tot 100.000 euro. In Spanje tot 300.000 euro. In Frankrijk tot 250.000 euro met dagelijkse extra boetes.
ADA Title II in de VS vereist nu expliciet webtoegankelijkheid voor overheidsinstellingen, met deadline april 2026.
WCAG 2.2 AA als auditdoel dekt de vereisten van al deze kaders.