WCAG 2.2 vs WCAG 2.1: Wat is nieuw en wat u moet bijwerken

Meer dan 96% van de homepages voldoet nog steeds niet aan de basisvereisten van de WCAG, volgens WebAIM's toegankelijkheidsanalyse van 2024 — en dat ten opzichte van een standaard die toen al vijf jaar oud was. Op 5 oktober 2023 publiceerde het W3C WCAG 2.2 als officiële webstandaard, waarbij de lat hoger werd gelegd met negen nieuwe succescriteria en één criterium dat verouderd was, werd geschrapt. Als je een website beheert, digitale producten bouwt of verantwoordelijk bent voor compliance, is dit een update die je niet eindeloos kunt uitstellen. Regelgeving in de EU, het VK en in toenemende mate Amerikaanse staten beweegt er al naartoe om WCAG 2.2 als referentiekader te gebruiken.

Een korte geschiedenis: van WCAG 2.1 naar WCAG 2.2

De Web Content Accessibility Guidelines hebben zich gestaag ontwikkeld sinds WCAG 2.0 in december 2008 werd gelanceerd. WCAG 2.1 verscheen in juni 2018 en voegde 17 nieuwe succescriteria toe, met een bijzondere focus op mobiele gebruikers en mensen met een beperkt gezichtsvermogen of cognitieve beperkingen. Vijf jaar lang fungeerde het als de feitelijke compliance-standaard voor wetten zoals de ADA, Section 508 en de EU Web Accessibility Directive.

WCAG 2.2 gaat precies verder waar 2.1 was gebleven. Het W3C startte dit met het expliciete doel om de toegankelijkheidsrichtlijnen verder te verbeteren voor drie grote groepen: gebruikers met cognitieve of leerstoornissen, gebruikers met een beperkt gezichtsvermogen en gebruikers met een beperking op mobiele apparaten. Die lijn is belangrijk, omdat het betekent dat de update evolutionair is, niet revolutionair — maar nog steeds betekenisvol genoeg om actie van jouw kant te vereisen.

Een van de belangrijkste structurele zaken om te begrijpen, is dat WCAG 2.2 volledig achterwaarts compatibel is met WCAG 2.1. Als je voldoet aan WCAG 2.2, voldoe je automatisch ook aan WCAG 2.1 en WCAG 2.0. Als je organisatie momenteel voldoet aan WCAG 2.1 AA, hoef je alleen de nieuwe criteria aan te pakken die in 2.2 zijn geïntroduceerd — je begint niet opnieuw. Het W3C adviseert ook dat, hoewel WCAG 2.0 en 2.1 geldige aanbevelingen blijven, organisaties WCAG 2.2 zouden moeten gebruiken om de toekomstige toepasbaarheid van hun toegankelijkheidswerk te maximaliseren.

Er wordt ook algemeen verwacht dat WCAG 2.2 de laatste dot-release van de WCAG 2.x-familie zal zijn. De volgende grote versie, WCAG 3.0, is een totaal ander beest — een fundamentele herziening van hoe toegankelijkheidsrichtlijnen zijn opgebouwd. Dat maakt WCAG 2.2 het definitieve eindpunt van een lijn die teruggaat tot 2008, en de versie die je nu op orde moet krijgen.

De cijfers: wat er daadwerkelijk is veranderd

Laten we precies zijn over de omvang van de verandering. WCAG 2.1 bevatte 78 succescriteria over drie niveaus van conformiteit (A, AA en AAA). WCAG 2.2 voegt negen nieuwe succescriteria toe en verwijdert er één — Succescriterium 4.1.1 Parsing — waardoor het totaal uitkomt op 86 actieve criteria. Van die negen toevoegingen zijn er twee op niveau A, vier op niveau AA en drie op niveau AAA.

Voor de overgrote meerderheid van organisaties die mikken op conformiteit op niveau AA — het niveau waarnaar in de meeste wetten en regels wordt verwezen — is de praktische impact zes nieuwe criteria om te implementeren. De drie toevoegingen op niveau AAA worden beschouwd als best practice en worden vaak aanbevolen in overheids- en zorgcontexten, maar zijn in de meeste rechtsgebieden vandaag geen harde wettelijke vereiste.

De nieuwe criteria richten zich vooral op vier probleemgebieden die in toegankelijkheidsaudits in de praktijk herhaaldelijk als onderbelicht in de bestaande standaard naar voren kwamen: zichtbaarheid van toetsenbordfocus, touch- en pointerinteracties, cognitieve toegankelijkheid en authenticatiebarrières. Dit zijn geen theoretische zorgen. Het zijn de soorten barrières die er regelmatig voor zorgen dat mensen met een beperking alledaagse taken niet kunnen afronden, zoals inloggen, een formulier invullen of een pagina met een sticky header navigeren.

De negen nieuwe succescriteria uitgelegd

Hier volgt een overzicht van elk nieuw criterium, wat het vereist en waarom het in de praktijk belangrijk is. De criteria worden per conformiteitsniveau gepresenteerd, zodat je je herstelwerkzaamheden kunt prioriteren.

Niveau A (Minimum — vereist voor iedereen)

• 2.4.11 Focus niet verduisterd (Minimum): Wanneer een UI-component toetsenbordfocus krijgt, mag deze niet volledig verborgen zijn door door de auteur gecreëerde content. De meest voorkomende boosdoeners zijn hier sticky headers, zwevende cookiebanners en livechat-widgets die bovenop de pagina liggen. Als een gebruiker met Tab op een knop terechtkomt die volledig wordt bedekt door je sticky navigatiebalk, wordt dit criterium geschonden. Let op: gedeeltelijk verduisterd is acceptabel op niveau A — het element mag alleen niet 100% verborgen zijn.
• 2.5.7 Sleepbewegingen: Elke functionaliteit die een sleepbeweging vereist — denk aan drag-and-drop-bestandsuploads, sorteerbare lijstitems of slidercontrols — moet ook bedienbaar zijn met één enkele pointeractie (zoals een klik of tik) zonder slepen. Dit is cruciaal voor gebruikers met motorische beperkingen die geen gecontroleerde sleepgebaren kunnen uitvoeren. De eis geldt voor door de auteur gecreëerde content; native browsergedragingen zijn uitgezonderd.

Niveau AA (Vereist voor standaardconformiteit)

• 2.4.12 Focus niet verduisterd (Uitgebreid): Een striktere versie van 2.4.11. Op niveau AA mag geen enkel deel van de focusindicator verborgen zijn door door de auteur gecreëerde content wanneer een element toetsenbordfocus krijgt. Dit sluit het achterdeurtje in de versie op niveau A en vereist dat gefocuste elementen volledig zichtbaar zijn — niet slechts gedeeltelijk.
• 2.5.8 Doelgrootte (Minimum): Het klikbare of tikbare gebied van interactieve elementen moet minimaal 24×24 CSS-pixels zijn, met specifieke uitzonderingen voor inline tekstlinks, door de user agent gecontroleerde elementen en gevallen waarin zich in de buurt een equivalent doel van 24×24 bevindt. Dit is een belangrijke verandering ten opzichte van WCAG 2.1, waar een doelgrootte van 44×44 pixels alleen op AAA-niveau werd aanbevolen. Nu is een minimale ondergrens afdwingbaar op AA. Let op: hoewel 24×24px de ondergrens is, beveelt het AAA-criterium (2.5.5) nog steeds 44×44px aan, en dat blijft de gouden standaard voor touchvriendelijk ontwerp.
• 3.2.6 Consistente hulp: Als een website hulpmechanismen biedt — contactgegevens van een persoon, selfservicetools, geautomatiseerde chat of een contactformulier — en die mechanismen komen op meerdere pagina’s voor, dan moeten ze op die pagina’s op dezelfde relatieve positie verschijnen. Gebruikers die hulp nodig hebben, vooral mensen met cognitieve beperkingen, moeten die altijd op dezelfde plek kunnen vinden zonder te hoeven zoeken.
• 3.3.7 Redundante invoer: Informatie die een gebruiker al in een eerdere stap van hetzelfde proces heeft ingevoerd, moet ofwel automatisch voor hem/haar worden ingevuld of beschikbaar zijn om te selecteren, zodat die niet opnieuw hoeft te worden getypt. Denk aan meerstaps-checkoutflows die om een factuuradres vragen en vervolgens opnieuw om een verzendadres — gebruikers moeten de mogelijkheid krijgen om te kopiëren wat ze al hebben ingevoerd. Uitzonderingen zijn toegestaan wanneer het opnieuw invoeren van informatie essentieel is voor de beveiliging (zoals het bevestigen van een wachtwoord) of wanneer de eerder ingevoerde gegevens niet langer geldig zijn.
• 3.3.8 Toegankelijke authenticatie (Minimum): Tests van cognitieve functies — zoals het oplossen van een puzzel, het onthouden van een wachtwoord of het overtypen van tekens uit een afbeeldings-CAPTCHA — mogen niet vereist zijn als enige middel van authenticatie. Er moet een alternatieve methode beschikbaar zijn, of er moet een mechanisme zijn dat de gebruiker helpt (zoals het toestaan van een wachtwoordmanager of het toestaan van kopiëren-plakken in het wachtwoordveld). Dit criterium verbiedt CAPTCHAs niet volledig, maar vereist wel dat ze nooit de enige optie zijn voor gebruikers die ze niet kunnen voltooien.

Niveau AAA (Uitgebreid — aanbevolen maar niet verplicht voor de meesten)

• 2.4.13 Focusweergave: Wanneer de toetsenbordfocusindicator zichtbaar is, moet deze aan specifieke minimale grootte- en contrastvereisten voldoen: het focusgebied moet minstens zo groot zijn als een perimeter van 2 CSS-pixels dik rond het element, en er moet een contrastverhouding van minimaal 3:1 zijn tussen de gefocuste en niet-gefocuste toestand. Dit criterium was oorspronkelijk gepland voor niveau AA, maar is vanwege de complexiteit naar AAA verplaatst. Dit betekent dat er voor alleen AA-conformiteit nog steeds geen normatief gedefinieerde minimale grootte voor een focusindicator is — alleen dat er een zichtbaar moet zijn.
• 2.5.9 Sleepbewegingen (Uitgebreid): Wacht — er is geen 2.5.9 in deze release. De AAA-uitbreiding voor slepen is opgenomen in 3.3.9 hieronder.
• 3.3.9 Toegankelijke authenticatie (Uitgebreid): Een striktere versie van 3.3.8. Op niveau AAA zijn ook objectherkennings- en persoonlijke inhoudstests (zoals "klik op alle verkeerslichten" of "selecteer foto’s uit je account") verboden, niet alleen de uitzonderingen die op niveau AA zijn toegestaan. Er blijven slechts twee uitzonderingen over in plaats van vier.

Wat is verwijderd: 4.1.1 Parsing

WCAG 2.2 verwijdert één succescriterium dat sinds WCAG 2.0 van kracht was: 4.1.1 Parsing. Dit criterium vereiste oorspronkelijk dat HTML goed gevormd was, met volledige begin- en eindtags, correcte nesting en geen dubbele attributen. De bedoeling was om ervoor te zorgen dat browsers en ondersteunende technologieën de markup betrouwbaar konden parsen en content correct aan gebruikers konden presenteren.

De verwijdering is niet controversieel — ze weerspiegelt een echte verschuiving in het technische landschap. Sinds 2008 zijn browsers buitengewoon goed geworden in het gracieus afhandelen van slecht gevormde HTML, volgens een consistent, gestandaardiseerd foutcorrectie-algoritme. Ondersteunende technologieën zoals schermlezers vertrouwen nu op het Document Object Model (DOM) van de browser, niet op de ruwe HTML-broncode. Het W3C concludeerde dat het criterium in de moderne omgeving geen betekenisvol toegankelijkheidsvoordeel meer biedt. Toegankelijkheidsproblemen die vroeger door 4.1.1 werden opgevangen, vallen nog steeds onder specifiekere criteria zoals 1.3.1 (Info and Relationships) en 4.1.2 (Name, Role, Value).

De praktische implicaties voor je team: als je geautomatiseerde testtools 4.1.1 Parsing-fouten hebben gesignaleerd, zijn dat geen WCAG 2.2-issues meer. Je kunt een vermindering van het aantal gerapporteerde fouten zien puur door de versie-upgrade, niet omdat er iets is opgelost. Dat gezegd hebbende, blijft het schrijven van geldige, goed gestructureerde HTML een sterke best practice — het is alleen niet langer op zichzelf een compliance-eis.

Regelgevende en juridische implicaties

De nieuwe criteria begrijpen is één ding. Begrijpen wat ze betekenen voor je juridische risico is iets anders. Het korte antwoord is: WCAG 2.2 wordt in meerdere rechtsgebieden de norm, en de tijdlijn beweegt sneller dan veel organisaties beseffen.

In het Verenigd Koninkrijk zijn publieke organisaties al verplicht om te voldoen aan WCAG 2.2 niveau AA onder de Public Sector Bodies Accessibility Regulations. In de Europese Unie is EN 301 549 — de technische standaard die ten grondslag ligt aan de European Accessibility Act — bezig WCAG 2.2 als basis te adopteren. De EAA zelf heeft een handhavingsdeadline in juni 2025 voor de meeste private organisaties die producten en diensten in de EU aanbieden. Verschillende Amerikaanse staten, waaronder Colorado, hebben ook de intentie uitgesproken om hun toegankelijkheidswetgeving op staatsniveau bij te werken van WCAG 2.1 naar WCAG 2.2.

In de Verenigde Staten verwijst ADA Title II momenteel naar WCAG 2.1 AA als technische standaard voor websites van lokale en staats-overheden. Amerikaanse rechtbanken verwijzen echter in toenemende mate naar WCAG 2.2 in toegankelijkheidsrechtszaken, en de richting is duidelijk. Wachten op een formeel federaal mandaat voordat je in actie komt, is een compliance-strategie met een groeiend juridisch risico, vooral voor e-commerce, financiële dienstverlening en zorgorganisaties die aantrekkelijke doelwitten zijn voor toegankelijkheidsprocedures.

Zelfs als je organisatie nog niet wettelijk verplicht is om aan WCAG 2.2 te voldoen, zorgt het eerder dan later voldoen aan de nieuwe succescriteria ervoor dat je voorloopt op veranderende regelgeving — en, belangrijker nog, op echte toegankelijkheidsbarrières waar je gebruikers vandaag mee te maken hebben.

Hoe je je site kunt auditen en updaten

Als je al voldoet aan WCAG 2.1 AA, is het upgradepad naar WCAG 2.2 beheersbaar. Hier is een praktisch kader om dit aan te pakken.

Begin met een gerichte audit van de zes nieuwe criteria op niveau AA. Dit zijn de criteria die voor de meeste organisaties juridisch gewicht hebben. Richt je vooral op 2.4.11 en 2.4.12 (focus verduisterd), 2.5.8 (doelgrootte), 3.2.6 (consistente hulp), 3.3.7 (redundante invoer) en 3.3.8 (toegankelijke authenticatie). Een ervaren toegankelijkheidsengineer kan deze criteria doorgaans handmatig in een paar uur auditen voor een site met gemiddelde complexiteit.

Audit eerst je sticky/fixed-position-elementen. De criteria rond focus verduisterd (2.4.11 en 2.4.12) worden geschonden door enkele van de meest voorkomende UI-patronen op het web — sticky headers, floating action buttons, cookiebalken en chatwidgets. Loop je hele site door met alleen de Tab-toets en kijk of een gefocust element ooit onder een vaste laag verdwijnt. Een CSS-fix is meestal eenvoudig:

/* Voorkom dat sticky header gefocuste elementen bedekt */
:focus {
  scroll-margin-top: 80px; /* stem af op de hoogte van je sticky header */
}

Audit de tapdoelgrootte van elk interactief element. Dit is vaak een snelle winst, zowel qua compliance als qua gebruikerservaring. Knoppen, links, formulierelementen en iconen hebben allemaal een minimum van 24×24 CSS-pixels nodig. Veel design systems overschrijden deze drempel al, maar kleine icoonknoppen — sluiticonen, social share-knoppen en inline actielinks — zijn veelvoorkomende overtreders. Inspecteer je componenten en voeg waar nodig padding toe of pas de afmetingen aan.

Bekijk je authenticatieflows zorgvuldig. SC 3.3.8 (Toegankelijke authenticatie) heeft echte tanden. Als je een CAPTCHA gebruikt die niet kan worden omzeild of opgelost via een alternatieve methode, ben je waarschijnlijk niet conform. Beoordeel of je login-, registratie- en tweefactorauthenticatieflows wachtwoordmanagers toestaan om automatisch in te vullen, kopiëren-plakken toestaan, een alternatieve verificatiemethode bieden (zoals een magic link of een eenmalige code) of een andere voorziening bieden voor gebruikers die geen cognitieve uitdaging kunnen voltooien.

Audit meerstapsformulieren op redundante invoer. Breng alle processen in kaart die uit meerdere stappen bestaan — checkouts, onboardingflows, aanvragen — en identificeer elke situatie waarin een gebruiker wordt gevraagd informatie te geven die al eerder is verstrekt. Voeg waar van toepassing logica voor automatisch invullen toe of een "zelfde als hierboven"-schakelaar. Dit is doorgaans een wijziging in de back-end of in het beheer van formulierstatus, geen complexe architecturale ingreep.

Controleer of hulpmechanismen consistent gepositioneerd zijn. Als je een chatwidget, een helplink of een telefoonnummer hebt dat in een footer of sidebar op meerdere pagina’s verschijnt, controleer dan of de relatieve positie niet verschuift. Dit is meestal een template- of layout-issue in plaats van een probleem per pagina — los het op in je componentenbibliotheek of CMS-template en het werkt overal door.

Gebruik geautomatiseerde tools voor de eerste inventarisatie, maar stop daar niet. Geautomatiseerde scanners kunnen ongeveer 40% van de WCAG 2.2-issues detecteren — ze zijn nuttig om schendingen van doelgrootte en duidelijke focusmanagementproblemen op te sporen, maar ze kunnen niet beoordelen of een CAPTCHA de enige authenticatieoptie is of dat een hulpmechanisme consistent gepositioneerd is. Handmatig testen, inclusief navigatie met alleen het toetsenbord en testen met een schermlezer, blijft essentieel. Testen met echte gebruikers met een beperking zal problemen aan het licht brengen die geen enkele geautomatiseerde tool ooit zal vinden.

WCAG 2.2 en overlay-widgets: wat je moet weten

Toegankelijkheidsoverlay-widgets en SDK’s — tools zoals Accsible — kunnen zinvolle hulp bieden bij het signaleren en verhelpen van bepaalde categorieën toegankelijkheidsproblemen, vooral voor gebruikers die realtime-aanpassingen nodig hebben zoals grotere lettergrootte, contrastwijzigingen of verbeterde toetsenbordnavigatie. Het is de moeite waard om helder te zijn over wat overlays wel en niet kunnen in de context van WCAG 2.2-conformiteit.

Overlays kunnen helpen bepaalde problemen met focuszichtbaarheid aan te pakken, alternatieve navigatiemodi te bieden en gebruikerszijde-aanpassingen te bieden die sommige tekortkomingen op ontwerpniveau compenseren. Ze zijn een nuttige laag in de toegankelijkheidsstack, vooral voor teams die de gebruikerservaring snel moeten verbeteren terwijl er aan langetermijnoplossingen wordt gewerkt. Ze zijn echter geen vervanging voor het oplossen van de onderliggende code. De nieuwe WCAG 2.2-criteria — met name rond authenticatie (3.3.8), redundante invoer (3.3.7) en sleepbewegingen (2.5.7) — vereisen structurele veranderingen in hoe je applicatie is gebouwd, niet alleen in hoe die wordt gepresenteerd.

De meest effectieve aanpak combineert een goed geïmplementeerde overlay voor aanpasbaarheid aan de gebruikerskant met correcte fixes op codeniveau voor de nieuwe 2.2-criteria. Zie een overlay-SDK als een krachtvermenigvuldiger: hij vergroot je bereik, verbetert de ervaring voor meer gebruikers en vult gaten op — maar de basis moet nog steeds solide zijn.

Belangrijkste punten

• WCAG 2.2 voegt negen nieuwe succescriteria toe en verwijdert één verouderde regel (4.1.1 Parsing). De standaard is volledig achterwaarts compatibel met 2.1, dus je bestaande compliance-werk is niet verspild — je hoeft alleen toe te voegen wat nieuw is.
• Richt je voor conformiteit op niveau AA op zes specifieke nieuwe criteria: Focus niet verduisterd (2.4.11 en 2.4.12), minimale doelgrootte (2.5.8), consistente hulp (3.2.6), redundante invoer (3.3.7) en toegankelijke authenticatie (3.3.8). Dit zijn de juridisch relevante criteria voor de meeste organisaties.
• De regulatoire adoptie versnelt. De Britse publieke sector handhaaft WCAG 2.2 al, de EU stapt eronder over in het kader van de European Accessibility Act, en Amerikaanse rechtbanken verwijzen er in toenemende mate naar. Wacht niet op een formeel mandaat in jouw rechtsgebied voordat je in actie komt.
• Geautomatiseerde tools vangen slechts ongeveer 40% van de WCAG 2.2-issues — handmatig testen, walkthroughs met alleen het toetsenbord en testen met echte gebruikers zijn essentieel om echte conformiteit te bereiken, vooral voor de nieuwe criteria rond authenticatie en cognitieve toegankelijkheid.
• De meest voorkomende quick wins zijn het repareren van sticky headers die gefocuste elementen verduisteren, het vergroten van kleine tapdoelen en het auditen van je login-/authenticatieflows op afhankelijkheid van CAPTCHA. Deze veranderingen vergen vaak relatief weinig inspanning en hebben veel impact — een goed startpunt voor je WCAG 2.2-remediatiesprint.