Wat is een toegankelijkheidsaudit? Hoe controleer je of je website WCAG-conform is

Volgens het meest recente WebAIM Million-rapport werden er 56 miljoen afzonderlijke toegankelijkheidsfouten gedetecteerd op één miljoen homepagina’s — een gemiddelde van 56 fouten per pagina. Dat betekent dat de overgrote meerderheid van websites gebruikers met een beperking elke dag actief in de steek laat. Als je een website-eigenaar, ontwikkelaar of compliance manager bent die zich afvraagt of je site WCAG-conform is, dan houdt het antwoord vrijwel zeker in dat je een goede toegankelijkheidsaudit moet uitvoeren. De vraag is: wat betekent dat precies, en hoe doe je het goed?

Waarom toegankelijkheidsaudits niet langer optioneel zijn

Webtoegankelijkheid gaat inmiddels veel verder dan goede bedoelingen. Het is nu een wettelijke verplichting in een groeiend aantal rechtsgebieden, en de gevolgen van niet-naleving zijn concreet en meetbaar. In 2024 werden er in de Verenigde Staten meer dan 4.000 rechtszaken over webtoegankelijkheid aangespannen, en de trend blijft stijgen. Rechtbanken in de VS hebben consequent geoordeeld dat websites van bedrijven die openstaan voor het publiek toegankelijk moeten zijn onder ADA Title III. Ondertussen werd de European Accessibility Act in juni 2025 afdwingbaar in alle EU-lidstaten, waarbij de vereisten verder reiken dan overheidssites en nu ook bankapps, e-commerceplatforms, SaaS-producten en meer omvatten.

De cijfers schetsen een scherp beeld. Ongeveer 16% van de wereldbevolking — circa 1,3 miljard mensen — leeft met een of andere vorm van beperking. Alleen al in de Verenigde Staten heeft ongeveer één op de vier volwassenen een beperking. Dit zijn geen randgebruikers. Het zijn klanten, werknemers, studenten en burgers die op websites barrières tegenkomen waar de meeste ontwikkelaars nooit bij stilstaan.

Naast het juridische risico is er een meetbare zakelijke case. Toegankelijke websites presteren beter in zoekmachines, omdat dezelfde structurele helderheid die schermlezers helpt — semantische koppen, beschrijvende alt-tekst, schone markup — ook crawlers helpt. Inclusief design verbetert consequent de bruikbaarheid voor iedereen: ondertiteling is nuttig voor mensen in lawaaiige omgevingen, hoog contrast helpt mensen in fel zonlicht, en toetsenbordnavigatie is gunstig voor power users. Een toegankelijkheidsaudit is de eerste stap om al deze voordelen te benutten.

Nog een belangrijke verschuiving: ADA Title II vereist nu expliciet webtoegankelijkheid voor Amerikaanse staats- en lokale overheidsinstanties, waarbij het DOJ WCAG 2.1 Level AA heeft aangenomen als technische standaard. Instanties die populaties van 50.000 of meer bedienen, hebben een nalevingstermijn tot 26 april 2026. Als je met klanten in de publieke sector werkt of actief bent in gereguleerde sectoren, is auditen niet langer optioneel — het is urgent.

Wat is een WCAG-toegankelijkheidsaudit precies?

Een webtoegankelijkheidsaudit is een systematische evaluatie van de naleving van je website met de Web Content Accessibility Guidelines (WCAG) — de internationaal erkende technische standaard voor digitale toegankelijkheid, ontwikkeld door het W3C. In de praktijk identificeert een audit specifieke barrières die voorkomen dat gebruikers met een beperking je content kunnen waarnemen, begrijpen, navigeren en ermee interageren. Het koppelt die barrières aan de WCAG-succescriteria, kent ernstniveaus toe en levert een roadmap voor remediatie op.

WCAG is momenteel in versie 2.2, gepubliceerd eind 2023 en in mei 2025 formeel opnieuw bevestigd door het W3C als de hoogste standaard voor webtoegankelijkheid. Het bevat negen nieuwe succescriteria ten opzichte van WCAG 2.1, voor gebieden zoals zichtbaarheid van toetsenbordfocus, minimale aanraakdoelgroottes, alternatieven voor sleepbewegingen en consistente helpmechanismen. Belangrijk is dat WCAG 2.2 backwards compatible is — als je aan 2.2 voldoet, voldoe je ook aan 2.1 en 2.0.

WCAG is georganiseerd rond drie conformiteitsniveaus. Niveau A dekt de meest kritieke barrières — fouten op dit niveau maken content volledig onbruikbaar voor sommige gebruikers. Niveau AA is het doel dat door de meeste toegankelijkheidswetten wereldwijd wordt voorgeschreven, waaronder de ADA, de European Accessibility Act en Section 508. Niveau AAA vertegenwoordigt de hoogste lat en is doorgaans ambitieus in plaats van wettelijk vereist. Wanneer iemand zegt dat zijn site “WCAG-conform” is, bedoelt die bijna altijd WCAG 2.1 of 2.2, Niveau AA.

WCAG is gebouwd op vier kernprincipes, vaak onthouden met het acroniem POUR: content moet Perceivable (gebruikers kunnen het waarnemen), Operable (gebruikers kunnen ermee interageren), Understandable (gebruikers kunnen het begrijpen) en Robust (het werkt betrouwbaar met ondersteunende technologieën) zijn. Elk succescriterium is gekoppeld aan een van deze vier principes, en een grondige audit controleert de conformiteit met al deze principes.

De meest voorkomende fouten die audits aan het licht brengen

Ongeveer 96% van alle gedetecteerde toegankelijkheidsfouten valt in slechts zes categorieën. Weten waar je op moet letten is de snelste manier om je audittijd te prioriteren:

• Tekst met laag contrast. Dit is consequent de meest voorkomende fout. Bijna 84% van de homepagina’s bevat tekst die onder de WCAG 2 AA-contrastdrempel van 4,5:1 voor normale tekst valt. Auditors controleren de kleurverhouding tussen voorgrond en achtergrond met tools zoals de TPGi Colour Contrast Analyser.
• Ontbrekende alternatieve tekst. Meer dan 16% van alle afbeeldingen op homepagina’s mist een alt-attribuut, waardoor schermlezergebruikers geen manier hebben om de inhoud van de afbeelding te begrijpen. Gelinkte afbeeldingen zonder alt-tekst zijn bijzonder schadelijk — ze worden betekenisloze navigatiedoelen.
• Lege links. Links zonder zichtbare tekst en zonder toegankelijke naam creëren doodlopende wegen voor toetsenbord- en schermlezergebruikers, die niet kunnen bepalen waar de link naartoe gaat.
• Ontbrekende labels voor formulierinvoer. Formulieren zonder programmatisch gekoppelde labels zijn onbruikbaar voor schermlezergebruikers. Dit omvat zowel zichtbare labels als verborgen labels met aria-label of aria-labelledby.
• Lege knoppen. Knoppen die alleen uit een icoon bestaan en geen toegankelijke naam hebben — vaak gebruikt in navigatie en sliders — laten niet-visuele gebruikers in het ongewisse over wat de knop doet.
• Ontbrekende documenttaal. Het lang-attribuut op het <html>-element vertelt schermlezers welke taal ze moeten gebruiken. Het ontbreken ervan veroorzaakt verkeerde uitspraak en desoriëntatie bij gebruikers die afhankelijk zijn van tekst-naar-spraak.

Audits laten consequent zien dat de meest schadelijke fouten ook het makkelijkst te verhelpen zijn. Laag contrast, ontbrekende alt-tekst en niet-gelabelde formuliervelden kunnen vaak in dagen worden opgelost, niet in maanden.

Naast deze zes zal een grondige audit ook ontbrekende skipnavigatielinks opsporen (waardoor toetsenbordgebruikers op elke pagina door elk kop-element moeten tabben), onjuiste koppenhiërarchie, ontoegankelijke modals en dialogen die focus verkeerd vastzetten, video’s zonder ondertiteling, PDF’s zonder getagde structuur en aangepaste JavaScript-widgets die geen toegankelijke rollen en statussen via ARIA blootleggen.

Hoe je een toegankelijkheidsaudit uitvoert: stap voor stap

Een goede toegankelijkheidsaudit is geen enkele scan — het is een meerstapsproces dat geautomatiseerde tools combineert met deskundig menselijk oordeel. Zo pak je het systematisch aan:

Stap 1: Bepaal de scope

Beslis wat je gaat auditen voordat je ook maar één test uitvoert. Voor een grote site is het onpraktisch om elke pagina te testen. Pas in plaats daarvan de WCAG-EM (Website Accessibility Conformance Evaluation Methodology) toe, ontwikkeld door het W3C: definieer een representatieve steekproef die alle unieke paginatemplates, alle belangrijke gebruikersreizen en alle verschillende contenttypes dekt. Een steekproef voor een e-commercesite kan de homepage, een categoriepagina, een productdetailpagina, de winkelwagen, de checkoutflow, accountlogin, contactformulier en een blogpost omvatten. Zorg dat dynamische staten zijn inbegrepen — geopende menu’s, foutmeldingen in formulieren, modale dialogen en geladen zoekresultaten moeten allemaal worden geëvalueerd.

Stap 2: Voer geautomatiseerde scans uit

Geautomatiseerde tools vormen de basis van elke efficiënte audit. Ze scannen je HTML snel, markeren ondubbelzinnige regeloverschrijdingen en geven je een basislijst met problemen. Belangrijke tools zijn onder andere:

• axe DevTools (browserextensie of CLI) — veelgebruikt, lage false-positive-ratio, integreert met CI/CD-pijplijnen
• WAVE (WebAIM) — annoteert pagina’s visueel met fouticonen, waardoor het intuïtief is voor niet-technische teamleden
• Lighthouse (ingebouwd in Chrome DevTools) — geeft een toegankelijkheidsscore naast prestatie- en SEO-metrics
• Colour Contrast Analyser (TPGi) — pikt elke kleur op het scherm en controleert die tegen WCAG-drempels
• PAC 2024 — speciale PDF-toegankelijkheidschecker voor downloadbare documenten

Een cruciale beperking: geautomatiseerde tools kunnen slechts tussen 30% en 40% van de WCAG-problemen detecteren. Ze zijn uitstekend in het signaleren van regelgebaseerde fouten zoals ontbrekende attributen, ongeldige ARIA-rollen en contrastverhoudingen. Maar ze kunnen niet beoordelen of alt-tekst betekenisvol is, of een formulier logisch is opgebouwd, of een gebruiker een taak daadwerkelijk kan voltooien. Daarom is automatisering Stap 2, niet de volledige audit.

Stap 3: Handmatige expertentest

Handmatig testen door een deskundig persoon — of idealiter een team — bepaalt de diepgang van een audit. Dit omvat:

• Alleen-toetsenbordnavigatie. Koppel de muis los en probeer elke kerngebruikersreis te voltooien met alleen Tab, Shift+Tab, Enter, Spatie en pijltjestoetsen. Kun je elk interactief element bereiken? Is de focusindicator altijd zichtbaar? Verdwijnt de focus ooit in een component?
• Schermlezertests. Gebruik NVDA met Chrome of Firefox op Windows, en VoiceOver met Safari op macOS en iOS. Navigeer op koppen, landmarks, links en formulieren. Maakt de pagina sense zonder visuele context? Worden alle interactieve elementen correct aangekondigd?
• Visuele en cognitieve review. Controleer de koppenhiërarchie op logische structuur, verifieer dat foutmeldingen beschrijvend zijn en gekoppeld aan het juiste veld, bevestig dat tijdgebaseerde media ondertiteling en transcripties hebben, en controleer dat instructies niet uitsluitend afhankelijk zijn van kleur, vorm of positie.
• Code-inspectie. Beoordeel HTML-semantiek, ARIA-gebruik, focusmanagement in aangepaste widgets en landmark-regio’s. Een modal die focus niet vastzet, of een ARIA live-regio die bij elke toetsaanslag afgaat, wordt alleen op dit niveau ontdekt.

Stap 4: Testen met ondersteunende technologie door echte gebruikers

De gouden standaard — en vaak de meest onthullende fase — is testen met echte gebruikers die dagelijks op ondersteunende technologieën vertrouwen. Mensen die schermlezers, switch-apparaten of spraakbesturingssoftware gebruiken, navigeren op manieren die zelfs deskundige handmatige testers niet volledig repliceren. Het betrekken van mensen met een beperking in je evaluatie brengt frictie in de echte wereld aan het licht die tools en checklists simpelweg niet kunnen voorspellen.

Stap 5: Bevindingen documenteren en prioriteren

Een ruwe lijst met fouten is geen auditrapport — het is een startpunt. Een bruikbaar auditdocument moet specificeren: de getroffen URL of component, het geschonden WCAG-succescriterium, de ernst (kritiek, hoog, medium, laag), de impact op getroffen gebruikers en specifieke remediatierichtlijnen met codevoorbeelden waar relevant. Prioriteit moet in de eerste plaats worden toegekend op basis van gebruikersimpact, niet technische gemakzucht. Een kapot formulierveldlabel dat checkout verhindert, is urgenter dan een suboptimale koppenstructuur in een blogsidebar.

Stap 6: Remediëren, valideren en monitoren

Zodra oplossingen zijn geïmplementeerd, valideer ze — ga er niet van uit dat de remediatie heeft gewerkt. Test elke oplossing opnieuw met dezelfde combinatie van tools en handmatige controles die tijdens de oorspronkelijke audit zijn gebruikt. Nadat je een basisniveau van conformiteit hebt bereikt, moet je continue monitoring inrichten. Nieuwe content, CMS-updates en scripts van derden kunnen op elk moment regressies introduceren. Behandel toegankelijkheid zoals security: iets dat je onderhoudt, niet iets dat je één keer bereikt en vervolgens vergeet.

Geautomatiseerde scans vs. volledige audits: het verschil begrijpen

Dit onderscheid is enorm belangrijk, vooral in een juridische context. Een geautomatiseerde scan voert een regelgebaseerde controle uit op je gerenderde HTML. Het duurt seconden of minuten en levert een lijst met gedetecteerde overtredingen op. Het is uitstekend om de duidelijke, veelvoorkomende problemen te signaleren en om te integreren in CI/CD-workflows om te voorkomen dat nieuwe regressies live gaan. Veel overlay- en widgetproducten — inclusief toegankelijkheidstools — bieden geautomatiseerde scandashboards als onderdeel van hun functieset, en deze zijn echt nuttig voor doorlopende monitoring.

Een volledige audit daarentegen beoordeelt je site op elk toepasselijk WCAG-succescriterium met een combinatie van geautomatiseerde scans, handmatige expertreview, schermlezertests en alleen-toetsenbordnavigatie. Een uitgebreide audit die geautomatiseerde en handmatige methoden combineert, kan meer dan 90% van de toegankelijkheidsproblemen aan het licht brengen, vergeleken met het plafond van 30–40% bij alleen automatisering. Als je te maken krijgt met een juridische sommatie, een inkoopvereiste of een regulatoire vraag, levert alleen een volledige audit de documentatie op die je nodig hebt.

Veel organisaties gebruiken een praktische hybride strategie: geautomatiseerde scans draaien continu in CI/CD om regressies vroegtijdig te detecteren, terwijl jaarlijks of na significante site-redesigns een volledige handmatige audit wordt uitgevoerd. Dit balanceert grondigheid met efficiëntie en houdt naleving op de lange termijn beheersbaar.

Geen enkele tool kan op zichzelf bepalen of een site aan toegankelijkheidsstandaarden voldoet. Deskundige menselijke evaluatie is vereist om te bepalen of een site werkelijk toegankelijk is. — W3C Web Accessibility Initiative

Wat te doen met auditresultaten: remediatieplanning

Een afgeronde audit is alleen waardevol als die tot actie leidt. Hoe je het remediatiewerk prioriteert, is net zo belangrijk als het identificeren van de problemen. Een praktisch raamwerk voor remediatieprioritering ziet er als volgt uit:

1. Kritiek (direct oplossen): Problemen die gebruikers volledig blokkeren bij het voltooien van kerntaken — een kapot checkoutformulier, een ontoegankelijke loginmodal, een navigatiemenu dat niet met het toetsenbord bereikbaar is. Dit zijn de grootste juridische risico’s en hebben de grootste impact op gebruikers.
2. Hoog (oplossen binnen de huidige sprint of releasecyclus): Problemen die de bruikbaarheid voor gebruikers met een beperking aanzienlijk aantasten, maar hen niet volledig blokkeren — ontbrekende alt-tekst op productafbeeldingen, laag contrast op lopende tekst, niet-gelabelde icoonknoppen in de interface.
3. Medium (geplande remediatie): Problemen die frictie veroorzaken maar waarvoor workarounds bestaan — inconsistente focusindicatoren, ontbrekende skiplinks, suboptimale koppenhiërarchie.
4. Laag (backlog met toegewezen eigenaar): Problemen die best-practice-verbeteringen zijn maar waarschijnlijk de bruikbaarheid in de meeste gevallen niet beïnvloeden — verbeteringen op AAA-niveau, kleine ARIA-verbeteringen rond overbodigheid.

Documenteer je remediatieplan en tijdlijn, zelfs voordat alle oplossingen zijn doorgevoerd. Toezichthouders en rechtbanken beoordelen aantoonbare, voortdurende, te goeder trouw aangebrachte verbeteringen over het algemeen gunstiger dan nietsdoen. Als je een sommatie ontvangt, sta je veel sterker met een auditrapport plus een remediatieschema in de hand dan zonder enige documentatie.

Overlay-widgets en SDK-tools — zoals die van Accsible — kunnen een betekenisvolle rol spelen in de remediatiefase. Ze kunnen directe oplossingen bieden voor een aanzienlijk deel van veelvoorkomende problemen (vooral visuele voorkeuren zoals contrast, lettergrootte en spatiëring), terwijl je ontwikkelingsteam werkt aan diepere remediaties op codeniveau. De sleutel is te begrijpen wat overlays goed oplossen en ze te gebruiken als onderdeel van een gelaagde strategie, niet als vervanging voor code-level fixes op kritieke barrières.

Hoe vaak moet je een toegankelijkheidsaudit uitvoeren?

Een eenmalige audit is een momentopname van je site op een bepaalde dag. Websites zijn levende producten — content verandert, scripts van derden worden geüpdatet, componenten worden vervangen en nieuwe features worden uitgerold. Elk van deze gebeurtenissen kan nieuwe toegankelijkheidsbarrières introduceren. Een duurzaam toegankelijkheidsprogramma ziet er doorgaans zo uit:

• Continue geautomatiseerde scanning geïntegreerd in je CI/CD-pijplijn of via een monitoringsdashboard, om regressies te detecteren voordat ze in productie komen
• Kwartaalgewijze handmatige steekproeven op pagina’s met veel verkeer en hoog risico (checkout, login, contactformulieren, belangrijke landingspagina’s)
• Jaarlijkse volledige audit uitgevoerd door gekwalificeerde toegankelijkheidsexperts, vooral na grote redesigns of platformmigraties
• Audit in de ontwerpfase voor elke nieuwe grote feature of redesign — toegankelijkheid is aanzienlijk goedkoper om in te bouwen dan om achteraf te repareren

De meest kosteneffectieve aanpak is om toegankelijkheid naar links te verschuiven — het vanaf dag één integreren in het ontwerp- en ontwikkelproces in plaats van het te behandelen als een complianceoefening na de lancering. Ontwikkelaars die de WCAG-vereisten begrijpen, vangen problemen bij de bron. Designers die weten van kleurcontrast en aanraakdoelgroottes, maken standaard toegankelijke keuzes. Een audit wordt dan een kwaliteitshek in plaats van een noodinterventie.

Belangrijkste inzichten

• De meeste websites falen op WCAG. Meer dan 95% van de homepagina’s heeft detecteerbare toegankelijkheidsfouten, en de zes meest voorkomende fouten — laag contrast, ontbrekende alt-tekst, lege links, ontbrekende formulierlabels, lege knoppen en ontbrekende documenttaal — zijn verantwoordelijk voor de overgrote meerderheid. Deze zijn allemaal oplosbaar.
• Geautomatiseerde tools zijn noodzakelijk maar niet voldoende. Geautomatiseerde scanners detecteren in het beste geval 30–40% van de WCAG-problemen. Een volledige audit vereist toetsenbordtesten, schermlezertesten en deskundige menselijke review van code en UX-flows.
• WCAG 2.2 Level AA is het doel. Het is de standaard waarnaar wordt verwezen door de ADA, de European Accessibility Act, Section 508 en de meeste andere toegankelijkheidskaders wereldwijd. Mikken op 2.2 AA betekent dat je automatisch alle lagere versies dekt.
• Remediatie heeft een prioriteitsraamwerk nodig. Begin met problemen die kerngebruikersreizen volledig blokkeren en werk vervolgens de hoog-impact, veelvoorkomende problemen af. Documenteer alles — je auditrapport en remediatieplan zijn je beste juridische verdediging.
• Toegankelijkheid is doorlopend, niet eenmalig. Combineer continue geautomatiseerde monitoring met periodieke handmatige audits en verplaats toegankelijkheid naar het begin van je ontwerp- en ontwikkelproces. Een overlay-widget zoals Accsible kan gaten overbruggen terwijl diepere remediaties worden uitgevoerd.