Hier is een ongemakkelijke waarheid: 94,8% van de top een miljoen websites slaagt niet voor basale toegankelijkheidscontroles, volgens het WebAIM Million 2025-rapport. Dat cijfer is in vijf jaar nauwelijks veranderd, ondanks groeiend bewustzijn, nieuwe wetten en een vloed aan geautomatiseerde tools die beloven alles op te lossen. Dus wat gaat er mis? Meestal slaan mensen de moeilijke delen over. Ze voeren een geautomatiseerde scan uit, lossen een paar kleurcontrastproblemen op en beschouwen het als afgerond. Maar geautomatiseerde tools vangen slechts 30% tot 57% van de WCAG-overtredingen op. De rest vereist dat een mens gaat zitten, de muis weglegt, een schermlezer opstart en daadwerkelijk probeert de website te gebruiken. Met de European Accessibility Act van kracht sinds juni 2025, de digitale ADA Title II-vereisten die in april 2026 ingaan, en meer dan 5.100 toegankelijkheidsrechtszaken ingediend in alleen al 2025, is er nog nooit zoveel op het spel gestaan. Deze gids leidt je door een compleet auditproces in acht concrete stappen. Geen opvulling, geen theoretische kaders die je nooit zult gebruiken. Alleen praktische technieken die echte problemen vinden op echte websites.
Wat is een webtoegankelijkheidsaudit precies?
Een webtoegankelijkheidsaudit is een gestructureerde evaluatie van een website aan de hand van vastgestelde toegankelijkheidsstandaarden, voornamelijk de Web Content Accessibility Guidelines (WCAG). Het doel is eenvoudig: elke barrière identificeren die mensen met een beperking verhindert om je site waar te nemen, te begrijpen, te navigeren en ermee te interacteren.
Denk eraan als een gebouwinspectie, maar dan voor je digitale eigendom. Een inspecteur controleert hellingen, liftknopppen, deurbreedtes en bebording. Een toegankelijkheidsauditor controleert toetsenbordnavigatie, schermlezercompatibiliteit, kleurcontrast, formulierlabels en tientallen andere criteria.
Er zijn drie typen toegankelijkheidsaudits, en het verschil begrijpen is belangrijk omdat het je verwachtingen en budget bepaalt.
Drie typen audits
Het eerste type is een puur geautomatiseerde audit. Je voert een tool uit zoals axe, WAVE, Lighthouse of web-accessibility-checker.com op je pagina's en krijgt een rapport van machinaal detecteerbare problemen. Dit is snel en goedkoop, maar vangt slechts 30% tot 57% van de WCAG-overtredingen op. Ontbrekende alt-tekst? Geautomatiseerde tools vinden het direct. Slechte alt-tekst die "image123.jpg" zegt in plaats van de inhoud te beschrijven? Geen idee. Het tweede type is een handmatige audit uitgevoerd door toegankelijkheidsspecialisten. Zij navigeren met het toetsenbord, testen met schermlezers, evalueren inhouds kwaliteit en controleren interacties die geen algoritme kan beoordelen. Dit vindt de overige 43% tot 70% van de problemen maar vereist getrainde mensen en aanzienlijke tijd. Het derde type, en degene waar je naar moet streven, is een hybride audit die beide benaderingen combineert. Begin met geautomatiseerd scannen om de duidelijke overtredingen op schaal te vangen, voeg dan handmatige tests toe voor de genuanceerde problemen. Dit is precies wat we stap voor stap gaan doorlopen. Voor een snelle referentieversie om af te drukken, bekijk onze toegankelijkheidsaudit checklist.Stap 1: Definieer de auditscope
Voordat je een tool aanraakt, moet je drie vragen beantwoorden. Welke pagina's ga je testen? Welke standaard gebruik je als maatstaf? En hoe groot is je steekproef? Voor de standaard is WCAG 2.1 Niveau AA de baseline die vrijwel elke toegankelijkheidswet noemt. De European Accessibility Act schrijft het voor. ADA-rechtszaken verwijzen ernaar. Als je net begint, richt je op WCAG 2.1 AA. Wil je verder gaan, dan heeft WCAG 2.2 in oktober 2023 negen nieuwe succescriteria toegevoegd, waaronder eisen voor focusweergave, sleepbewegingen en consistente hulpplaatsing. Onze WCAG-gids legt de verschillen in detail uit. Voor paginaselectie: probeer niet elke pagina van een grote site te auditen. Selecteer in plaats daarvan een representatieve steekproef die elk uniek template en elk kritiek gebruikerspad dekt. Dat betekent typisch: de homepage, hoofdnavigatiepagina's, minstens één pagina van elk contenttype (artikel, product, overzicht, formulier), het complete checkout- of conversieproces, login- en accountpagina's, zoekresultaten, foutpagina's en elke pagina met complexe interactieve componenten zoals modals, carrousels of datatables. Voor een site met minder dan 50 pagina's: audit alles. Voor grotere sites vangt een steekproef van 20 tot 40 pagina's gewoonlijk alle unieke patronen op. Het belangrijkste inzicht is dat het repareren van een template elke pagina repareert die dat template gebruikt, waardoor je een cascade-effect krijgt door je te richten op templates in plaats van individuele pagina's.Stap 2: Voer geautomatiseerd scannen uit
Begin je audit met geautomatiseerde tools omdat ze onmiddellijke, kwantificeerbare resultaten geven over veel pagina's. Beschouw dit als triage: je identificeert de meest voor de hand liggende problemen voordat je dieper graaft. Voer je site door web-accessibility-checker.com om snel een baselinescore te krijgen. De gratis scan controleert je pagina aan WCAG-criteria in minder dan een seconde voor DOM-gebaseerde problemen, met een diepere analyse erna. Je krijgt een uitsplitsing per ernst en WCAG-principe die je helpt de omvang van het werk te begrijpen. Controleer dan kruislings met minstens één ander tool. Elke geautomatiseerde scanner gebruikt licht verschillende regelsets en heuristieken, dus het combineren van twee tools vangt meer problemen op dan elk afzonderlijk. Goede gratis opties zijn WAVE (uitstekend voor visuele overlay van problemen), axe DevTools (sterke browserextensie met gedetailleerde uitleg) en Lighthouse (ingebouwd in Chrome, goed voor toegankelijkheid plus prestaties en SEO). Pa11y werkt goed voor commandoregel-integratie en CI/CD-pipelines. Documenteer elke bevinding in een spreadsheet of issue tracker. Voor elk probleem noteer je de pagina-URL, het geschonden WCAG-succescriterium, een screenshot of codefragment, het ernstniveau en welk tool het meldde. Een waarschuwing: stop hier niet. Ik heb te veel organisaties gezien die een geautomatiseerde scan uitvoeren, alles repareren wat het vindt, en zichzelf toegankelijk verklaren. Dat laat minimaal 43% van de problemen volledig onbehandeld. Voor een diepere vergelijking van testtools, bekijk onze gids voor de beste toegankelijkheidstools.Stap 3: Handmatige toetsenbordtests
Leg je muis in een la. Serieus. In deze stap navigeer je je hele steekproef met alleen het toetsenbord, en je zult verbaasd zijn hoe snel dingen uit elkaar vallen op veel websites.
Hier zijn de toetsen die je nodig hebt: Tab beweegt vooruit door interactieve elementen. Shift plus Tab beweegt achteruit. Enter activeert links en knoppen. Spatie activeert knoppen, selectievakjes en toggles. Escape sluit modals en dropdowns. Pijltoetsen navigeren binnen componenten zoals menu's, tabs, radiogroepen en schuifregelaars.
Begin op de homepage en druk herhaaldelijk op Tab. Let op deze specifieke problemen:
Focuszichtbaarheid. Kun je altijd zien welk element momenteel gefocust is? Een zichtbare focusindicator is vereist door WCAG 2.4.7 (Niveau AA). Veel sites verwijderen de standaard browseromlijning om esthetische redenen en vergeten deze te vervangen door iets beters. Als je je positie op de pagina kwijtraakt, is dat een fout.
Tabvolgorde. Beweegt de focus in een logische volgorde door de pagina? Het moet de visuele leesvolgorde volgen, over het algemeen van links naar rechts en van boven naar beneden voor LTR-talen. Als de focus willekeurig over de pagina springt, komt de onderliggende DOM-volgorde waarschijnlijk niet overeen met de visuele indeling.
Toetsenbordvallen. Kun je altijd van het huidige element wegbewegen? Probeer in en uit elk interactief component te tabben: menu's, modals, datumpickers, videospelers, ingebedde kaarten, carrousels. Als je vastzit en er niet met Tab of Escape uit kunt, is dat een toetsenbordval en een Niveau A-fout, het meest ernstige type.
Interactieve functionaliteit. Kun je elke functie bedienen? Elk dropdown openen, elk formulier verzenden, elke video afspelen, elk popup sluiten, elk meerstappenproces voltooien. Als enige functionaliteit alleen met de muis werkt, is het ontoegankelijk.
Skip-links. Biedt de site een link "Ga naar hoofdinhoud" die verschijnt bij Tab? Zonder deze moeten toetsenbordgebruikers door de hele navigatie tabben op elke pagina.
Stap 4: Schermlezertests
Schermlezertests onthullen een compleet andere dimensie van je site. Content die visueel perfect georganiseerd lijkt, kan een onsamenhangend chaos zijn wanneer sequentieel voorgelezen.
Volgens de WebAIM Screen Reader User Survey nummer 10 heeft JAWS 41% marktaandeel op desktop, NVDA volgt met 38%, en VoiceOver domineert mobiel met 70,6%. Je hoeft niet met allemaal te testen, maar je zou met minstens één desktoplezer en één mobiele lezer moeten testen.
Begin praktisch gezien met NVDA op Windows (gratis) of VoiceOver op Mac (ingebouwd, activeer met Command plus F5). Op mobiel gebruik je VoiceOver op iOS of TalkBack op Android.
Waar je op moet letten tijdens schermlezertests:
Paginastructuur. Wanneer je navigeert per kop (druk H in NVDA of gebruik de rotor in VoiceOver), weerspiegelen de koppen nauwkeurig de inhoudshiërarchie? Zijn er overgeslagen niveaus, zoals van h2 naar h4 springen? Heeft elke sectie een betekenisvolle kop?
Afbeeldingsbeschrijvingen. Navigeer naar elke afbeelding en luister naar de alt-tekst. Is deze beschrijvend en nuttig? Een alt van "foto" op een productafbeelding faalt de test, ook al zouden geautomatiseerde tools het markeren als aanwezige alt-tekst. Decoratieve afbeeldingen moeten lege alt-attributen hebben zodat schermlezers ze volledig overslaan.
Formulierinteracties. Tab door elk formulier. Kondigt elk veld zijn label aan? Worden verplichte velden aangegeven? Wanneer je indient met fouten, worden de foutmeldingen aangekondigd en gekoppeld aan de juiste velden?
ARIA-gebruik. Hier creëren veel sites meer problemen dan ze oplossen. Pagina's met ARIA-attributen hadden feitelijk 34,2% meer gedetecteerde fouten dan pagina's zonder ARIA, volgens het WebAIM Million 2025. Dat komt niet omdat ARIA slecht is, maar omdat het frequent verkeerd wordt gebruikt.
Dynamische content. Wanneer content op de pagina verandert, kondigt de schermlezer dit aan? Dit omvat formuliervalidatieberichten, laadstatussen, notificatiebanners, live chat widgets en alle content bijgewerkt via JavaScript zonder paginalading. ARIA live regions behandelen dit, maar ze moeten correct geïmplementeerd zijn.
Stap 5: Controleer kleur en contrast
Kleurcontrastfouten zijn het meest voorkomende toegankelijkheidsprobleem op het web en treffen 79,1% van de top een miljoen homepages volgens WebAIM. Het goede nieuws is dat contrastproblemen eenvoudig te identificeren en te repareren zijn.
WCAG definieert drie contrastdrempels. Normale tekst (onder 18pt of onder 14pt vet) heeft een contrastverhouding van 4,5 op 1 nodig ten opzichte van de achtergrond. Grote tekst (18pt en groter, of 14pt vet en groter) heeft 3 op 1 nodig. Gebruikersinterfacecomponenten en grafische objecten die informatie overbrengen hebben 3 op 1 nodig.
Gebruik de Colour Contrast Analyser (gratis, van TPGi) om specifieke kleurcombinaties te controleren, of gebruik de contrastcontroles ingebouwd in je geautomatiseerde tools uit Stap 2. Let vooral op tekst over afbeeldingen of verlopen, waar contrast kan variëren. Placeholder-tekst in formuliervelden staat berucht om het niet voldoen aan contrastvereisten.
Controleer naast contrastverhoudingen dat je site niet uitsluitend op kleur vertrouwt om informatie over te brengen. Foutmeldingen moeten niet alleen rood worden; ze hebben ook een pictogram of tekstlabel nodig. Grafieken hebben patronen of labels nodig naast kleurcodering. Linktekst in alinea's moet een niet-kleurindicator hebben zoals een onderstreping, niet alleen een andere kleur.
Stap 6: Beoordeel de contentskwaliteit
Deze stap gaat verder dan technische conformiteit naar de effectiviteit van content. Geautomatiseerde tools signaleren de aan- of afwezigheid van elementen, maar kunnen geen kwaliteit beoordelen. Hier heb je menselijke ogen en oordeel nodig. Alt-tekstkwaliteit. Elke informatieve afbeelding heeft alt-tekst nodig die hetzelfde doel dient als de afbeelding. Een foto van een teamvergadering moet relevante details beschrijven, niet simpelweg "vergadering" zeggen. Een grafiek moet het belangrijkste datapunt of de trend overbrengen. Complexe afbeeldingen zoals infographics hebben mogelijk een langere beschrijving nodig via een gekoppeld tekstalternatief. Koppenstructuur. Je koppenhiërarchie moet leesbaar zijn als een inhoudsopgave. Schermlezergebruikers navigeren frequent per kop om pagina-inhoud te scannen, dus je koppen moeten beschrijvend en correct genest zijn. Geen niveaus overslaan. Geen koptags gebruiken alleen om tekst groter te maken. Paginataal. Elke pagina moet zijn taal declareren in het HTML lang-attribuut. Content in een andere taal binnen de pagina heeft een lang-attribuut nodig op zijn container. Ontbrekende documenttaal is een van de meest voorkomende WCAG-fouten. Formulierontwerp. Elk formulierveld heeft een zichtbaar, gekoppeld label nodig. Groepeer gerelateerde velden met fieldset en legend. Geef duidelijke instructies voor het formulier, niet alleen erin. Foutmeldingen moeten het probleem specifiek identificeren in plaats van generiek. Zorg dat foutherstel makkelijk is en eerder ingevoerde geldige gegevens niet wist. Datatables. Gebruik juiste tabelkoppen (th-elementen) met scope-attributen. Vermijd tabellen voor layout. Complexe tabellen met samengevoegde cellen hebben extra markup nodig om begrijpbaar te blijven voor hulptechnologieën. Voor bredere context over nalevingsvereisten dekt onze ADA-nalevingsgids de juridische standaarden die je content moet voldoen.Stap 7: Test op mobiele apparaten
Mobiele toegankelijkheidstests vangen problemen op die desktoptests volledig missen. Meer dan 60% van het webverkeer komt van mobiele apparaten, en mensen met een beperking zijn intensieve mobiele gebruikers omdat smartphones uitstekende ingebouwde toegankelijkheidsfuncties hebben.
Aanraakdoelgrootte. WCAG 2.2 vereist dat interactieve elementen minstens 24 bij 24 CSS-pixels zijn voor Niveau AA-conformiteit, met een aanbeveling van 44 bij 44 pixels voor AAA. Meet je knoppen, links, formuliervelden en elk tikbaar element. Let vooral op elementen die dicht bij elkaar staan, zoals navigatielinks in een footer of actieknoppen in een lijst. Kleine, dicht op elkaar staande doelen zijn een nachtmerrie voor gebruikers met motorische beperkingen.
Zoom en herschikking. Zoom naar 200% en dan naar 400%. Content moet herschikken naar een enkele kolom zonder horizontaal scrollen, zonder overlappende elementen en zonder functionaliteitsverlies. Slechtziende gebruikers zoomen frequent, en een site die bij 200% breekt faalt WCAG 1.4.4.
Oriëntatie. Je site moet werken in zowel portret- als landschapsoriëntatie, tenzij een specifieke oriëntatie essentieel is (wat extreem zeldzaam is). Sommige gebruikers monteren hun apparaten in een vaste oriëntatie vanwege fysieke beperkingen.
Aanraakgebaren. Als je site complexe gebaren gebruikt zoals knijpen, meervinger-swipen of lang indrukken, bied dan alternatieven met één aanwijzer. Een carrousel die een swipe vereist heeft ook vorige- en volgende-knoppen nodig.
Test met VoiceOver op iOS en TalkBack op Android. De ervaring verschilt merkbaar van desktop-schermlezers.
Stap 8: Documenteer en rapporteer je bevindingen
Alles wat je in stappen 2 tot en met 7 hebt gevonden, moet worden georganiseerd in een actiegerichte rapportage. Dit is geen documentatie om de documentatie; een goed gestructureerd rapport bepaalt of problemen daadwerkelijk worden opgelost of voor altijd in een backlog blijven liggen. Een sterk auditrapport bevat zes secties. Begin met een managementsamenvatting die het algehele conformiteitsniveau en risico communiceert aan niet-technische stakeholders. Voeg een numerieke score of cijfer toe en een duidelijke verklaring van wat het betekent. Documenteer vervolgens je scope en methodologie: welke pagina's zijn getest, welke tools en technieken zijn gebruikt, welke WCAG-versie en conformiteitsniveau je hebt gemeten, en eventuele beperkingen van de audit. Organiseer dan bevindingen per WCAG-principe. Groepeer problemen onder Waarneembaar, Bedienbaar, Begrijpelijk en Robuust. Binnen elk principe lijst je de specifieke succescriteria op die niet voldeden. Voor elk individueel probleem voeg je het WCAG-succescriterium toe, het ernstniveau, de getroffen pagina's of componenten, een duidelijke probleembeschrijving, een screenshot of codefragment, en een specifieke herstel aanbeveling met codevoorbeelden waar mogelijk. Bied na de bevindingen een herstelroadmap met geprioriteerde fasen. Voeg ten slotte een hertestplan toe dat specificeert wanneer en hoe je zult verifiëren dat fixes correct zijn geïmplementeerd. Een audit zonder hertestcyclus is maar half werk. Als je na je audit een toegankelijkheidsverklaring moet publiceren, biedt ons sjabloon voor toegankelijkheidsverklaringen een kant-en-klaar format.Hoe prioriteer je wat eerst te repareren
Je hebt je auditrapport. Het vermeldt waarschijnlijk tientallen, misschien honderden problemen. Waar begin je?
Classificeer eerst elk probleem op ernst. Kritieke problemen blokkeren toegang volledig: een toetsenbordval die checkout verhindert, een formulier zonder labels, een video zonder ondertitels. Ernstige problemen maken taken zeer moeilijk maar niet onmogelijk. Matige problemen veroorzaken frustratie. Kleine problemen zijn technisch niet-conform maar hebben beperkte impact.
Pas dan een prioriteringsformule toe: bereik maal impact maal inspanning. Bereik vraagt hoeveel pagina's of gebruikers getroffen zijn. Impact vraagt hoe ernstig het probleem taakvoltooiing beïnvloedt. Inspanning vraagt hoeveel werk de reparatie vereist. Problemen met hoog bereik, hoge impact en lage inspanning gaan bovenaan de lijst.
In de praktijk werkt deze volgorde het best. Repareer eerst problemen op templateniveau omdat ze doorwerken op elke pagina die dat template gebruikt. Een ontbrekende skip-link in je header-template? Eenmaal repareren, en elke pagina is gerepareerd.
Repareer dan kritieke problemen op pagina's met hoog verkeer en hoge conversie. Je homepage, productpagina's, checkoutproces en contactformulieren verdienen prioriteit.
Werk vervolgens systematisch door ernstige en matige problemen. Groepeer per component: repareer alle koppenproblemen tegelijk, dan alle formulierproblemen, dan alle afbeeldingsproblemen.
Bewaar puur cosmetische of randgevalproblemen voor een onderhoudsfase.
De beste tools voor toegankelijkheidsaudits
Na het testen van tientallen tools over honderden audits, hier is wat echt werkt in de praktijk. Voor gratis tools is WAVE uitstekend voor visuele leerlingen omdat het pictogrammen direct op je pagina legt die tonen waar problemen zijn. axe DevTools is de referentie-browserextensie voor ontwikkelaars, met duidelijke uitleg en detail op codeniveau. Lighthouse is handig omdat het in Chrome is ingebouwd en toegankelijkheid combineert met prestatie- en SEO-controles. Pa11y is krachtig voor CI/CD-integratie. De Colour Contrast Analyser van TPGi behandelt contrastcontrole met een pipettool. Web-accessibility-checker.com biedt een gratis scan die je pagina in minder dan een seconde controleert op DOM-problemen en vervolgt met een diepere PageSpeed Insights-analyse. De betaalde monitoringplannen voegen geplande scans, historische tracking en multi-pagina-dekking toe. Voor betaalde enterprise-tools is Siteimprove uitgebreid maar duur op ongeveer 28.000 dollar per jaar. AudioEye begint bij 45 dollar per maand. axe Monitor van Deque breidt de gratis axe-engine uit met dashboardrapportage en teamfuncties. Level Access biedt volledige auditing met expertconsultants. De eerlijke waarheid is dat geen enkel tool voldoende is. Combineer een gratis scanner voor snelle controles, een browserextensie voor ontwikkeling, en handmatige tests voor volledigheid. De beste tool is degene die je team daadwerkelijk consistent gebruikt.Wat geautomatiseerde tools niet kunnen detecteren
De beperkingen van automatisering begrijpen maakt je een betere auditor. Hier zijn de categorieën die consequent menselijk oordeel vereisen.
Alt-tekstkwaliteit is het klassieke voorbeeld. Geautomatiseerde tools verifiëren dat alt-attributen bestaan maar kunnen niet evalueren of ze betekenisvol zijn. Een afbeelding met alt ingesteld op "DSC_0042.jpg" slaagt voor geautomatiseerde controles maar faalt volledig bij echte gebruikers.
Toetsenbordvaldetectie is deels automatiseerbaar maar onbetrouwbaar. Geautomatiseerde tools kunnen basale Tab-navigatie controleren, maar complexe widgets met conditioneel focusbeheer vereisen vaak een echt persoon die toetsen indrukt.
Leesvolgorde versus visuele volgorde. CSS Grid en Flexbox maken het makkelijk om layouts te creëren waar de visuele volgorde verschilt van de DOM-volgorde. Geautomatiseerde tools controleren het DOM; alleen een mens met een schermlezer of Tab-toets merkt wanneer dingen in de verkeerde volgorde worden gelezen.
Cognitieve toegankelijkheid is bijna geheel een kwestie van menselijk oordeel. Is de taal te complex? Zijn instructies duidelijk? Is de navigatie voorspelbaar? Zijn foutmeldingen behulpzaam?
ARIA-correctheid voorbij syntax. Geautomatiseerde tools kunnen verifiëren dat een ARIA-attribuut een geldige waarde heeft, maar kunnen niet vertellen of role="button" op een div die eruitziet en zich gedraagt als een link semantisch fout is. Het WebAIM Million vond dat pagina's met ARIA 34,2% meer fouten hadden.
De echte gebruikerservaring. Geen tool kan je vertellen of je checkoutproces daadwerkelijk bruikbaar is met een schermlezer. Dat vereist een mens die het hele proces doorloopt en evalueert of de algehele ervaring logisch is.
De meest voorkomende WCAG-fouten
De meest voorkomende fouten kennen helpt je om je audit te focussen en je verwachtingen te kalibreren. Het WebAIM Million 2025 analyseerde de homepages van de top een miljoen websites en vond deze hoofdproblemen. Tekst met laag contrast verscheen op 79,1% van de pagina's. Dit is met afstand de meest voorkomende toegankelijkheidsfout op het web. Lichtgrijze tekst op witte achtergronden, trendy kleurenschema's met laag contrast en onvoldoende placeholder-tekstcontrast zijn de gebruikelijke schuldigen. Ontbrekende alternatieve tekst voor afbeeldingen trof 55,5% van de pagina's. Dit omvat afbeeldingen zonder alt-attribuut en afbeeldingen met lege alt op niet-decoratieve content. Ontbrekende formulierlabels treffen een enorm aantal pagina's. Wanneer een formulierveld geen programmatisch label heeft, moeten schermlezergebruikers raden welke informatie in te voeren. Placeholder-tekst is geen acceptabel alternatief voor een label. Lege links en lege knoppen zijn links of knoppen die geen toegankelijke tekst bevatten. Een link die alleen een pictogram wikkelt zonder alt-tekst of aria-label faalt dit criterium. Ontbrekende documenttaal is een van de makkelijkst te repareren problemen. Het toevoegen van lang="nl" aan je HTML-tag duurt vijf seconden, toch laat een substantieel percentage van de pagina's het nog steeds weg. Dit zijn allemaal Niveau A-overtredingen, het meest basale toegankelijkheidsniveau. Als je site faalt op Niveau A, heeft het fundamentele problemen die dringend aandacht vereisen. Onze EAA-nalevingspagina legt uit hoe deze criteria zich vertalen naar Europese wettelijke vereisten.Kosten, ROI en de businesscase
Toegankelijkheidsaudits hebben duidelijke kosten en nog duidelijkere opbrengsten. De cijfers begrijpen helpt je budget te krijgen en de investering te rechtvaardigen.
Qua kosten kost een professionele audit van een kleine tot middelgrote website typisch tussen 1.250 en 5.500 dollar afhankelijk van scope en complexiteit. Enterprise-audits met honderden templates en complexe applicaties lopen van 25.000 tot 40.000 dollar of meer. Zelf-audits met het proces in deze gids kosten voornamelijk personeelstijd.
Bekijk nu de risicokant. De gemiddelde schikking voor een ADA webtoegankelijkheidsrechtszaak is ongeveer 25.000 dollar, exclusief juridische kosten, herstelkosten of reputatieschade. Met meer dan 5.100 rechtszaken in 2025 is dit geen theoretisch risico.
De ROI-cijfers zijn overtuigend. Forrester-onderzoek vond ongeveer 100 dollar rendement per geïnvesteerde dollar in toegankelijkheidsverbeteringen. Sites die toegankelijkheid verbeteren zien gemiddeld 23% meer organisch verkeer. Vanaf het begin toegankelijk bouwen bespaart 67% vergeleken met achteraf aanpassen.
Misschien het meest opvallende cijfer: winkelwagenverlatingspercentages dalen van ongeveer 69% op ontoegankelijke e-commercesites naar ongeveer 23% op toegankelijke sites. Wanneer mensen je site daadwerkelijk kunnen gebruiken, kopen ze. Dat alleen al kan de volledige kosten van een audit en herstelprogramma vele malen rechtvaardigen.
De businesscase schrijft zichzelf. Een audit is geen uitgave. Het is een investering die juridisch risico vermindert, je markt vergroot, SEO verbetert en conversies verhoogt.