Waarom geautomatiseerde toegankelijkheidsscanners slechts 30% van de problemen opsporen (en wat je eraan kunt doen)

Je voert een geautomatiseerde toegankelijkheidsscan uit, het dashboard kleurt groen en je haalt opgelucht adem. Maar hier is een ongemakkelijke waarheid: dat schone rapport kan het merendeel van de echte toegankelijkheidsbarrières op je site verbergen. Onderzoek en onafhankelijke studies laten consequent zien dat geautomatiseerde scanners ergens tussen de 30% en 57% van de daadwerkelijke WCAG-overtredingen detecteren — wat betekent dat ergens tussen de helft en twee derde van de problemen waar je gebruikers met een beperking dagelijks tegenaan lopen volledig onzichtbaar zijn voor de tools waar de meeste teams op vertrouwen.

De stand van zaken rond geautomatiseerd toegankelijkheidstesten

Geautomatiseerd toegankelijkheidstesten is enorm in populariteit toegenomen, en met goede reden. Steeds meer teams wenden zich tot automatisering om te screenen op toegankelijkheidsproblemen: 50% van de respondenten in een enquête uit 2024 gaf aan geautomatiseerde toegankelijkheidstools te gebruiken om potentiële problemen te identificeren, tegenover 40% in 2023. De aantrekkingskracht is duidelijk — scanners zijn snel, relatief goedkoop en kunnen direct in CI/CD-pijplijnen worden geïntegreerd. Ze vangen de voor de hand liggende, herhaalbare, regelgebaseerde overtredingen op schaal: het ontbrekende alt-attribuut, het formulierinvoerveld zonder label, de knop met een lege toegankelijke naam.

Maar het dekkingsplafond is een hardnekkig probleem waar geen enkele scannerleverancier doorheen heeft kunnen breken. Volgens Deque "kun je gemiddeld 57% van de WCAG-problemen automatisch vinden", en zelfs dan zullen tools componenten als onvolledig teruggeven wanneer handmatige beoordeling nodig is. Dat cijfer van 57% vertegenwoordigt het optimistische uiteinde van het spectrum, bereikt door een van de meest volwassen en breed vertrouwde toegankelijkheidsengines op de markt met een pragmatische, realistische meetmethodologie. Andere schattingen liggen aanzienlijk lager. Geautomatiseerde tools vangen ongeveer 30–40% van de WCAG-overtredingen, waarbij de resterende 60–70% handmatig testen vereist.

Het verschil tussen 30% en 57% komt neer op hoe je de noemer definieert. Deque kwam tot het cijfer van 57% door een pragmatische, realistische benadering te hanteren in plaats van een theoretische — door een groot aantal sites te bemonsteren en te meten hoeveel van de daadwerkelijk gedocumenteerde toegankelijkheidsdefecten zouden zijn gedetecteerd met axe-core. Wanneer onderzoekers de dekking in plaats daarvan meten ten opzichte van alle WCAG-succescriteria als een theoretische set, dalen de cijfers scherp. Op het moment van schrijven laat filteren op WCAG 2.2 niveaus A en AA om alleen goedgekeurde geautomatiseerde testregels te tonen, slechts gedeeltelijke of volledige dekking zien voor 17 van de 55 succescriteria. Hoe je het ook bekijkt, geautomatiseerd testen laat een significante — en juridisch gevaarlijke — kloof achter.

Het probleem wordt verergerd doordat die kloof van buitenaf zo moeilijk te zien is. Een geslaagde scan geeft actief een signaal van veiligheid, precies het moment waarop teams het meest geneigd zijn te stoppen met kijken. Het dashboard is groen. Er wordt gedeployed. Echte gebruikers met een beperking lopen tegen echte barrières aan.

Waar scanners daadwerkelijk goed in zijn

Voordat we in de dekkingskloof duiken, is het de moeite waard om duidelijk te zijn over wat geautomatiseerde tools echt goed doen. Ze zijn snel, consistent en onvermoeibaar in het controleren van zaken die puur kunnen worden vastgesteld door de DOM te lezen. Toegankelijkheidsautomatisering kan betrouwbaar veelvoorkomende WCAG-overtredingen opsporen, zoals ontbrekende alt-tekst, lege links, onjuiste formulierlabels en lage kleurcontrastverhoudingen. Dit zijn structurele, binaire controles — of het attribuut bestaat of het bestaat niet, of de contrastverhouding voldoet aan 4,5:1 of hij faalt.

Het WebAIM Million-rapport, dat jaarlijks de top één miljoen homepages analyseert, geeft een levendig beeld van hoe wijdverbreid deze detecteerbare fouten nog steeds zijn. 95,9% van de homepages had gedetecteerde WCAG 2-fouten. De zes meest voorkomende categorieën — tekst met laag contrast, ontbrekende alt-tekst, ontbrekende formulierlabels, lege links, lege knoppen en ontbrekende documenttaal — zijn goed voor 96% van alle gedetecteerde fouten, en deze meest voorkomende fouten zijn de afgelopen zeven jaar hetzelfde gebleven. Geautomatiseerde tools zijn oprecht nuttig bij het naar boven halen van deze veelvoorkomende, laag-complexe overtredingen op schaal. Het probleem is dat het oplossen van alleen deze issues een site nog steeds achterlaat met het grootste deel van zijn echte barrières intact.

Waarom de kloof bestaat: wat scanners niet kunnen beoordelen

Het dekkingsplafond is geen falen van engineering — het is een fundamentele beperking van wat een machine kan beoordelen zonder menselijk oordeel. De kloof bestaat omdat machines geen context, gebruikersintentie of subjectieve kwesties kunnen begrijpen, zoals of de koppenhiërarchie logisch is of of alt-tekst accuraat is. Een scanner kan bevestigen dat een afbeelding een alt-attribuut heeft. Hij kan je niet vertellen of dat attribuut "photo-123-final-v2.jpg" luidt of een echt nuttige beschrijving. Tools kunnen markeren dat een afbeelding alt-tekst heeft, maar alleen een persoon kan beoordelen of die tekst de afbeelding daadwerkelijk goed beschrijft.

Dit zijn de belangrijkste categorieën problemen die consequent aan geautomatiseerde detectie ontsnappen:

• Screenreader-ervaring: Geautomatiseerde tools kunnen niet luisteren naar hoe een screenreader content aankondigt. Ze kunnen de geldigheid van ARIA-attributen controleren, maar niet bepalen of de resulterende aankondigingen logisch zijn voor gebruikers. Een formulierveld kan een technisch geldig aria-label hebben dat voor een echte NVDA- of JAWS-gebruiker wordt voorgelezen als een verwarrende reeks tekens.
• Logische lees- en focusvolgorde: In de praktijk is de leesvolgorde vaak niet logisch wanneer screenreader-gebruikers informatie benaderen die visueel misschien perfect leesbaar is. In een kolomlay-out leest een screenreader de eerste regel van kolom 1 en daarna kolom 2, wat tot verwarring leidt. Scanners analyseren de DOM-volgorde geïsoleerd, zonder de context van hoe de visuele lay-out die volgorde voor een ziende gebruiker transformeert.
• Betekenisvolle link- en knoptekst in context: Geautomatiseerde tools kunnen controleren of een link bestaat en of die tekst bevat, maar ze kunnen niet altijd beoordelen of het doel van die link duidelijk is. Vijf "Lees meer"-links op dezelfde pagina slagen allemaal voor geautomatiseerde checks en falen allemaal voor echte gebruikers die moeten begrijpen waar elke link naartoe leidt.
• Dynamische content en live regions: Geautomatiseerde tools zullen problemen met dynamisch geladen content niet kunnen detecteren. Je moet de test opnieuw uitvoeren nadat de dynamische update is toegevoegd — maar zelfs dan kan de tool niet zeggen of een screenreader het zal voorlezen of niet.
• Cognitieve toegankelijkheid en duidelijke taal: Automatisering kan structurele problemen detecteren zoals kopvolgorde of de aanwezigheid van labels, maar kan leesbaarheid, helderheid of de vraag of instructies gemakkelijk te volgen zijn niet beoordelen. Een complex meerstaps-afrekenproces met verwarrende foutmeldingen kan structureel "schoon" zijn en toch diep ontoegankelijk voor gebruikers met cognitieve beperkingen.
• Toetsenbordnavigatie in complexe interacties: Automatisering kan basisfocus en -bedienbaarheid met het toetsenbord testen, maar kan complexe meerstapsinteracties, aangepaste gebaren of alternatieve invoerapparaten niet volledig valideren. Een aangepaste datumprikker-widget kan in theorie volledig met het toetsenbord bedienbaar zijn en in de praktijk een complete valkuil.
• Overlappende visuele elementen en verloopcontrast: Geautomatiseerde tools kunnen contrastverhoudingen evalueren, maar houden niet altijd rekening met overlappende elementen, afbeeldingen achter tekst of dynamisch veranderende content die de leesbaarheid verstoort.

Een schone geautomatiseerde scan betekent dat je de 30–40% van de problemen hebt aangepakt die automatisering kan vangen. De resterende 60–70% is ongetest. Claim nooit WCAG-naleving uitsluitend op basis van geautomatiseerd testen.

Eén bijzonder opvallend bewijsstuk: in één studie creëerden overheidsadvocaten voor toegankelijkheid in het Verenigd Koninkrijk opzettelijk een webpagina met 142 toegankelijkheidsbarrières, waarna ze de pagina analyseerden met 13 geautomatiseerde toegankelijkheidstools. De best presterende tool kon slechts 40% van de barrières identificeren. De slechtst presterende tool vond slechts 13%. Zelfs wanneer de kaarten in het voordeel van de tools waren geschud — met een gecontroleerde pagina met bekende, gedocumenteerde problemen — waren de resultaten ontnuchterend. En tools combineren lost het niet volledig op: zelfs met zes tools parallel ingezet, wordt de helft van alle WCAG 2-succescriteria niet gedekt en wordt 6 op de 10 overtredingen gemist.

Het juridische risico van te veel vertrouwen op automatisering

Dit is niet alleen een theoretische zorg over gebruikerservaring. De juridische inzet bij niet-naleving van toegankelijkheid neemt scherp toe, en een geslaagde geautomatiseerde scan biedt vrijwel geen bescherming in een rechtszaak. In 2024 werden meer dan 4.000 rechtszaken aangespannen bij Amerikaanse rechtbanken wegens barrières voor website- of mobiele toegankelijkheid. Alleen al in de eerste helft van 2025 waren er 2.014 ADA-websitezaken — een stijging van 37% ten opzichte van 2024.

Schikkingen buiten de rechtbank bedragen gemiddeld $30.000, terwijl rechterlijke uitspraken gemiddeld $85.000 bedragen. Verdedigingskosten voor advocaten van $30.000–$175.000 komen daar in alle gevallen nog bovenop. Erger nog, één keer schikken is geen garantie op veiligheid: 45–46% van de federale rechtszaken over digitale toegankelijkheid in 2025 waren gericht op bedrijven die al eerder waren aangeklaagd. Aangeklaagd worden en alleen te repareren wat geautomatiseerde tools markeren, zonder de bredere structurele hiaten aan te pakken, schildert simpelweg een doelwit op je rug voor de volgende eiser.

Het is ook de moeite waard om een veelvoorkomend misverstand over toegankelijkheidswidgets en overlays als snelkoppeling naar naleving te adresseren. Gegevens uit 2025 laten zien dat 456 ADA-rechtszaken werden aangespannen tegen websites die toegankelijkheidswidgets hadden geïnstalleerd, goed voor 22,64% van het totale aantal rechtszaken — wat benadrukt dat simpelweg een toegankelijkheidswidget toevoegen geen allesomvattende oplossing is. Geautomatiseerde tools kunnen slechts 30% van de WCAG-problemen detecteren, wat betekent dat elke tool of widget die puur op geautomatiseerde detectie vertrouwt per definitie het merendeel van de problemen onopgelost laat. Wat een echt waardevolle toegankelijkheids-SDK — zoals Accsible — onderscheidt van de overlay-producten die met juridische en regelgevende tegenwind te maken hebben gehad, is de combinatie van geautomatiseerde remediatie met een inzet voor een eerlijke, gelaagde nalevingsstrategie in plaats van valse garanties.

Een gelaagde teststrategie die wél werkt

Het antwoord op de dekkingskloof is niet om geautomatiseerde scanners af te schaffen — het is om ze correct te gebruiken, als de eerste laag in een uitgebreide strategie, niet de laatste. Van de 86 WCAG 2.2-succescriteria vereist zeventig procent menselijke beoordeling om de criteria correct te interpreteren en toe te passen op de grijze gebieden buiten het bereik van geautomatiseerde toegankelijkheidstechnologie. Dat betekent dat menselijk oordeel niet optioneel is — het is structureel vereist door de standaard zelf.

Een robuust toegankelijkheidstestprogramma werkt doorgaans in drie lagen:

1. Geautomatiseerde scanning (continu): Integreer scanners zoals axe-core in je CI/CD-pijplijn en voer ze uit bij elke build. Vang de structurele, binaire overtredingen voordat ze productie bereiken. Stel drempels in en laat builds falen bij nieuwe kritieke overtredingen. Dit is je vangnet voor de voor de hand liggende zaken — snel, schaalbaar en goedkoop. Voer geautomatiseerde tools vroeg en vaak uit tijdens de ontwikkeling. Integreer axe of WAVE in je CI/CD-pijplijn zodat problemen worden opgevangen voordat code QA bereikt. Dit verplaatst toegankelijkheidstesten naar links, zodat problemen worden gevonden wanneer ze het goedkoopst zijn om op te lossen.
2. Handmatige audit door experts (periodiek): Voer gestructureerde handmatige audits uit aan de hand van de volledige WCAG-checklist, uitgevoerd door mensen met diepgaande toegankelijkheidskennis. Handmatige toegankelijkheidstests worden uitgevoerd door getrainde experts die websites actief gebruiken met ondersteunende technologieën zoals screenreaders, toetsenbordnavigatie of vergrotingssoftware. Ze beoordelen context en gebruikerservaring — de logische focusvolgorde en het intuïtieve gevoel van navigatie, de duidelijkheid van formulieren en foutmeldingen, leesbaarheid binnen complexe content. Handmatige audits vinden doorgaans per kwartaal plaats of wanneer grote features live gaan, en ze moeten je drukstbezochte gebruikersflows end-to-end dekken. Begeleide handmatige toegankelijkheidsaudits zitten tussen volledig handmatig en volledig geautomatiseerd testen in, verkleinen de dekkingskloof en sommige schattingen plaatsen de dekking met deze aanpak op wel 80%.
3. Testen met ondersteunende technologie en gebruikers (doorlopend): Je kunt niet uitsluitend vertrouwen op geautomatiseerde tools om toegankelijkheidsproblemen op je site vast te stellen. Elk websiteproject heeft een gebruikers­teststrategie nodig, en het is sterk aan te raden om toegankelijkheidsgebruikersgroepen op te nemen — screenreader-gebruikers, gebruikers die alleen het toetsenbord gebruiken, gebruikers die niet kunnen horen, gebruikers met motorische beperkingen. Echte gebruikers met een beperking vinden problemen die geen enkele checklist voorziet. Test met NVDA en JAWS op Windows, VoiceOver op macOS en iOS, en TalkBack op Android. Doorloop je volledige afreken- of aanmeldflow uitsluitend met het toetsenbord. Luister daadwerkelijk naar hoe je content klinkt wanneer die wordt voorgelezen.

Wanneer teams alle drie de lagen implementeren, kan de gecombineerde dekking oplopen tot 80–90% van de problemen in de echte wereld — een dramatische verbetering ten opzichte van het plafond van 30–57% bij alleen automatisering. Het doel is niet perfectie op dag één; het is een systematisch, gedocumenteerd proces dat blijk geeft van oprechte inspanning te goeder trouw en de kloof continu verkleint.

Toegankelijkheid integreren in je ontwikkelworkflow

De belangrijkste culturele verschuiving is om toegankelijkheid te verplaatsen van een checklist vóór de lancering naar een continue praktijk. Veel organisaties maken de fout het te behandelen als een eenmalige audit die ze laten uitvoeren wanneer ze een rechtszaak vrezen, in plaats van als een kwaliteitsnorm die in elke sprint is ingebakken. Tegen de tijd dat een audit problemen in een productiesysteem aan het licht brengt, zijn de kosten om ze op te lossen vijf tot tien keer hoger dan in de ontwerpfase.

Begin met het opnemen van toegankelijkheidscriteria in je definitie van klaar. Wanneer een ontwikkelaar een nieuw component oplevert, moet er automatisch een snelle geautomatiseerde check draaien. Wanneer een designer een nieuw patroon maakt, moeten kleurcontrast en focusstaten worden beoordeeld voordat het ontwerp überhaupt wordt overgedragen. Wanneer een contenteditor een nieuwe afbeelding toevoegt, moet die een duidelijk begrip hebben van hoe betekenisvolle alt-tekst eruitziet — niet alleen dat alt-tekst vereist is.

Voor compliance-managers is de praktische implicatie documentatie. Sommige teams voeren geautomatiseerde tests uit maar pakken de bevindingen nooit aan. Dit levert geen waarde op en creëert documentatie waaruit blijkt dat je op de hoogte was van problemen maar ze niet hebt opgelost — problematisch in juridische situaties. Een toegankelijkheidsprogramma is alleen verdedigbaar als je een redelijke, te goeder trouw gevolgde aanpak van continue verbetering kunt aantonen: regelmatige scans, gedocumenteerde bevindingen, een remediatie-roadmap en bewijs dat je handelt op basis van wat je leert. WCAG-conformiteit is geen binair iets dat je één keer bereikt — het is een houding die je onderhoudt.

Tools zoals Accsible bestaan om deze gelaagde aanpak te ondersteunen — door een SDK te bieden die toegankelijkheidsverbeteringen direct in de gebruikerservaring inbedt, realtime problemen naar boven haalt en het handmatige auditproces aanvult in plaats van te proberen het te vervangen. De juiste overlay of SDK is geen magisch schild tegen rechtszaken; het is één onderdeel van een doordacht programma dat erkent wat automatisering wel en niet kan.

Belangrijkste inzichten

• Geautomatiseerde scanners zijn een startpunt, geen finish. Zelfs de beste tools detecteren tussen de 30% en 57% van de echte WCAG-overtredingen. Een schoon scanrapport betekent niet dat je site toegankelijk is — het betekent dat de detecteerbare subset van problemen is aangepakt.
• De meerderheid van de WCAG-succescriteria vereist menselijk oordeel. Screenreader-ervaring, logische leesvolgorde, betekenisvolle linktekst in context, cognitieve helderheid en complexe toetsenbordinteracties zijn allemaal gebieden waar automatisering structureel niet in staat is je een betrouwbaar antwoord te geven.
• De juridische omgeving is vijandig tegenover zelfgenoegzaamheid. Meer dan 5.100 federale ADA-websitezaken werden aangespannen in 2025, schikkingen kosten routinematig $30.000–$85.000 plus verdedigingskosten, en bijna de helft van de gedaagden was al eerder aangeklaagd — wat suggereert dat oppervlakkige fixes niet genoeg zijn.
• Een drielaagse strategie — geautomatiseerde scanning, handmatige audits door experts en echt testen met ondersteunende technologie — kan de dekking richting 80–90% duwen en geeft je de gedocumenteerde, te goeder trouw gevolgde nalevingshouding die rechtbanken en toezichthouders verwachten te zien.
• Verplaats toegankelijkheid naar links. Problemen in de ontwerp- en ontwikkelfase opsporen kost een fractie van wat remediatie na de lancering kost. Integreer geautomatiseerde checks in CI/CD, maak toegankelijkheid onderdeel van je definitie van klaar en voer regelmatige handmatige audits uit op je drukstbezochte gebruikersflows.