Eenvoud
Whitepaper · april 2026

Digitale toegankelijkheid · WCAG 2.2 AA

De EAA is niet uw
grootste probleem met toegankelijkheid.

De boete van de ACM is reëel, maar overzichtelijk. Wat minder zichtbaar is: de technische schuld die u opbouwt zolang toegankelijkheid buiten uw ontwerp- en ontwikkelproces staat.

Doelgroep IT- en businessbeslissers
Leestijd 8–10 minuten
Auteur Peter Bijsterveld · Eenvoud

Herkenbaar?

U krijgt een mail van juridische zaken: “Voldoen wij aan de EAA?” Er ligt een scan in uw inbox — 147 issues, de auditor stelt een remediation-plan voor. Uw CFO vraagt wat het kost. Uw CMO vraagt wat het oplevert. U heeft op geen van beide een scherp antwoord.

U bent niet alleen. De WebAIM Million-audit van 2025 vond op 96% van de grootste één miljoen websites automatisch detecteerbare WCAG-fouten, met gemiddeld 51 fouten per homepage. De helft van de meldingen in uw inbox gaat waarschijnlijk over dingen die voor iedereen vervelend zijn: een knop die te klein is om te raken, een foutmelding die niet uitlegt wat er mis ging, een pop-up die niet weg wil. Toegankelijkheid blijkt niet een apart hoekje voor “mensen met een beperking” — het is gewoon de vraag of uw product werkt.

Huidige situatie

Audit-en-repareer achteraf

Reactieve toegankelijkheidscyclus Live product wordt periodiek door een externe audit gecontroleerd, die vindt issues, die als tickets in een backlog komen, waarna ontwikkelaars fixes doen die terug naar live gaan. De cyclus loopt maanden en herhaalt zich. Live product (met issues) Externe audit (per jaar) Tickets (backlog) Dev-fix (sprint later)
  • Issues ontdekt nadat ze in productie staan
  • Fix-kosten 10–30× hoger dan bij de bron
  • Regressie op elke nieuwe release mogelijk
  • Kennis zit bij auditor, niet bij team

Gewenste situatie

Ingebouwd in de ontwikkelketen

Preventieve toegankelijkheidsketen Designsysteem met a11y-tokens voedt design en code. Linter en CI-pipeline blokkeren fouten voor ze in productie komen. Handmatige spot-check per sprint sluit de keten. Een enkele pijl naar een stabiel, toegankelijk product. Designsysteem (a11y-tokens) Design Code CI-check (axe, lint) Live product (stabiel)
  • Fouten gevangen voor ze in productie komen
  • Kennis zit in tokens, linters, patronen
  • Nieuwe features erven toegankelijkheid
  • Audit wordt verificatie, geen herstel-operatie
Concreet voorbeeld — een foutmelding op een loginformulier Achteraf: een screenreader-gebruiker typt een verkeerd wachtwoord, de rode tekst “ongeldig” verschijnt onder het veld maar wordt nooit aangekondigd — de gebruiker denkt dat er niets gebeurt. Drie maanden later vindt de audit het, er wordt een ticket geschreven, een developer voegt aria-live="polite" toe, regressietest, deploy. Ingebouwd: het formulier-component in het designsysteem heeft aria-live ingebakken. Elke foutmelding die ermee gebouwd wordt, is automatisch correct. De bug bestaat nooit.

Wat WCAG concreet van u vraagt

WCAG 2.2 op niveau AA is de de-facto-lat voor het web. De EAA verwijst via EN 301 549 formeel nog naar WCAG 2.1 AA, maar de ETSI-update naar 2.2 wordt begin 2026 verwacht. Wie nu 2.2 bouwt, is compliant én toekomstbestendig. Dit zijn de acht gebieden waar het in de praktijk op aankomt.

Waarneembaar — Tekstalternatieven en contrast

Elke afbeelding, icoon en grafiek heeft een zinvolle alt-tekst of wordt expliciet als decoratief gemarkeerd. Tekst heeft minimaal 4.5:1 contrastverhouding met de achtergrond (3:1 voor grote tekst). Informatie mag niet uitsluitend via kleur worden overgebracht.

UitkomstEen screenreader-gebruiker en iemand met kleurenblindheid ontvangen dezelfde boodschap als een ziende gebruiker.

Bedienbaar met toetsenbord — Alles moet zonder muis werken

Elke interactie — menu’s, modals, formulieren, drag-and-drop — is volledig te bedienen met Tab, Enter, Space en pijltjestoetsen. Focus is zichtbaar. Geen keyboard traps. Custom componenten gedragen zich zoals het ARIA-patroon voorschrijft.

UitkomstGebruikers met motorische beperkingen én power-users met alleen een toetsenbord komen overal.

Structuur en semantiek — HTML zegt wat het is

Koppen zijn koppen (niet opgemaakte divs). Lijsten zijn lijsten. Landmarks — header, main, nav, footer — zijn correct. Formuliervelden hebben expliciete labels. Tabellen gebruiken th/scope. ARIA alleen waar native HTML tekortschiet.

UitkomstOndersteunende technologie — screenreader, voice control, leesmodus — kan de pagina begrijpen zonder dat u iets hoeft uit te leggen.

Formulieren die helpen — Fouten uitleggen, niet verbergen

Verplichte velden zijn vooraf herkenbaar. Foutmeldingen staan bij het veld, beschrijven het probleem in gewone taal en suggereren een oplossing. Autocomplete-attributen zijn ingevuld. Bij betaling of verzenden is herstel mogelijk vóór definitieve actie.

UitkomstFormulieren worden eerder afgemaakt — door iedereen, niet alleen door bezoekers met een beperking.

Responsief en schaalbaar — Werkt op 320 pixels én bij 200% zoom

De interface blijft bruikbaar tot 320 CSS-pixels breed zonder horizontaal scrollen. Tekst laat zich tot 200% vergroten zonder verlies van functionaliteit. Raakdoelen zijn minimaal 24×24 pixels (nieuw in 2.2). Orientatie is niet vastgelegd tenzij strikt nodig.

UitkomstDe site werkt bij ingezoomde tekst, op een kleiner telefoonscherm, en voor iemand die met één hand bedient.

Authenticatie en sessies — Inloggen zonder geheugensport

Nieuw in WCAG 2.2: geen cognitieve tests bij inloggen — geen puzzels, geen CAPTCHA’s die alleen op herkenning leunen zonder alternatief. Wachtwoordvelden laten zich plakken vanuit een wachtwoordmanager. Sessie-timeouts waarschuwen en bieden verlenging.

UitkomstInloggen is geen drempel meer voor wie slecht ziet, dyslectisch is, of gewoon een 2FA-app gebruikt.

Dynamisch gedrag en media — Bewegen, pauzeren, voorspellen

Auto-play video heeft pauzeknop. Bewegende content langer dan 5 seconden is te stoppen. Video heeft ondertitels; audio-only heeft transcript. Focus springt niet onverwacht. Content verandert niet van betekenis wanneer een gebruiker input geeft, tenzij aangekondigd.

UitkomstMensen met vestibulaire problemen, ADHD of slechte bandbreedte worden niet overvallen door de interface.

Proces, niet project — Toegankelijkheid in de pijplijn

Automatische checks draaien in CI (axe-core, Lighthouse). Designsystemen hebben accessibility-specs in de tokens. Definition of Done bevat a11y-criteria. Elke release krijgt een handmatige spot-check op kritieke flows. Een toegankelijkheidsverklaring staat publiek en wordt bijgehouden.

UitkomstNieuwe features schieten niet per ongeluk weer in de rode cijfers — het blijft staan, release na release.

Architectuurprincipe

Toegankelijkheid is geen extra laag op een bestaand product. Het is een kwaliteitseigenschap van de codebase — net als prestatie of security.

Wat niet bij de bron wordt ingebouwd, keert altijd terug als schuld.

Wat u overhoudt als u het serieus aanpakt

Compliance is de trigger, niet de opbrengst. De werkelijke winst zit in wat een toegankelijk product óók is: een beter gestructureerd, robuuster, begrijpelijker product. Voor iedereen.

Bereik

Een groter publiek, meetbaar

Ongeveer een kwart van de Europese bevolking leeft met een beperking — visueel, auditief, motorisch of cognitief. Een toegankelijke interface betekent dat u deze groep niet al bij de voordeur verliest, plus de substantiële groep die tijdelijk in een vergelijkbare situatie zit: gebroken arm, ingezoomd scherm, luidruchtige omgeving.

Conversie

Formulieren die afmaken

Heldere labels, zinvolle foutmeldingen en autocomplete-attributen verhogen het voltooien van formulieren. Dit zijn dezelfde technieken die UX-teams gebruiken om hun funnel te optimaliseren — WCAG codificeert ze alleen als norm.

SEO

Zoekmachines houden van semantiek

Dezelfde koppenstructuur die screenreaders helpt, helpt Google. Alt-teksten, beschrijvende linktitels en duidelijke content-hiërarchie zijn zowel a11y- als SEO-basis. Twee vliegen, één slag.

Code-kwaliteit

Minder ad-hoc, meer patroon

Een codebase met serieuze a11y heeft bijna per definitie een beter designsysteem, duidelijker componentgrenzen en minder eenmalige hacks. Technische schuld daalt op plekken waar u het niet verwacht.

Aanbesteding

Deuren die anders dicht blijven

Publieke aanbestedingen en steeds meer enterprise-klanten vragen expliciet om WCAG 2.1 AA of hoger in hun RFP’s. Geen verklaring, geen deal. Zonder audit bent u niet eens in de running.

Risico

Minder juridische blootstelling

Onder de EAA kan de ACM voor e-commerce en telecommunicatiediensten boetes opleggen tot €900.000 per overtreding (Wet handhaving consumentenbescherming). Een gedocumenteerd verbeterplan en een publieke toegankelijkheidsverklaring verlagen het risicoprofiel aanzienlijk — ook bij klachten die nog niet tot een procedure hebben geleid.

Duurzaamheid

Toekomstbestendig voor WCAG 2.3 en 3.0

De POUR-principes (Perceivable, Operable, Understandable, Robust) blijven de basis in komende versies. Wie nu een gezonde a11y-praktijk opbouwt, hoeft bij de volgende standaard niet opnieuw te beginnen — alleen bij te werken.

Voor wie zijn deze getallen relevant?

Om de kosten en rendementen in de volgende sectie concreet te maken, hanteren we een fictief maar typisch profiel. Herkent u er zichzelf in? Dan kloppen de orden van grootte ongeveer. Heeft u een kleinere website? Zie in Deel 3 het blok “En kleinere websites dan?” voor een aparte indicatie.

Typische middelgrote organisatie

B2C dienstverlener · 140 medewerkers · klantgerichte webapp

Een organisatie met een publieke marketingsite van 60–120 pagina’s plus een ingelogde klantomgeving waar gebruikers transacties, contracten of dossiers beheren. De codebase is 3–7 jaar oud, deels gerefactored, met een front-end in React of Vue. Toegankelijkheid is nooit systematisch meegenomen.

~85Unieke templates / componenten
14Kritieke gebruikersflows (login tot transactie)
180kUnieke bezoekers per maand
AAWCAG-doel (2.1 verplicht, 2.2 aanbevolen)

Wat kost het, wat levert het op

Ranges voor het profiel hierboven. Bedragen exclusief btw. Eigen uren niet meegerekend, tenzij anders vermeld. Dit zijn richtgetallen uit vergelijkbare trajecten — geen offerte. Niet elke post is altijd volledig nodig: de startsituatie van uw bestaande site bepaalt vooral waar u in de bandbreedte landt.

Scope van deze uitsplitsing De kostenposten hieronder horen bij een groter traject: een publieke site plus klantgerichte webapp met meerdere kritieke flows. Voor een website-zonder-webapp is deze uitsplitsing meestal te zwaar; gebruik daarvoor het blok “En kleinere websites dan?” als realistischer referentie.

Scenario A — redelijke basis op orde

Totaal indicatie: € 35.000–70.000

Recent redesign, componentbibliotheek aanwezig, beperkt maatwerk in formulieren en navigatie. Meeste werk zit in gerichte remediation en procesinrichting.

Scenario B — gemengd beeld

Totaal indicatie: € 70.000–120.000

Combinatie van moderne en legacy-componenten, meerdere kritieke flows met bekende frictie. Extra budget gaat vooral naar component-harmonisatie en regressietesten.

Scenario C — duidelijke achterstand

Totaal indicatie: € 120.000–180.000

Verouderde codebase, veel unieke templates, weinig herbruikbare patronen. Audit-uitkomsten raken zowel UX, front-end als content op grote schaal.

Belangrijkste prijsdrivers
  • De technische staat van componenten: hoeveel basispatronen al toegankelijk zijn.
  • Het volume en type content: vooral formulieren, tabellen, documenten en media.
  • Het aantal kritieke gebruikersflows dat onderbroken raakt bij regressie.

En kleinere websites dan?

Indicatie: € 8.000–30.000 eenmalig

Voor een compacte website (bijvoorbeeld 10–30 pagina’s, beperkt aantal interactieve formulieren, geen complexe ingelogde omgeving) ligt de investering meestal duidelijk lager dan in het referentieprofiel hierboven.

  • Onderkant range: moderne theme- of componentbasis, beperkte content-opschoning, weinig maatwerk.
  • Bovenkant range: veel PDF’s, custom widgets, zware formulieren of technische achterstand in templates.
  • Doorlopend: reken daarna grofweg op € 1.500–5.000 per jaar voor periodieke controles en kleine correcties.

Kosten — eenmalig (groot site + webapp-traject)

  • Externe audit WCAG 2.2 AA (site + webapp)Automatische scan plus handmatige audit op alle kritieke flows€ 8.000–18.000
  • Remediation development (100–250 issues)Oplossen van geïdentificeerde issues in sprints€ 25.000–75.000
  • Designsysteem-update met a11y-tokensKleuren, focus states, componentpatronen compliant maken€ 12.000–30.000
  • Content-review en alt-teksten (60–120 pagina’s)Alt-teksten, formulierteksten en foutmeldingen€ 4.000–10.000
  • Toegankelijkheidsverklaring en processenPublieke verklaring, klachtenprocedure, ACM-rapportage€ 3.000–6.000
  • Training design- en ontwikkelteam (2 dagen)Kennis verankeren in het staande team€ 4.000–8.000

Kosten — doorlopend per jaar

  • Automatische scans in CI (tooling + onderhoud)axe-core, Lighthouse in de pipeline€ 2.000–5.000
  • Handmatige regressietest per kwartaalScreenreader-test op kritieke flows€ 6.000–12.000
  • Herziening verklaring + klachtafhandelingJaarlijkse update en monitoring€ 2.000–4.000
  • A11y-review op nieuwe features (opslag)Inbegrepen in feature-ontwikkeling10–15% op feature-kosten

Rendement — kwantitatief

  • Minder support-tickets over navigatie en foutenDoor betere structuur en foutafhandeling−15–30%
  • Tijd bespaard per release (minder a11y-regressie)Automatische checks vangen regressie vroegorde van dagen
  • Afgewezen aanbestedingen wegens a11y-eisMet verklaring en audit-rapport kwalificeert u→ 0
  • Conversie-uplift op verbeterde formulierenBetere labels, foutmeldingen, autocompletemeetbaar, context-afhankelijk

Rendement — kwalitatief

  • Risico op ACM-boete of klachtGedocumenteerd verbeterplan verlaagt blootstellingsubstantieel lager
  • Codebase-kwaliteit en onderhoudbaarheidBetere structuur, minder hacks, duidelijker patronenaantoonbaar beter
  • Positie in aanbestedingen met a11y-eisVan niet-kwalificeerbaar naar compliantvan nul naar kwalificeerbaar
Let op — wanneer dit níét de juiste keuze is. Een organisatie die binnen 6 maanden een volledige replatforming plant, kan remediation beter overslaan en direct accessibility-first bouwen op het nieuwe platform. Een pure B2B-applicatie met gecontroleerde gebruikersgroep (bijvoorbeeld interne tools voor 40 medewerkers zonder beperkingen en zonder aanbestedingsverplichting) kan volstaan met de belangrijkste basis, zonder volledige audit en certificering. Geld besteden aan WCAG 2.2 AAA is in bijna alle gevallen niet zinvol — AA is de norm waar wetgeving, aanbestedingen en gebruikers om vragen.
Relatieve kosten van één toegankelijkheidsfix, per projectfase Staafdiagram met vier balken. In de ontwerpfase kost een fix 1×. In development 3 tot 5×. Pre-launch 10×. Na live-gang 30 tot 100× zoveel. Relatieve kosten van één toegankelijkheidsfix, per fase Ontwerp Development 3–5× Pre-launch 10× Na live-gang 30–100× € per fix
Indicatief. Toegankelijkheidsissues volgen dezelfde kostencurve als security- en bugfixes: hoe later in het traject, hoe duurder. Dit is waarom de doorlopende kosten in de tabel hierboven zo bescheiden zijn — mits u aan de bron begint.

Hoe we het doen

Een traject dat compliance én kwaliteit oplevert bestaat uit vier fases. Overlap en iteratie zijn normaal — dit is geen waterval.

Fase 01

Audit & nulmeting

2–4 weken

Automatische scan plus handmatige audit op WCAG 2.2 AA. Activiteiten
  • Screenreader-test op 8–12 kritieke flows
  • Prioritering van issues naar impact, frequentie en reparatiekosten
Oplevering
  • Rapport met alle bevindingen
  • Remediation-roadmap

Fase 02

Designsysteem & fundament

3–6 weken

Kleuren, spacing, focus states en componentpatronen worden accessibility-compliant gemaakt. Activiteiten
  • Tokens in het designsysteem
  • Linter- en CI-configuratie
  • Training van designers en ontwikkelaars zodat het werk in de sprints landt
Oplevering
  • Compliant designsysteem met a11y-tokens
  • CI-pipeline met automatische checks

Fase 03

Remediation in sprints

8–14 weken

Issues worden in sprints opgelost, geordend naar impact. Activiteiten
  • Handmatige verificatie na elke sprint
  • Regressiewaarborg via automatische tests
  • Content-team werkt parallel aan alt-teksten en formulierteksten
Oplevering
  • Volledig geremedieerde codebase
  • Alle content WCAG-compliant

Fase 04

Verklaring & borging

2–3 weken

Publieke toegankelijkheidsverklaring, klachtenprocedure, non-conformity rapportage (ACM). Activiteiten
  • Definition of Done wordt uitgebreid met a11y-criteria
  • Kwartaalproces voor hercontrole en review
Oplevering
  • Publieke toegankelijkheidsverklaring
  • Overdracht aan het staande team

Kennismaken

Eén gesprek, geen verkooppitch. We kijken samen waar u staat.

Een korte video-call. We lopen uw site of webapp door met een aantal scans en bespreken welke EAA-risico’s reëel zijn, welke niet, en wat een zinvolle eerste stap zou zijn. Geen offerte op voorhand — een gesprek waar u na afloop iets aan heeft, ongeacht of u met ons verder gaat.

Peter Bijsterveld

Technical Director · Eenvoud · peter@eenvoud.nl

Volgende stap

Eén gesprek, geen verkooppitch

We bekijken samen of dit past bij waar uw organisatie nu staat. Geen sales-deck, wel een open gesprek over wat werkt en wat niet.