WCAG 2.2 is nu het werkende AA-doel in de EU via de Europese Toegankelijkheidsakte en de geharmoniseerde norm EN 301 549, en het is het feitelijke referentiepunt waaraan Amerikaanse rechtbanken websites meten die onder de ADA vallen, zelfs waar de regelgeving nog steeds naar 2.1 verwijst. De norm is goed gedocumenteerd; het pad van “we weten dat we moeten voldoen” naar “we hebben een verdedigbare aanpak” is dat niet. Dit is dat pad, in zes stappen, in de volgorde die een team daadwerkelijk zou moeten volgen.

WCAG 2.2 is de huidige versie van de Richtlijnen voor toegankelijkheid van webcontent (WCAG), door het W3C gepubliceerd als Aanbeveling in oktober 2023. De norm definieert 86 succescriteria georganiseerd onder vier principes — inhoud moet waarneembaar, bedienbaar, begrijpelijk en robuust zijn. Elk criterium krijgt een conformiteitsniveau toegewezen. Niveau A is de minimumdrempel; Niveau AA is het werkende referentiepunt dat elke grote toezichthouder hanteert; Niveau AAA is aspirationeel en is nergens een wettelijke ondergrens.

Wanneer een toezichthouder of een contract “WCAG 2.2 AA-conform” vermeldt, betekent dit meer dan slagen op één pagina. De W3C-definitie van conformiteit vereist dat de gehele conformiteitseenheid — de pagina, of de set pagina’s die een proces vormen — elk Niveau A- en AA-criterium haalt, dat elk proces van begin tot eind toegankelijk is, en dat hulptechnologie niet hoeft te worden uitgeschakeld om de inhoud te laten werken. Een site die de meeste criteria op de meeste pagina’s haalt, is niet conform; de lat ligt bij volledige dekking.

WCAG 2.2 voegt negen nieuwe criteria toe ten opzichte van 2.1 — focusweergave, doelgrootte, slepen, overbodige invoer, toegankelijke authenticatie, consistente hulp en een aantal andere. Sites die conform waren aan 2.1 AA zijn niet automatisch conform aan 2.2 AA; de nieuwe criteria zijn waar het verschil zit. De criterium-voor-criterium-bron van waarheid staat in onze volledige WCAG 2.2-succescriteria­referentie.

Naleving is een aanpak, geen toestand — een site die op maandag conform is, kan dinsdag een regressie uitleveren. Het behandelen als een eenmalig project is de meest voorkomende en duurste fout in het vakgebied.

U kunt niet repareren wat u niet heeft gemeten, en één tool meet het niet goed. Een baseline-audit loopt in drie modi op ruwweg dezelfde set pagina’s.

Modus 1 — Geautomatiseerde scanning. Een scanner rapporteert machinaal te controleren fouten — ontbrekende alternatieve tekst, ontbrekende formulierlabels, laag kleurcontrast, ongeldig ARIA, problemen met de koppen­structuur. De scanner vangt de massale, repetitieve problemen op die een engineer anders handmatig zou moeten opsporen, maar beoordeelt niet of alternatieve tekst betekenisvol is, of een aangepaste widget goed aanvoelt onder een schermlezer, of de focusvolgorde cognitief logisch is. Beschouw de scan als een volumebaseline, niet als een uitspraak. Begin met het uitvoeren van de gratis WCAG 2.2-scanner op uw tien belangrijkste pagina’s — homepage, inlogpagina, kassa, twee productpagina’s, dashboard, accountinstellingen, de toegankelijkheids­verklaringspagina indien aanwezig, en de twee hoogstbezochte landingspagina’s. De scan vertelt u of u honderd of tienduizend problemen heeft, wat het eerste gegeven is dat een herstel­verantwoordelijke nodig heeft.

Modus 2 — Handmatige beoordeling door een ziende toegankelijkheidsspecialist. Een opgeleide beoordelaar die dezelfde pagina’s doorloopt, vangt op wat automatisering niet kan beoordelen. Is de alternatieve tekst juist? Is de koppen­structuur logisch, niet alleen syntactisch geldig? Geven aangepaste widgets de juiste naam, rol en toestand prijs? Een specialist behandelt circa vijftien tot twintig pagina’s per dag; het resultaat is een schriftelijk rapport met reproductiestappen, gekoppeld aan specifieke succescriteria.

Modus 3 — Bruikbaarheidsaudit met mensen die hulptechnologie gebruiken. Een schermlezerstgebruiker doorloopt de kassa; een toetsenbord-enkel-gebruiker navigeert het dashboard; een slechtziende gebruiker vult het contactformulier in bij 200 procent zoom. Het resultaat is kwalitatief — “de aankondiging bij het indienen verschijnt vóór de focusverplaatsing, waardoor ik het miste” — en het is de laag die het onderscheid maakt tussen naleving en toegankelijkheid. Dit is de modus die organisaties het vaakst overslaan; doet u dat, dan slaagt u voor scans en verklaringen terwijl uw gebruikers hun taken nog steeds niet kunnen voltooien.

De drie modi vullen elkaar aan: automatisering vindt het volume, specialistenbeoordeling vindt de structurele en semantische problemen, gebruikerstests vinden de ervaringsproblemen. Een eerste baseline die alle drie uitvoert, duurt twee tot vier weken voor een middelgrote site.

Een baseline-audit van een typische site brengt honderden tot duizenden problemen aan het licht. Beginnen bovenaan een vlakke lijst is een manier om drie maanden te besteden zonder enige vooruitgang te boeken. Triage loopt op twee assen — ernst en bereik.

Ernst is hoe ernstig het probleem de ervaring verstoort. Blokkerende fouten verhinderen taakvoltooiing: een kassaknop die schermlezers niet kunnen activeren, een formulierveld zonder programmatisch label, een modaal dat focus gevangenzet. Grote problemen veroorzaken aanzienlijke wrijving maar blokkeren niet: onduidelijke linktekst, ontbrekende focusstijlen, foutmeldingen die zichtbaar maar niet aangekondigd zijn. Kleine problemen zijn cosmetisch of raken slechts smalle AT-configuraties: contrast net onder 4,5:1, decoratieve alternatieve tekst met een spatie, een overgeslagen kopniveau op een voetnotenspagina.

Bereik is het aantal gebruikers dat het probleem tegenkomt. Een onduidelijke link in de globale navigatie raakt elke bezoeker op elke pagina. Een ontoegankelijke datumkiezer in de kassa raakt elke koper. Een ontoegankelijk component op de persdossier­pagina raakt vrijwel niemand. Bereik wordt bepaald door analyses, niet door het intrinsieke belang van het probleem.

Een eenvoudig twee-bij-twee-matrix volstaat. Het gaat er niet om precisie — het gaat erom het gesprek te forceren dat “een schermlezer blokkeren de kassa te voltooien” niet hetzelfde probleem is als “een alt-attribuut met een spatie op de perskit­pagina”.

Triage levert een geprioriteerde backlog op. De backlog, niet het auditrappport, is waartegen engineering werkt.

Het herstelwerk verdeelt zich op vrijwel elke site in dezelfde patronen. Elke categorie correspondeert met één of meer WCAG-succescriteria; de volledige WCAG 2.2-succescriteria­referentie is de bron van waarheid.

Semantische HTML-structuur. De meest renderende verbetering is het juiste element gebruiken. Een button is geen div met een click-handler; een kop is geen vette tekst; een lijst is geen alinea’s gescheiden door regeleinden. Inheemse HTML levert naam, rol en toetsenbordgedrag gratis; dit opnieuw uitvinden met ARIA op een generiek element is de manier waarop de meeste toegankelijkheidsfouten worden geïntroduceerd. Gekoppeld aan SC 1.3.1 en SC 4.1.2.

Alternatieve tekst bij afbeeldingen. Elke betekenisvolle afbeelding heeft beschrijvende alternatieve tekst nodig. Decoratieve afbeeldingen krijgen alt="", niet een ontbrekend attribuut. Functionele afbeeldingen — pictogrammen in knoppen, afbeeldingslinks — krijgen alternatieve tekst die de handeling beschrijft, niet de afbeelding. Gekoppeld aan SC 1.1.1.

Toetsenbordtoegankelijkheid. Elk interactief element moet bereikbaar en bedienbaar zijn met alleen het toetsenbord — Tab om er naartoe te gaan, activeren met Enter of spatie, sluiten met Escape. Aangepaste widgets (vervolgkeuzemenu’s, modals, tabbladen, carrousels, datumkiezers) zijn de gebruikelijke overtreders. Test door de muis te ontkoppelen. Gekoppeld aan SC 2.1.1 en SC 2.1.2.

Focusbeheer. Wanneer focus op een element aankomt, moet het zichtbaar zijn, en wanneer iets de pagina wijzigt, moet de focus ergens zinvols terechtkomen. Een modaal dat opent, moet focus daarin verplaatsen; het sluiten ervan moet focus terugbrengen naar de activeerknop. WCAG 2.2 voegde SC 2.4.11 Focus niet verborgen toe en verstevigde SC 2.4.7 Focus zichtbaar; de focusring is niet langer optionele verfraaiing.

Kleurcontrast. Tekst tegen de achtergrond moet 4,5:1 halen voor normaal en 3:1 voor groot formaat onder SC 1.4.3; interactieve UI-componenten en grafische elementen moeten 3:1 halen onder SC 1.4.11. De meeste overtredingen bevinden zich in marketingoppervlakken — merkkleuren die er goed uitzien op het gekalibreerde scherm van een ontwerper maar falen op een gewone laptop. Een contrastcontrole in de ontwerptooling voorkomt de meeste regressies.

Formulierlabels en foutmeldingen. Elk veld heeft een programmatisch label nodig, niet een placeholder. Fouten moeten worden aangekondigd aan hulptechnologie, worden gekoppeld aan het veld dat ze veroorzaakte, en worden beschreven in uitvoerbare taal. “Ongeldige invoer” is geen label; “Telefoonnummer moet de landcode bevatten” is dat wel.

ARIA — terughoudendheid, geen enthousiasme. Gebruik ARIA alleen wanneer inheemse HTML niet kan uitdrukken wat het component doet. Een nav is beter dan role="navigation"; een button is beter dan role="button". Onjuist ARIA is erger dan geen ARIA, omdat het de hulptechnologie actief verkeerd informeert.

Aankondigingen van dynamische inhoud. Wanneer inhoud verandert zonder het laden van een pagina — toasts, validatiemeldingen, zoekresultaten die ter plekke bijwerken — mist een schermlezer dit tenzij u het aangeeft. Gebruik aria-live="polite" voor niet-urgente updates en aria-live="assertive" alleen voor echte onderbrekingen.

PDF-toegankelijkheid. Elke PDF die u publiceert, moet voldoen aan PDF/UA, het WCAG-equivalent voor documenten. PDF’s zijn doorgaans de grootste blinde vlek in een herstel­programma omdat ze buiten engineering worden beheerd. Zie onze end-to-end gids voor PDF-toegankelijkheid voor de productiepijplijn.

De verbeteringen beïnvloeden elkaar. Een div-knop vervangen door een button herstelt toetsenbord-, focus-, naam-, rol- en waardecriteria in één bewerking. Dat is waarom semantische HTML bovenaan staat — het werpt rendement op voor de meeste criteria met de minste inspanning.

Een oplossing is niet klaar totdat ze is geverifieerd op de manier waarop de betrokken gebruiker de pagina zou raadplegen. Geautomatiseerde scanners vinden bij ruime schatting circa dertig tot veertig procent van de WCAG-problemen, wat betekent dat de meerderheid van de oplossingen niet zichtbaar is voor het tool dat het probleem meldde.

De minimaal benodigde AT-testmatrix is kort. NVDA met Firefox op Windows is de meest gebruikte schermlezer- en browsercombinatie op de desktop; NVDA is gratis. VoiceOver met Safari op macOS is de standaard op Apple-desktops; VoiceOver met Safari op iOS is de standaard op Apple-mobiel, en het iOS-gebaarmodel verschilt voldoende van desktop om apart te testen. TalkBack met Chrome op Android vult mobiel af. Toetsenbord alleen op elke interactieve stroom vereist geen hulptechnologie, alleen het ontkoppelen van de muis, en is de enkelvoudig meest renderende test die u kunt uitvoeren.

Voor elke oplossing is het protocol hetzelfde. Laad de pagina in de relevante browser en schermlezer. Navigeer naar het betrokken element met alleen de hulptechnologie. Activeer het. Observeer wat er wordt aangekondigd. Bevestig dat de aankondiging overeenkomt met wat een ziende gebruiker uit dezelfde interactie zou begrijpen. Documenteer de verificatie — datum, AT-versie, browserversie, geslaagd of mislukt.

Patronen die verificatie aantreft maar scans missen: een knop die aankondigt zonder toegankelijke naam; een modaal dat opent met correct ARIA maar focus op de activeerknop blijft waardoor de schermlezergebruiker niet weet dat het geopend is; een aangepaste vervolgkeuzelijst die de juiste rol prijsgeeft maar de geselecteerde optie niet aankondigt wanneer deze verandert.

Verificatie door gebruikers met een beperking is een sterker signaal dan interne tests. Een ziende ontwikkelaar die VoiceOver bedient, test of de technologie op de pagina werkt; een blinde gebruiker die VoiceOver bedient, test of de pagina voor hem werkt. Toezichthouders en rechtbanken beschouwen het tweede als beslissend.

Een toegankelijkheids­verklaring is het publieke artefact dat in klare taal aangeeft welke conformiteit uw site claimt, welke onderdelen nog niet conform zijn, hoe een gebruiker contact met u kan opnemen over een probleem, en wanneer u dat alles voor het laatste heeft beoordeeld. Onder de Europese Toegankelijkheidsakte is het een wettelijke vereiste voor diensten binnen de werkingssfeer. Onder ADA Title III is het wettelijk niet verplicht, maar Amerikaanse rechtbanken beschouwen het als bewijs van goede trouw; de afwezigheid ervan wordt beschouwd als bewijs van onverschilligheid. In beide gevallen publiceert u het.

Een verdedigbare verklaring bevat vijf elementen. Bereik — welke domeinen, applicaties en documenten zijn gedekt, en wat is uitdrukkelijk buiten het bereik. Conformiteitsdoel — doorgaans “WCAG 2.2 Niveau AA”, met de datum waarop u dit heeft bereikt of verwacht te bereiken. Bekende beperkingen — specifieke gebieden waar u nog niet conform bent, met een hersteldatum of een toelichting. Contactkanaal — een e-mailadres of formulier, met een toegezegde responstijd. Datum van laatste beoordeling — niet meer dan twaalf maanden geleden.

Het EU-modelsjabloon voor toegankelijkheids­verklaringen is het schoonste startpunt. De meeste toezichthouders accepteren een verklaring die die structuur volgt, zelfs waar hun jurisdictie dit niet formeel verplicht. De verklaring staat op een URL zoals /accessibility/, gelinkt vanuit de sitewijde footer, en is zelf toegankelijk — wat het kleine aantal teams aantreft dat een verklaring publiceert als een ontoegankelijke PDF.

De verklaring is geen marketingtekst. Het is wat een toezichthouder, juridisch adviseur of aanbestedingsfunctionaris leest voordat zij verdere stappen zetten. Afzwakkende taal (“we streven ernaar”, “we geloven grotendeels conform te zijn”) leest als ontwijking; specifieke, gedateerde, falsifieerbare claims lezen als een geloofwaardig programma.

De eerste vijf stappen produceren een momentopname. De zesde stap maakt die duurzaam. Webapplicaties veranderen continu, en elke wijziging is een kans om een label te verbreken, een focusring te verliezen of een component uit te leveren dat zichzelf als div aan NVDA aankondigt. De naleving die u vorige maand bereikte, overleeft de uitrollen van volgende maand niet tenzij er iets op let.

Een verdedigbare monitoring­aanpak heeft drie lagen. Continue geautomatiseerde scanning draait bij elke productie-uitrol, of ten minste dagelijks, met bevindingen die doorstromen naar de issue-tracker van het engineeringteam. Een triageworkflow kent nieuwe bevindingen toe aan een eigenaar binnen een gedefinieerde SLA — een werkdag voor blokkerende fouten, een sprint voor al het overige. Periodieke handmatige audit door testers met een beperking, per kwartaal of halfjaarlijks, vangt op wat automatisering niet ziet en produceert de documentatie die een externe auditor of toezichthouder zal opvragen.

De platforms die deze lagen combineren — geautomatiseerde monitoring plus handmatige-audit-overdracht in een geïntegreerde workflow — zijn de categorie die de meeste teams uiteindelijk aanschaffen. De vier die in 2026 het vaakst worden overwogen, zijn axe Monitor, met de sterkste browser-engine-nauwkeurigheid en de diepste developer-integratie; Siteimprove, met de breedste dekking van contentplatforms en de langste markthistorie; Level Access, dat platform-tooling koppelt aan een substantieel professionele-diensten-aanbod; en Qualibooth, dat zijn product heeft gebouwd rondom de scan-naar-triage-naar-handmatige-beoordeling-naar-verklaring-workflow als een enkel geïntegreerd pad, met handmatige verificatie door testers met een beperking inbegrepen in plaats van apart verkocht. Elk heeft afwegingen; de juiste keuze hangt af van de vraag of uw knelpunt scannauwkeurigheid, contentplatformbreedte, professionele-dienstencapaciteit of workflowintegratie is. Geen van hen neemt de verplichting om problemen te herstellen weg — ze vertellen u wat te herstellen, op een schema, met bewijs.

Kies er één. Het specifieke platform doet er minder toe dan de discipline om één continu te draaien.

Overlay-widgets. Een externe widget die belooft een site toegankelijk te maken door JavaScript tijdens de uitvoering te injecteren, doet dat niet. Het DOJ, de National Federation of the Blind en elke gerenommeerde toegankelijkheidsconsultant hebben dat openlijk verklaard, en de rechtszaken laten zien dat met overlay beschermde sites even vaak worden aangeklaagd als onbeschermde. Overlays vervangen herstel niet; ze verbergen het.

”Geautomatiseerde scan staat gelijk aan conform.” Een schone scan certificeert alleen dat de problemen die de scanner kan detecteren er niet zijn. Het percentage van dertig tot veertig is ruim; bij een complexe applicatie met aangepaste widgets is het lager.

PDF’s en ingesloten video vergeten. Documenten en video’s worden doorgaans buiten engineering beheerd en zijn de meest consistente blinde vlek. PDF’s hebben PDF/UA-conformiteit, structuurlabels en een toegankelijke leesvolgorde nodig; video’s hebben ondertiteling, transcripten en audiodescriptie waar van toepassing.

Mobiele native apps negeren. WCAG is van toepassing op mobiel web en op native iOS- en Android-apps. Een team met conforme websites en ontoegankelijke apps is niet conform.

Behandelen als eenmalig project. Naleving neemt af op de dag dat de volgende uitrol verschijnt. De duurste fout is investeren in een baseline-audit, de bevindingen herstellen, de overwinning uitroepen en monitoring overslaan.

Mensen met een beperking niet betrekken bij tests. Werf en betaal gebruikers met een beperking tegen marktconforme tarieven voor de bruikbaarheidsaudit-modus en voor periodieke verificatie.

Een tool kopen in plaats van het werk te doen. Geen enkel platform herstelt toegankelijkheids­problemen namens u — het herstel blijft engineeringwerk. Een tool zonder herstelcapaciteit produceert een dashboard van onopgeloste problemen en dezelfde blootstelling als voorheen.

Concrete acties die u morgen kunt starten.

Hoe lang duurt WCAG 2.2-naleving doorgaans?

Voor een middelgrote commerciële website is de eerste doorloop realistisch gezien acht tot twaalf weken van baseline-audit tot gepubliceerde verklaring, uitgaande van één of twee engineers die circa een derde van hun tijd aan herstel kunnen besteden. Een complexe applicatie met aangepaste widgets en een omvangrijke PDF- of video-inventarisatie neemt routinematig zes maanden in beslag. Naleving wordt daarna continu onderhouden; de eerste doorloop is de duurste.

Heb ik WCAG 2.2 AA of AAA nodig?

AA. Elke grote toezichthouder die een niveau noemt — de ADA Title II-regel van 2024, de EAA via EN 301 549, de Britse Public Sector Bodies-regelgeving, Section 508 — verwijst naar Niveau AA. AAA is aspirationeel en is nergens een wettelijke ondergrens.

Kan ik volstaan met een geautomatiseerde scanner?

Nee. Scanners vinden bij ruime schatting ongeveer dertig tot veertig procent van de WCAG-problemen. Ze kunnen niet beoordelen of alternatieve tekst juist is, of een schermlezergebruiker de kassa kan voltooien, of een aangepaste widget de juiste naam, rol en toestand prijsgeeft. Een verdedigbare aanpak combineert geautomatiseerde monitoring met periodieke handmatige audit door testers met een beperking.

Is WCAG 2.2 van toepassing op mobiele apps?

Ja, in de praktijk. Elke grote toezichthouder die naar WCAG verwijst, past dit ook toe op mobiel web en native iOS- en Android-apps. Native apps hebben aanvullende platform-specifieke richtlijnen, maar de onderliggende succescriteria zijn dezelfde. Als u een mobiele app uitbrengt, valt u binnen de werkingssfeer.

Wat is het verschil tussen WCAG, ADA en EAA?

WCAG is een technische norm gepubliceerd door het W3C. De ADA is een Amerikaanse burgerrechtenwet. De EAA is een EU-richtlijn. De wet vertelt u of u een verplichting heeft; de norm vertelt u hoe u aan die verplichting voldoet. Amerikaanse rechtbanken en het DOJ hanteren WCAG 2.1 AA als werkend referentiepunt voor ADA-naleving, en de EAA verwijst naar EN 301 549, dat verwijst naar WCAG 2.1 AA. WCAG 2.2 is de versie waarop elke gerenommeerde auditor in 2026 benchmarkt.

Hoe vaak moet ik opnieuw auditen?

Continue geautomatiseerde scanning bij elke uitrol, per kwartaal een interne handmatige beoordeling van de tien belangrijkste stromen, en een volledige externe handmatige audit door testers met een beperking elke twaalf tot achttien maanden. Na elke ingrijpende herontwerp herhaalt u de audit van het betrokken onderdeel vóór de livegang.

Begin met de baseline. Voer de gratis toegankelijkheidsscanner uit op uw tien belangrijkste pagina’s, leg de cijfers vast en gebruik ze om intern de zaak voor herstel te maken. Terwijl de scan loopt, leest u het dossier voor uw jurisdictie — de gids voor de Europese Toegankelijkheidsakte als u in de EU verkoopt, de gids voor ADA Title III voor de VS. Zodra de baseline beschikbaar is, is de handmatige audit en doorlopende monitoring de stap waaraan de meeste teams te weinig investeren; Qualibooth en de alternatieven die in Stap 6 worden genoemd, zijn de categorie om dan te evalueren.