Het W3C publiceerde WCAG 2.2 in oktober 2023 als een evolutionaire update van versie 2.1. Deze nieuwe versie bouwt voort op de bestaande basis en introduceert 9 nieuwe succescriteria terwijl één verouderd criterium wordt verwijderd. Voor organisaties die werken aan digitale toegankelijkheid is het cruciaal om deze wijzigingen te begrijpen en te implementeren.
Snel overzicht van wijzigingen tussen WCAG 2.1 en 2.2
WCAG 2.2 voegt in totaal 9 nieuwe succescriteria toe aan de bestaande 78 criteria uit versie 2.1. De verdeling over conformiteitsniveaus is als volgt: 2 nieuwe criteria op niveau A (het meest basaal), 4 op niveau AA (de gebruikelijke standaard voor wetgeving), en 3 op niveau AAA (de hoogste lat). Daarnaast is criterium 4.1.1 Parsing volledig verwijderd omdat moderne browsers parsing-fouten automatisch corrigeren. De nieuwe criteria richten zich vooral op cognitieve toegankelijkheid, touch-interacties op mobiele apparaten en verbeterde focus-indicatoren voor toetsenbordgebruikers.
Nieuwe succescriteria in WCAG 2.2
De 9 nieuwe succescriteria in WCAG 2.2 pakken specifieke toegankelijkheidsproblemen aan die in eerdere versies onderbelicht bleven. Ze komen voort uit uitgebreid gebruikersonderzoek en feedback van mensen met diverse beperkingen, waaronder cognitieve stoornissen, visuele beperkingen en motorische uitdagingen. Hieronder worden alle nieuwe criteria in detail besproken met praktische voorbeelden.
2.4.11 Focus niet verborgen (Minimum) - Niveau AA
Dit criterium zorgt ervoor dat gefocuste elementen niet volledig verborgen worden door andere content, zoals sticky headers of cookie-banners. Wanneer een gebruiker met het toetsenbord door een pagina navigeert, moet het gefocuste element minimaal gedeeltelijk zichtbaar blijven. Een veelvoorkomend probleem: een sticky header aan de bovenkant bedekt links die focus krijgen tijdens Tab-navigatie. De oplossing is om scroll-gedrag aan te passen zodat gefocuste elementen altijd gedeeltelijk zichtbaar zijn, bijvoorbeeld door 'scroll-padding-top' te gebruiken in CSS om ruimte te reserveren voor vaste headers.
2.4.12 Focus niet verborgen (Uitgebreid) - Niveau AAA
De uitgebreide versie van criterium 2.4.11 vereist dat gefocuste elementen volledig zichtbaar zijn, niet slechts gedeeltelijk. Dit hogere niveau van toegankelijkheid garandeert dat gebruikers met verminderd gezichtsveld of cognitieve beperkingen altijd het complete gefocuste element kunnen zien zonder te moeten scrollen of content te moeten verplaatsen. In de praktijk betekent dit dat sticky elements (zoals floating action buttons, chat widgets of persistente navigatie) zo gepositioneerd moeten worden dat ze nooit een volledig gefocust element bedekken, of dat ze tijdelijk moeten verdwijnen wanneer focus zich onder het element bevindt.
2.4.13 Focusweergave - Niveau AAA
Dit criterium stelt expliciete eisen aan de zichtbaarheid van de focus-indicator. De indicator moet minimaal een grootte hebben die overeenkomt met een 2 CSS pixels dikke omlijning rond het gefocuste element, of een solide vorm met een oppervlakte van minimaal 4 CSS pixels. Daarnaast moet het contrast tussen de gefocuste en niet-gefocuste staat minimaal 3:1 zijn. Een praktisch voorbeeld: de standaard blauwe outline van browsers voldoet meestal wel, maar custom focus-stijlen met dunne of lage-contrast borders voldoen vaak niet. Een goede implementatie gebruikt een duidelijke, dikke border (bijvoorbeeld 3px solid) in een contrasterende kleur, eventueel gecombineerd met een box-shadow voor extra zichtbaarheid.
2.5.7 Sleepbewegingen - Niveau AA
Functies die geactiveerd worden door sleepbewegingen (drag & drop) moeten ook beschikbaar zijn via een alternatieve methode met één aanwijzer zonder te slepen. Veel gebruikers met motorische beperkingen kunnen geen sleep-acties uitvoeren, en dit criterium garandeert dat zij dezelfde functionaliteit kunnen gebruiken. Een klassiek voorbeeld is een kanban-bord waar items tussen kolommen kunnen worden gesleept. De toegankelijke implementatie biedt daarnaast knoppen aan om items te verplaatsen, of een contextmenu met 'Verplaats naar...' opties. Een ander voorbeeld: een slider die met slepen bediend kan worden, moet ook via knoppen of directe numerieke invoer aanpasbaar zijn.
2.5.8 Doelgrootte (Minimum) - Niveau AA
Aanwijsdoelen (zoals knoppen, links en form controls) moeten een minimale grootte hebben van 24 bij 24 CSS pixels. Dit criterium helpt gebruikers met motorische beperkingen en mensen die touchscreens gebruiken, omdat grotere doelen makkelijker te raken zijn. Er zijn enkele uitzonderingen: inline links in tekstblokken hoeven niet aan deze eis te voldoen, doelen die standaard door de browser worden weergegeven (zoals checkboxes) zijn vrijgesteld, en essentiële elementen waarbij de grootte niet gewijzigd kan worden zonder de informatie of functionaliteit te veranderen. Een praktische implementatie: verhoog de padding van knoppen zodat de klikbare/tappable area minimaal 24x24px is, ook als het visuele icoon of de tekst kleiner is. Gebruik CSS om 'min-width: 24px' en 'min-height: 24px' in te stellen voor interactieve elementen.
3.2.6 Consistente hulp - Niveau A
Als een website hulpmechanismen aanbiedt (zoals contactformulieren, telefoonnummers, chatfuncties of self-service opties), moeten deze op elke pagina op dezelfde relatieve positie verschijnen. Dit criterium helpt gebruikers met cognitieve beperkingen die baat hebben bij voorspelbare interfaces. De volgorde van hulpopties moet consistent blijven: als de chat-knop rechtsonder staat op de homepage, moet hij op alle pagina's rechtsonder staan. De hulpopties hoeven niet op alle pagina's aanwezig te zijn, maar als ze er zijn, moet de positie hetzelfde zijn. Een praktische implementatie: plaats contactinformatie consequent in de footer van elke pagina, zet een 'Help' link altijd op dezelfde plek in de hoofdnavigatie, of gebruik een floating support-widget die op alle pagina's op dezelfde positie verschijnt.
3.3.7 Overbodige invoer - Niveau A
Informatie die eerder in een proces al is ingevoerd of automatisch beschikbaar is, mag niet opnieuw gevraagd worden, tenzij het essentieel is voor veiligheid of de informatie niet meer geldig is. Dit criterium vermindert de cognitieve belasting en is vooral belangrijk voor mensen met geheugenproblemen of leerstoornissen. Een veelvoorkomend voorbeeld: bij een multi-step checkout hoeft het verzendadres niet opnieuw ingevoerd te worden als het hetzelfde is als het factuuradres. Gebruik een checkbox 'Factuuradres is hetzelfde als verzendadres' en vul het formulier automatisch in. Een ander voorbeeld: bij het invullen van een creditcardnummer moet de browser's autocomplete functie ondersteund worden met de juiste 'autocomplete' attributen, zodat gebruikers niet elke keer opnieuw hun gegevens hoeven in te typen.
3.3.8 Toegankelijke authenticatie (Minimum) - Niveau AA
Login-processen mogen geen cognitieve functietests vereisen, tenzij er een alternatieve methode beschikbaar is of een hulpmechanisme wordt aangeboden. Dit betekent dat wachtwoordmanagers ondersteund moeten worden (via 'autocomplete' attributen) en dat gebruikers niet gedwongen worden om ingewikkelde CAPTCHAs op te lossen of informatie uit hun geheugen op te halen. Goede alternatieven zijn object-herkenning CAPTCHAs ('Selecteer alle afbeeldingen met verkeerslichten'), biometrische authenticatie, of authenticatie via e-mail/SMS. Een praktische implementatie: gebruik 'autocomplete="username"' en 'autocomplete="current-password"' attributen op login-velden, zodat password managers de velden herkennen. Bied meervoudige authenticatie-opties aan, waaronder passwordless opties zoals magic links via e-mail.
3.3.9 Toegankelijke authenticatie (Uitgebreid) - Niveau AAA
De uitgebreide versie van criterium 3.3.8 verbiedt elke vorm van cognitieve functietest tijdens authenticatie. Zelfs object-herkenning CAPTCHAs zijn niet toegestaan. De enige toegestane methoden zijn: het herkennen van objecten, het invoeren van content die de gebruiker zelf heeft aangeleverd (zoals persoonlijke security questions), of mechanismen die niet-persoonlijke content gebruiken. In de praktijk betekent dit dat organisaties moeten vertrouwen op wachtwoordmanagers, biometrische authenticatie, hardware tokens, of authenticatie-apps. Een praktische implementatie voor AAA-niveau: gebruik WebAuthn voor hardware-token authenticatie, implementeer FIDO2 voor biometrische login, of gebruik OAuth providers (Google, Microsoft, Apple) waarbij de gebruiker al ingelogd is. Zorg ervoor dat de 'forgot password' flow ook toegankelijk is zonder cognitieve tests.
Verwijderd criterium: 4.1.1 Parsing
WCAG 2.2 heeft criterium 4.1.1 Parsing volledig verwijderd. Dit criterium vereiste dat HTML geen duplicate IDs had, geen duplicate attributen op elementen, en correct geneste tags gebruikte. De reden voor verwijdering is dat moderne browsers (sinds HTML5) parsing-fouten automatisch en consistent corrigeren volgens de HTML5-specificatie. Hulptechnologieën zoals screenreaders vertrouwen niet langer direct op de HTML parsing, maar op de browser's DOM tree die al gecorrigeerd is. Dit betekent niet dat valide HTML onbelangrijk is geworden - goede code is nog steeds een best practice - maar parsing-fouten leiden niet meer automatisch tot toegankelijkheidsproblemen. De verwijdering vermindert de administratieve last voor WCAG-audits zonder negatieve impact op de werkelijke toegankelijkheid.
Wat de European Accessibility Act vereist
De European Accessibility Act (EAA) treedt in werking op 28 juni 2025 en verwijst in zijn technische specificaties naar WCAG 2.1 niveau AA als minimumstandaard. Hoewel WCAG 2.2 niet expliciet verplicht is, adviseren toegankelijkheidsexperts en Europese instanties sterk om direct WCAG 2.2 na te streven. De reden is dat WCAG 2.2 volledig achterwaarts compatibel is met 2.1, dus conformiteit met 2.2 garandeert automatisch conformiteit met 2.1. Bovendien zullen toekomstige wetgevingsupdates waarschijnlijk WCAG 2.2 als referentie gebruiken, en de nieuwe criteria pakken belangrijke toegankelijkheidsproblemen aan die in 2.1 ontbreken. Organisaties die nu investeren in WCAG 2.2-conformiteit zijn toekomstbestendig en bieden een betere gebruikerservaring aan mensen met beperkingen.
Moet u WCAG 2.2 nastreven?
Het korte antwoord is ja. WCAG 2.2 is volledig achterwaarts compatibel met versie 2.1, wat betekent dat een website die voldoet aan WCAG 2.2 automatisch ook voldoet aan 2.1. De nieuwe criteria verbeteren de toegankelijkheid voor mensen met cognitieve beperkingen, mobiele gebruikers en toetsenbordgebruikers - groepen die vaak over het hoofd worden gezien. Vanaf een praktisch standpunt: als u nu begint met een toegankelijkheidsproject of bestaande code bijwerkt, richt u dan meteen op WCAG 2.2. De extra inspanning is minimaal vergeleken met de voordelen: toekomstbestendigheid, betere gebruikerservaring, en compliance met aankomende wetgeving. Voor organisaties die al WCAG 2.1-compliant zijn, is de stap naar 2.2 een logische evolutie die de toegankelijkheid merkbaar verbetert zonder bestaande functionaliteit te breken.
Hoe te testen op WCAG 2.2-conformiteit
WCAG 2.2-conformiteit vereist een combinatie van geautomatiseerde tools en handmatige testen. Geautomatiseerde tools zoals axe DevTools, WAVE of Lighthouse kunnen veel criteria controleren, maar detecteren maximaal 30-40% van alle toegankelijkheidsproblemen. De nieuwe 2.2-criteria vereisen vooral handmatige verificatie: test toetsenbordnavigatie om te controleren of gefocuste elementen niet verborgen worden (2.4.11), test sleepfunctionaliteit met alleen knoppen (2.5.7), meet aanwijsdoelen met browser developer tools (2.5.8), en doorloop multi-step processen om redundante invoer te identificeren (3.3.7). Gebruik een screenreader (NVDA of JAWS op Windows, VoiceOver op macOS/iOS) om de ervaring van blinde gebruikers te simuleren. Test op verschillende apparaten en schermformaten, vooral mobiele touchscreens waar doelgrootte cruciaal is. Voor een volledige audit is het aan te raden om een specialist in digitale toegankelijkheid in te schakelen die ervaring heeft met WCAG 2.2.