Hoe je de toegankelijkheid van je website in 2 uur auditet: open-source stack en EAA-checklist

Door het Kiwop-team · Digitaal Agentschap gespecialiseerd in Softwareontwikkeling en toegepaste Kunstmatige Intelligentie · Gepubliceerd op 7 mei 2026 · Laatst bijgewerkt: 7 mei 2026

TL;DR — De deadline van de European Accessibility Act was 28 juni 2025. De meeste websites voldoen nog steeds niet. Dit artikel geeft je het praktische raamwerk: 5 open-source tools die ~70% van de automatisch detecteerbare fouten dekken, een volledige audit in 2 uur, en een EAA-checklist geprioriteerd op juridische impact. Zonder consultants, zonder speciaal budget. Alleen bewezen stack en kopieerbare commando's.

Toen de European Accessibility Act op 28 juni 2025 in werking trad, was de meest voorkomende reactie bij technische teams: "we kijken er volgende week naar". Tien maanden later ziet de meerderheid van die websites er nog hetzelfde uit. Het WebAIM Million 2024-rapport bevestigde het al vóór de deadline: 94,8% van de geanalyseerde homepagina's had automatisch detecteerbare WCAG-fouten.

Het probleem is niet gebrek aan wil. Het is gebrek aan een duidelijk startpunt. Je weet dat je aan WCAG 2.2 AA moet voldoen, je weet dat er tools zijn, maar je weet niet goed waar te beginnen, hoeveel tijd het kost en hoe je prioriteiten stelt bij wat je vindt.

Dit artikel is dat startpunt. Als je onze gids over de EAA-regelgeving, deadlines en sancties al hebt gelezen, is dit de volgende stap: de concrete technische procedure. Als je die nog niet hebt gelezen, doe dat dan eerst — hier gaan we ervan uit dat je weet wat de wet van je eist en focussen we ons op hoe je het uitvoert.

Waarom je NU auditeert (en niet volgende week)

De werkelijke EAA-nalevingsstatus in 2026

De deadline is verstreken. Dit is geen toekomstige dreiging: de EAA is al geldend recht in alle EU-lidstaten die de richtlijn vóór 28 juni 2025 hebben omgezet. En de nalevingscijfers zijn alarmerend.

Het WebAIM Million 2024 analyseerde de 1.000.000 meest bezochte homepagina's. Resultaat: 94,8% had minstens één automatisch detecteerbare WCAG 2.1 AA-fout — en dat is nog voordat je de fouten meerekent die alleen opduiken bij handmatige controle. De meest voorkomende fouten: laag kleurcontrast (81% van de pagina's), ontbrekende alt-tekst (54,5%), ontbrekende formulierlabels (48,6%), lege links (44,6%) en knoppen zonder toegankelijke naam (28,2%).

Anders gezegd: je website heeft vrijwel zeker al die problemen. De vraag is niet of je voldoet, maar hoeveel criteria je niet naleeft en hoe ernstig.

Het concrete juridische risico

Het officiële portaal van de Europese Commissie over de EAA is duidelijk: de regelgeving is van toepassing op elk bedrijf dat digitale producten of diensten aanbiedt aan consumenten in de EU, ongeacht de vestigingsplaats. De sancties worden bepaald door elke lidstaat afzonderlijk, maar de richtlijn eist dat ze "doeltreffend, evenredig en afschrikwekkend" zijn. In meerdere landen worden al boetes tot €100.000 per overtreding overwogen.

Buiten de boetes: elke persoon met een beperking die geen toegang heeft tot jouw dienst kan een formele klacht indienen bij het toezichthoudende orgaan in zijn land. De bewijslast rust op het bedrijf — jij moet aantonen dat je voldoet, niet zij dat je niet voldoet.

Wat de toezichthouder eist (en wat niet)

Wat wordt gevraagd is conformiteit met WCAG 2.2 niveau AA en een publieke toegankelijkheidsverklaring. Wat niet gevraagd wordt is absolute perfectie of een jaarlijkse audit ondertekend door een gecertificeerd bureau. Er wordt een redelijk niveau van due diligence gevraagd, gedocumenteerd.

Wat je niet redt: een JavaScript-overlay die over je website wordt gelegd en automatische toegankelijkheid belooft. De FTC beboette accessiBe met 1 miljoen dollar voor misleidende reclame precies op dit punt. Geen toezichthoudend orgaan accepteert een overlay als bewijs van naleving.

De echte eerste stap van die due diligence is de audit. En je kunt die in 2 uur uitvoeren met de juiste tools.

De stack: 5 open-source tools die ~70% van WCAG 2.2 AA dekken

Voordat je het proces bekijkt, begrijp je de fundamentele beperking van elke automatische tool: ze detecteren ongeveer 30-40% van de echte toegankelijkheidsproblemen. Dat zegt de W3C-gids voor toegankelijkheidsaudits. De rest vereist handmatige controle — toetsenbordnavigatie, schermlezers, menselijk oordeel.

Waarom dan beginnen met automatische tools? Omdat ze je in staat stellen de dikste laag van fouten systematisch in minuten te elimineren, waardoor tijd vrijkomt voor de handmatige controle waar de echte waarde ligt.

axe-core (Deque) — de industriestandaard motor

axe-core is de open-source bibliotheek van Deque Systems die tegenwoordig vrijwel alle toegankelijkheidstesttools in de industrie aandrijft. Chrome DevTools, Storybook, Playwright, Cypress en tientallen CI-frameworks gebruiken het. Het is niet één optie onder vele: het is de motor.

Het grootste voordeel is niet de dekking — het is de nagenoeg nul fout-positieven. Wanneer axe een fout rapporteert, is het een echte fout. Wanneer het niets rapporteert, betekent dat niet dat je in orde bent; het betekent dat de fouten die het niet detecteert in die 60-70% zitten die handmatige controle vereisen.

Je kunt axe op drie manieren gebruiken:

Als browserextensie (axe DevTools Free): installeer de extensie in Chrome of Firefox, open je pagina, voer de analyse uit. Resultaat in seconden. Nul configuratie. Ideaal voor het eerste contact.

Als bibliotheek in tests: integreer axe-core direct in je test suite met Playwright of Cypress:

Via CLI met @axe-core/cli:

Lighthouse — de gratis aanvulling van Chrome

Lighthouse bevat een toegankelijkheidsaudit in zijn standaardrapport, ook gebaseerd op axe-core, maar met extra dekking van prestatiecijfers en eigen controles.

De toegankelijkheidsscore (0-100) staat niet gelijk aan het percentage WCAG-naleving. Het is een relatieve maatstaf die als referentie dient. Het werkelijk nuttige is de gecategoriseerde issuelijst die het genereert.

Je kunt het uitvoeren via:

• Chrome DevTools → Lighthouse → Categorie "Toegankelijkheid"
• CLI: npx lighthouse https://jouw-website.nl --only-categories=accessibility --output json
• PageSpeed Insights: https://pagespeed.web.dev/ (gratis, niets installeren)

De officiële Lighthouse-documentatie voor toegankelijkheid van Google legt precies uit wat elk criterium controleert en hoe de score wordt berekend. Lees het een keer om de resultaten niet verkeerd te interpreteren.

Pa11y — audit vanuit CLI/CI

Pa11y is de commandoregelstool die is ontworpen voor integratie in CI/CD-pipelines. Het kan een enkele URL, een volledig sitemap of een lijst van pagina's auditeren en resultaten exporteren in meerdere formaten.

Pa11y gebruikt standaard htmlcs, maar kan worden geconfigureerd om axe-core als motor te gebruiken:

Het voordeel van Pa11y boven handmatig axe uitvoeren is dat het goed omgaat met pagina's met asynchrone JavaScript, basisauthenticatie en multi-pagina-sites zonder eigen scripts te schrijven.

NVDA + VoiceOver — de echte schermlezers

Geen automatische tool kan vervangen dat je 20 minuten door je website navigeert met een schermlezer. De resultaten zijn altijd onthullend — en altijd anders dan je verwachtte.

NVDA (Windows, gratis): de meest gebruikte schermlezer in Windows-omgevingen. Download het van nvaccess.org. De essentiële sneltoetsen voor een snelle audit:

VoiceOver (macOS/iOS, ingebouwd in het systeem): activeer met Cmd + F5. Voor een snelle audit op macOS:

Wat je met beide schermlezers zoekt: kondigt het het type van elk element correct aan (knop, link, veld)? Hebben formulieren labels? Hebben afbeeldingen nuttige alt-tekst? Is de leesvolgorde logisch?

WAVE (browserextensie) — snelle visuele controles

De extensie WAVE van WebAIM plaatst visuele pictogrammen direct over de pagina die fouten, waarschuwingen en structurele elementen aangeven. Het is de snelste manier om een visueel overzicht van problemen te krijgen zonder de browser te verlaten.

Bijzonder nuttig voor:

• In één oogopslag de headinghiërarchie zien (spring je van H1 naar H4?)
• Zones met laag contrast in visuele context detecteren
• Formulieren zonder label identificeren voordat je axe uitvoert
• Verifiëren dat ARIA-landmarks goed zijn gedefinieerd (header, nav, main, footer)

Gebruik het niet als primaire tool — het heeft meer fout-positieven dan axe. Gebruik het als eerste visuele blik voordat je de andere tools uitvoert.

Stap voor stap: je eerste audit in 2 uur

Dit protocol dekt de meest kritieke pagina's van je site: home, een lijstpagina, een detailpagina en de belangrijkste conversiestroom (contact, registratie of aankoop). Met de 2 uur zo verdeeld:

Minuut 0-15: setup → Minuut 15-45: automatisering → Minuut 45-90: handmatige controle → Minuut 90-120: prioritering en rapport

Minuut 0-15: setup

Voordat je tools lanceert, bepaal je exact welke pagina's je gaat auditeren. Een audit die probeert de hele site in één keer te dekken, eindigt zonder iets goed te dekken.

Aanbevolen minimumlijst voor een eerste audit:

1. Home (/)
2. Een representatieve lijst- of categoriepagina
3. Een representatieve detail- of servicepagina
4. Contact- of hoofdformulierpagina
5. Een checkout- of registratiepagina (indien van toepassing)

Installeer met die lijst de tools:

Installeer ook de WAVE-extensie in Chrome of Firefox, en download NVDA als je Windows gebruikt (of activeer VoiceOver op macOS met Cmd + F5).

Minuut 15-45: geautomatiseerde uitvoering (axe + Lighthouse + Pa11y)

Voer de drie tools uit op elke URL van je lijst. De volgorde doet er toe: begin met axe omdat de output het schoonst is, dan Lighthouse voor de gecombineerde weergave van prestaties + toegankelijkheid, en Pa11y om te valideren met een tweede motor.

Terwijl de scripts worden uitgevoerd, open je elke URL in Chrome met de WAVE-extensie actief. Noteer visueel de patronen die je ziet voordat je de rapporten leest.

Wanneer de scripts klaar zijn, open je de JSON-bestanden met een viewer of tel je de schendingen eenvoudig:

Minuut 45-90: handmatige tests met schermlezers

Dit is het deel dat het meeste oplevert en dat mensen het vaakst overslaan. Sla het niet over.

Protocol van 20 minuten met NVDA of VoiceOver (herhaal voor elke kritieke pagina):

1. Navigeer alleen met Tab vanaf het begin van de pagina. Is het eerste element "naar hoofdinhoud springen" (skip link)? Is de focus altijd zichtbaar? Is de volgorde logisch?

1. Open de headinglijst (Insert + F7 in NVDA, rotor in VoiceOver). Is er een H1? Is de hiërarchie coherent? Zijn er headings op elementen die visueel geen heading zijn?

1. Activeer formuliermodus als er formulieren zijn. Vul het formulier in met alleen het toetsenbord. Kondigt elk veld zijn label aan? Worden validatiefouten correct aangekondigd? Kun je het formulier indienen?

1. Navigeer via links (toets K in NVDA). Hebben alle links beschrijvende tekst buiten de context? Zegt geen enkele "klik hier", "meer bekijken" of "lees meer"?

1. Luister naar afbeeldingen. Wanneer de focus een afbeelding bereikt, beschrijft de alt-tekst de inhoud of functie? Worden decoratieve afbeeldingen genegeerd (alt="")?

Documenteer elk probleem dat je vindt met: URL, betrokken element, WCAG-criterium dat wordt geschonden, en prioriteit (die bespreken we in de volgende stap).

Minuut 90-120: prioritering en rapport

Je hebt twee bronnen van issues: de automatische rapporten en je handmatige notities. Het werk nu is ze samenvoegen en prioriteren op gebruikers- en juridische impact.

Probeer niets op te lossen. Het doel van de 2 uur is diagnose, niet herstel.

Maak voor het rapport een document met deze minimale structuur:

Resultaten interpreteren: prioritering op juridische impact

De grootste fout bij het interpreteren van een toegankelijkheidsaudit is alle issues gelijk behandelen. Laag contrast in een voettekstzin heeft zeer andere gevolgen dan een registratieformulier dat niet met het toetsenbord te bedienen is.

De prioriteringsmatrix combineert twee assen: ernst voor de gebruiker (blokkeert het gebruik?) en juridische blootstelling (raakt het kritieke stromen die de toezichthouder als eerste zou onderzoeken?).

Kritieke issues (blokkeren naleving)

Een issue is kritiek wanneer het een taak onmogelijk maakt voor een gebruiker met een beperking of wanneer het een stroom treft die de toezichthouder als eerste zou onderzoeken (registratie, aankoop, contact, toegang tot dienst).

De gebruikelijke kandidaten:

• Formulieren niet toegankelijk met toetsenbord: WCAG-criterium 2.1.1 (Toetsenbord) is niveau A — het minimumniveau. Dit niet naleven in het contactformulier is een directe nalevingsblokkade.
• Functionele afbeeldingen zonder alt: een afbeelding die een link of knop is zonder alt-tekst laat de schermlezergebruiker zonder informatie om te handelen. Criterium 1.1.1.
• Knoppen zonder toegankelijke naam: <button><svg>...</svg></button> zonder aria-label. De knop bestaat, de gebruiker weet dat hij er is, maar weet niet wat hij doet. Criterium 4.1.2.
• Video met audio zonder ondertiteling: als je video's hebt met informatie in audio, vereist criterium 1.2.2 gesynchroniseerde ondertitels. Afwezigheid is blokkerend en zeer zichtbaar.

Grote issues (hoog klachtenrisico)

Een issue is groot wanneer het gebruik aanzienlijk belemmert maar niet volledig blokkeert, of wanneer het invloed heeft op zeer zichtbare pagina's, ook al is de individuele impact gedeeltelijk.

• Laag contrast in hoofdtekst: criterium 1.4.3. Een verhouding onder 4,5:1 in lopende tekst treft gebruikers met laag zicht en gebruikers in moeilijke lichtomstandigheden (niet alleen mensen met een officieel vastgestelde beperking).
• Gebroken headinghiërarchie: springen van H1 naar H4, headings alleen voor visuele stijl gebruiken, of geen H1 hebben. Treft schermlezers en cognitieve gebruikers die door structuur navigeren. Criterium 1.3.1.
• Focus niet zichtbaar: als de outline van de focus globaal is verwijderd met *:focus { outline: none; }, wordt toetsenbordnavigatie ondoorzichtig. Criterium 2.4.7 (AA) en 2.4.11 (AA in WCAG 2.2).
• Foutmeldingen zonder ARIA live regions: wanneer een formulier valideert en fouten toont, kondigt de schermlezer die dan automatisch aan? Als niet, weet de gebruiker niet dat er iets fout ging. Criterium 3.3.1.

Kleine issues (verbeterpunten)

Een issue is klein wanneer het een beperkte impact heeft, secundaire elementen treft, of contextbeoordeling vereist om te bepalen of het echt een probleem is.

• Beschrijvende maar onnauwkeurige alt bij decoratieve of ondersteunende afbeeldingen.
• Contrast iets onder het minimum in voetteksten of disclaimers.
• Redundante ARIA-rollen die geen schade veroorzaken maar ook geen waarde toevoegen.
• Contextuele linkteksten (die logisch zijn met de omringende tekst, maar niet op zichzelf).

Negeer kleine issues niet voor onbepaalde tijd — ze stapelen zich op. Maar blokkeer de herstelwerkzaamheden voor kritieke issues niet door kleine issues eerst op te lossen.

Wat tools NIET detecteren (en je handmatig moet doen)

Hier zit de 60-70% die axe, Pa11y en Lighthouse niet zien. Dit blok is wat een echte audit onderscheidt van een automatische check en één klik op "delen". De W3C-documentatie over toegankelijkheidsbeoordeling behandelt dit rigoureus; hier de praktische versie.

"Decoratieve" alt-tekst verkeerd gebruikt: axe controleert of afbeeldingen alt hebben, maar kan niet weten of de alt-tekst de inhoud correct beschrijft. "Afbeelding 1" of de bestandsnaam slaagt de automatische check en is een echte fout.

Logische tabulatievolgorde: Tab doorloopt interactieve elementen in de DOM-volgorde. Als je CSS elementen visueel herordent, kan de tabulatievolgorde chaotisch zijn. Geen tool detecteert dit — alleen door met Tab te navigeren.

Correct gekoppelde formulierlabels: axe detecteert ontbrekende labels, maar detecteert geen labels die in de HTML staan maar niet correct gekoppeld zijn aan het juiste veld (door verkeerde for/id of verkeerd geïmplementeerde proximity association).

Contextuele linkteksten: WCAG staat links toe waarvan de tekst ("meer lezen") logisch is in context dankzij de omringende tekst (criterium 2.4.4 — In Context). Axe kan niet evalueren of die context voldoende is. Alleen een mens kan dat beoordelen.

Leesstroom in schermlezer: de leesvolgorde van een schermlezer volgt de DOM, niet de visuele presentatie. CSS Grid- of Flexbox-layouts die elementen visueel herordenen kunnen een onbegrijpelijke leesstroom genereren die geen automatische tool detecteert.

Ondertitels en transcripties van video: axe detecteert of er een <track>-element in een <video> staat, maar kan niet verifiëren of de ondertitels nauwkeurig, volledig of goed gesynchroniseerd zijn. Dat vereist menselijke controle.

Complexe gebaren zonder alternatief: als je interface functies heeft die door multi-touch-gebaren (pinch, swipe) worden geactiveerd zonder toetsenbord- of eenvoudig-tik-alternatief, is dat een schending van criterium 2.5.1. Desktoptools detecteren dit niet.

Verkeerd ARIA-gebruik: axe detecteert ongeldig ARIA, maar detecteert geen technisch geldige ARIA die de semantiek breekt. Een role="presentation" op een interactief element, of een aria-hidden="true" op relevante inhoud, slaagt de automatische check en zijn ernstige fouten.

Rapporteren in EAA-nalevingsformaat

Een audit die geen nuttige documentatie genereert, is een halve audit. De toezichthouder vraagt niet om een axe-test; hij vraagt om bewijs van due diligence. De GOV.UK-toegankelijkheidsgids — branchereferentie hoewel van Brits bereik — documenteert de de-facto-standaard voor toegankelijkheidsverklaringen die meerdere Europese toezichthouders als referentie hebben overgenomen.

Structuur van het rapport dat de overheid verwacht

Een toegankelijkheidsauditrapport dat je aan de toezichthouder kunt voorleggen (of dat als basis dient voor je verklaring) moet bevatten:

1. Bereik: welke pagina's zijn geauditeerd, waarom zijn die gekozen, en welke hulptechnologieën zijn gebruikt voor de handmatige controle.
2. Methodologie: geautomatiseerde tools (exacte versies), handmatig controleproces (schermlezers, browserversies).
3. Beoordeeld standaard: WCAG 2.2 niveau AA / EN 301 549.
4. Bevindingen: lijst van niet-nageleefd criteria, met bewijs (screenshots, HTML-fragmenten), geclassificeerd naar ernst.
5. Nalevingsstatus: volledige, gedeeltelijke of niet-conforme naleving — met motivering.
6. Gedocumenteerde uitzonderingen: als er oncontroleerbare content van derden is (externe widget, ingesloten kaart), dit documenteren als tijdelijke uitzondering met oplossingsplan.
7. Auditdatum en herzieningsfrequentie.

Sjabloon voor toegankelijkheidsverklaring

De toegankelijkheidsverklaring is het publieke document dat de EAA vereist dat je op je website publiceert (gewoonlijk op een URL zoals /toegankelijkheid of in de voettekst). Minimale structuur:

Hoe tijdelijke uitzonderingen te documenteren

Als je inhoud hebt die niet voldoet maar niet onmiddellijk kan worden verholpen (chat-widget van een derde, ingesloten kaart, verouderde PDF), staat de EAA het documenteren als tijdelijke uitzondering toe, onder voorwaarden:

• Beschrijf de betrokken inhoud en het geschonden WCAG-criterium.
• Motiveer waarom het onmiddellijk oplossen een onevenredige last is.
• Geef de geplande oplossingstermijn of het beschikbare toegankelijke alternatief aan.
• Werk de verklaring bij wanneer het is opgelost.

Een gedocumenteerde uitzondering is juridische bescherming. Een niet-gedocumenteerde uitzondering is dat niet.

Naleving handhaven: integratie in CI

De eenmalige audit vertelt je waar je vandaag staat. CI-integratie vertelt je of wat je morgen publiceert breekt wat je gisteren repareerde. Zonder CI voor toegankelijkheid is herstelwerk een emmer met gaten.

axe-core in GitHub Actions / GitLab CI

Het meest basale CI-blok met axe en Playwright:

En de bijbehorende test:

Als je project React of een ander SPA-framework gebruikt, zorg er dan voor dat de test wacht tot de dynamische inhoud is gerenderd voordat axe wordt uitgevoerd — gebruik page.waitForSelector of page.waitForLoadState('networkidle').

Pa11y dashboard

Pa11y heeft een open-source webdashboard waarmee je de toegankelijkheid van een complete site in de loop van de tijd kunt bewaken en de evolutie van issues per pagina kunt zien. Bijzonder nuttig voor:

• Sites met veel dynamisch gegenereerde pagina's (blogs, e-commerce).
• Teams waarbij niet-technisch personeel de resultaten raadpleegt.
• Geplande wekelijkse of maandelijkse audits zonder handmatige tussenkomst.

Voor kleinere projecten is Pa11y CI met JSON-output en een versiebeheerd configuratiebestand in de repo doorgaans voldoende:

De parameter threshold stelt een maximaal aantal acceptabele schendingen in voordat de build faalt — nuttig wanneer je bezig bent met herstelwerk en regressies wil vermijden zonder elke PR te blokkeren.

Pull request gating

De meest effectieve manier om naleving te handhaven is het blokkeren van merges van PRs die nieuwe schendingen introduceren. De aanbevolen stroom:

1. De CI-workflow voert axe uit op de pagina's die door de PR worden beïnvloed.
2. Als er nieuwe schendingen zijn (vergeleken met de basistak), faalt de check.
3. De PR kan niet worden gemerged totdat de nieuwe schendingen zijn opgelost of de uitzondering is gedocumenteerd.

De sleutel is alleen de betrokken pagina's te auditeren — het hele site bij elke PR auditeren is te traag. Een praktische strategie: in kaart brengen welke componenten elke PR beïnvloedt en de pagina's auditeren die die componenten gebruiken.

Dit model van QA-automatisering geïntegreerd in de ontwikkelingscyclus is hetzelfde dat we toepassen op andere kwaliteitstypen: prestaties, beveiliging, testdekking.

Te bewaken statistieken

De statistieken die er echt toe doen voor het bijhouden van toegankelijkheid in de tijd:

Veelgemaakte fouten bij herstelwerk

De audit is de helft van het werk. Bij het herstelwerk maken de meeste teams fouten die nieuwe problemen creëren of een vals gevoel van naleving geven.

Fout 1: alleen repareren wat axe detecteert

Als je alleen de automatische issues herstelt, dek je 30-40% van het probleem en laat je 60-70% onbehandeld. De toezichthouder accepteert "we slagen axe zonder fouten" niet als bewijs van WCAG-naleving. Slaag de automatische check ÉN de handmatige controle.

Fout 2: automatische alt-tekst met AI zonder review

Verschillende toegankelijkheidstools en CMS-systemen bieden automatische alt-tekstgeneratie met AI. Het resultaat kan technisch aanwezig zijn (wat axe tevreden stelt) maar semantisch nutteloos of onjuist. Een door AI gegenereerde alt die "een persoon die een laptop gebruikt in een kantoor" beschrijft terwijl de afbeelding een technisch architectuurdiagram toont, slaagt de automatische check en faalt het echte criterium. Controleer gegenereerde alts altijd.

Fout 3: onnodige ARIA-rollen die de boom breken

Het meest voorkomende antipatroon bij pogingen om toegankelijkheid te "verbeteren": ARIA-rollen toevoegen aan elementen die al correcte native semantiek hebben. <button role="button"> is redundant. <nav role="navigation"> is redundant. Maar <div role="button"> in plaats van <button> breekt de toegankelijkheidsboom omdat de div niet het toetsenbordgedrag van de native knop heeft. De algemene regel: gebruik native semantisch HTML voordat je ARIA toevoegt. ARIA is voor gevallen die HTML niet dekt, niet om bestaand HTML te versieren.

Fout 4: markup wijzigen zonder opnieuw te testen met NVDA

Elke HTML-wijziging die structuur, rollen, landmarks of de elementvolgorde beïnvloedt, kan de schermlezerervaring op niet-voor-de-hand-liggende manieren veranderen. Een wijziging die de axe-score verbetert, kan de echte navigatie verslechteren. Test opnieuw met NVDA of VoiceOver elke keer dat je de semantische structuur van een pagina wijzigt, niet alleen bij wijzigingen die specifiek voor toegankelijkheid zijn.

Fout 5: repareren zonder het criterium te begrijpen

"Voeg aria-label toe aan knoppen" is een instructie die letterlijk kan worden geïnterpreteerd en te ruim kan worden toegepast. Als een knop al beschrijvende zichtbare tekst heeft, kan het toevoegen van aria-label dit tegenspreken en de schermlezer in de war brengen (criterium 2.5.3 — Label in Name — vereist dat de aria-label de zichtbare tekst bevat). Lees het WCAG-criterium dat de wijziging rechtvaardigt in de officiële W3C-spec voordat je een correctie toepast.

Veelgestelde vragen

Is WCAG AA voldoende of heb ik AAA nodig?

De EAA vereist WCAG 2.2 niveau AA. Niveau AAA is wettelijk niet verplicht. Dat gezegd hebbende, zijn sommige AAA-criteria eenvoudig te implementeren en bieden ze aanzienlijke verbeteringen voor bepaalde gebruikersgroepen (zoals criterium 2.4.12 — Focus Appearance — dat een grotere focuszichtbaarheid vereist). Als je AA bereikt zonder extra moeite, controleer dan of een specifiek AAA-criterium relevant is voor jouw doelgroep. Maar maak van AAA geen doelstelling voor regelgevende naleving — dat is het niet.

Wat als ik een widget van een derde partij heb die niet voldoet?

Dit is een van de meest voorkomende en oncomfortabelste situaties. Als de widget in een kritieke stroom staat (supportchat, betaalgateway, registratieformulier), heb je drie opties: vervangen door een toegankelijke, een toegankelijk equivalent alternatief bieden, of documenteren als tijdelijke uitzondering met een oplossingstermijn. Je kunt het niet negeren — de wet houdt jou verantwoordelijk voor de complete ervaring die je de gebruiker biedt, inclusief componenten die je niet direct beheert. Als de leverancier van de widget geen toegankelijkheidsroadmap heeft, is dat een selectiecriterium voor leveranciers.

Hoeveel kost een professionele toegankelijkheidsaudit?

Een onafhankelijke professionele audit — die een formeel rapport genereert met juridische waarde voor de toezichthouder — kost doorgaans tussen €3.000 en €15.000 voor een website van gemiddelde omvang, afhankelijk van het aantal pagina's, de complexiteit van de interacties en of het testen met echte gebruikers met beperkingen omvat.

De 2-uurs audit die dit artikel beschrijft is niet gelijkwaardig aan een professionele audit. Het is een diagnose op hoog niveau waarmee je kunt weten waar je staat en prioriteiten kunt stellen. Het dient als basis voor interne herstelwerkzaamheden. Als je het formele rapport nodig hebt om aan de toezichthouder voor te leggen of voor een juridisch proces, heb je een professionele audit nodig. Bij Kiwop doen we formele toegankelijkheidsaudits — als je op dat punt bent, praten we.

Moet de audit worden herhaald?

Ja, en op twee niveaus. Het automatische niveau (axe in CI) moet worden uitgevoerd bij elke PR die UI-componenten wijzigt. Het volledige niveau (automatisering + handmatige controle met schermlezers + stroombeoordeling) moet minstens eenmaal per jaar worden herhaald en altijd wanneer er significante ontwerpwijzigingen, nieuwe hoofdfunctionaliteiten of een wijziging van de rendering-technologie zijn.

Toegankelijkheid is geen toestand die wordt bereikt en zichzelf handhaaft. Het is een doorlopend proces — precies zoals prestaties of beveiliging.

Moeten mijn PDF's of documenten ook voldoen?

Ja. De EAA geldt niet alleen voor HTML. Downloadbare documenten (PDF, Word, Excel) die deel uitmaken van een digitale dienst moeten ook toegankelijk zijn als ze relevante informatie voor de gebruiker bevatten. Toegankelijke PDF's vereisen kopenstructuur, correcte leesvolgorde, alt-tekst bij afbeeldingen en echte tekst (geen gescande afbeelding). Tools: PAC 2024 (PDF Accessibility Checker, gratis) en de ingebouwde toegankelijkheidscontrole in Adobe Acrobat. Als je site documentatie, contracten, facturen of formulieren als PDF aanbiedt, neem ze dan op in de audit.

Conclusie: naleving is een proces, geen evenement

Als er één les is die alles hierboven samenvat, is het deze: toegankelijkheid wordt onderhouden net als software — met geautomatiseerde tests die regressies detecteren, periodieke controles die valideren wat automatisering niet ziet, en documentatie die due diligence aantoont.

De deadline van de EAA is verstreken. Je kunt dat niet terugdraaien. Wat je wel kunt doen is vandaag beginnen, met de stack die je hebt, in 2 uur, en vandaaruit bouwen. Een onvolmaakte audit die vandaag wordt uitgevoerd is oneindig waardevoller dan een perfecte audit die nooit wordt uitgevoerd.

Het pad is: diagnose (dit artikel) → geprioriteerd herstelwerk → CI-integratie → formele audit als je juridische blootstelling dat vereist.

Als je op een punt in dat pad externe ondersteuning nodig hebt — een formele audit, complex herstelwerk, of het integreren van toegankelijkheid in het Softwareontwikkelingsproces van je team vanaf het begin — doen we bij Kiwop precies dat. Vertel ons waar je staat en we vertellen je waar je moet beginnen.