Wat is er nieuw in WCAG 2.2? De 9 nieuwe criteria in gewone taal

Iemand loopt met het toetsenbord door uw checkout. De focus komt op de knop “Nu betalen”, maar daar ligt een vaste cookiebanner overheen, dus die persoon ziet niet meer waar hij is. Onder WCAG 2.1 zou die pagina nog kunnen slagen. Onder WCAG 2.2 zakt ze.

Dat soort gaten dicht de update naar 2.2. Hieronder krijgt elk nieuw succescriterium dezelfde behandeling: wat het zegt, wie er baat bij heeft, een snelle test en de gebruikelijke oplossing. De vier principes en de niveaus op één pagina vindt u in onze Engelstalige WCAG 2.2-referentie.

Wat is WCAG 2.2?

WCAG 2.2 is de huidige versie van de Web Content Accessibility Guidelines (Richtlijnen voor Toegankelijkheid van Webcontent), de W3C-standaard waar de meeste toegankelijkheidswetten en -contracten naar verwijzen. De versie werd op 5 oktober 2023 (opent in een nieuw tabblad) een W3C-aanbeveling, werd op 12 december 2024 (opent in een nieuw tabblad) bijgewerkt en werd in oktober 2025 goedgekeurd als ISO/IEC 40500:2025 (opent in een nieuw tabblad).

WCAG bestaat uit toetsbare uitspraken, de succescriteria, elk met een niveau: A (het minimum), AA (waar wetten meestal om vragen) of AAA (het strengst). “We hebben WCAG 2.2 AA nodig” betekent: elk criterium van niveau A en AA in versie 2.2. Volgens de specificatie “bouwt 2.2 voort op WCAG 2.1 en is het daarmee achterwaarts compatibel”, dus de nieuwe versie vult 2.1 aan in plaats van die te vervangen.

Wat is er veranderd van WCAG 2.1 naar 2.2?

WCAG 2.2 voegt negen succescriteria toe en schrapt er één. Zes van de nieuwe zijn niveau A of AA en tellen dus mee voor het gebruikelijke doel AA: 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 en 3.3.8. De andere drie zijn AAA. Het geschrapte criterium is 4.1.1 Parsen, dat het W3C nu verouderd noemt.

4.1.1 Parsen controleerde op fouten in de markup, zoals dubbele ID's. De WCAG 2-FAQ (opent in een nieuw tabblad) legt uit dat die problemen nu onder andere criteria vallen, zoals 4.1.2 Naam, rol, waarde. Eén addertje: eist een contract nog WCAG 2.0 of 2.1, dan moet u 4.1.1 volgens het W3C “mogelijk blijven testen en rapporteren”.

Focus niet bedekt en Focusweergave: zien toetsenbordgebruikers waar ze zijn?

Deze criteria houden het element met de toetsenbordfocus zichtbaar. Op niveau AA (2.4.11) mag een link of knop met focus niet volledig worden verborgen door inhoud die u hebt toegevoegd, zoals een vaste header, cookiebanner of chatbubbel. Op AAA mag er helemaal niets overheen liggen (2.4.12), en moet het focuskader groot zijn en duidelijk contrasteren (2.4.13).

• Wie er baat bij heeft: ziende mensen die een toetsenbord gebruiken in plaats van een muis, vaak vanwege een motorische beperking. Zien ze de focus niet, dan zijn ze aan het gokken.
• Snelle test: laad een lange pagina waarop de cookiebanner, de vaste header en de chatwidget tegelijk te zien zijn, en druk een paar keer op Tab. Verdwijnt de focus helemaal achter iets, dan voldoet de pagina niet aan 2.4.11.
• Gebruikelijke oplossing: voeg in CSS scroll-padding toe ter hoogte van uw vaste header of footer, zodat de browser elementen met focus ervan vrij scrolt. Het W3C noemt dit een voldoende techniek (opent in een nieuw tabblad). Een banner kan ook slagen als hij modaal is en eerst moet worden weggeklikt.

Focusweergave (2.4.13) vraagt om een indicator die minstens zo groot is als een kader van 2 CSS-pixels dik rond het onderdeel, met een contrastverschil van ten minste 3:1 tussen de toestand met en zonder focus. Dat is AAA, maar een doorlopend kader van 2 pixels in een krachtige kleur haalt het meestal. Hoe u 3:1 meet, leest u in onze gids over kleurcontrast.

Sleepbewegingen en aanwijsgebieden: is uw site te gebruiken zonder precies te mikken?

Deze twee criteria op niveau AA helpen mensen die moeite hebben met nauwkeurig aanwijzen. 2.5.7 zegt dat alles wat u met slepen kunt doen, ook met losse klikken of tikken moet werken. 2.5.8 zegt dat aanwijsgebieden ten minste 24 bij 24 CSS-pixels moeten zijn, of zo ver uit elkaar moeten staan dat een cirkel met een diameter van 24 pixels, gecentreerd op elk gebied, geen ander gebied raakt.

2.5.7 Sleepbewegingen

Denk aan een schuifregelaar voor de prijsklasse in de filters van een webshop, of een verlanglijst die u door slepen herschikt. Voor iemand met een tremor of iemand die met een hoofdmuis werkt, kan indrukken, vasthouden, bewegen en loslaten heel moeilijk zijn.

Snelle test: voer elke sleeptaak uit met alleen klikken of tikken. Gebruikelijke oplossing: laat mensen overal op de baan van een schuifregelaar klikken, zet er vakjes voor “min” en “max” naast, of voeg knoppen “Omhoog” en “Omlaag” toe aan sorteerbare lijsten. Bediening met het toetsenbord alleen is niet genoeg: het Understanding-document (opent in een nieuw tabblad) van het W3C zegt dat een toetsenbordalternatief “niet automatisch aan dit succescriterium voldoet”.

2.5.8 Grootte van het aanwijsgebied (minimum)

De gebruikelijke fouten zijn kleine “×”-knoppen in pop-ups, dicht op elkaar staande paginanummers, sterrenbeoordelingen en rijen pictogrammen van sociale media. Ernaast tikken is voor iedereen irritant en voor mensen met een beperkte fijne motoriek een echte drempel.

• Uitzonderingen: links in een zin, aanwijsgebieden met een gelijkwaardig bedieningselement elders op de pagina dat wel groot genoeg is, elementen waarvan de browser de grootte bepaalt en die u niet hebt aangepast, en gevallen waarin een bepaalde grootte essentieel of wettelijk vereist is.
• Snelle test: probeer op een telefoon elk klein pictogram en elke kleine knop; om er een te meten, inspecteert u hem in de ontwikkelaarstools van uw browser.
• Gebruikelijke oplossing: voeg padding toe. Het klikbare gebied groeit, ook als het pictogram er hetzelfde uitziet. En zie 24 pixels als ondergrens: het oudere AAA-criterium 2.5.5 vraagt om 44 bij 44.

Consistente hulp en Overbodige invoer: laat u mensen zoeken of alles herhalen?

Beide zijn niveau A. 3.2.6 Consistente hulp zegt dat hulp, zoals contactgegevens, een chat of een link naar veelgestelde vragen, die op meerdere pagina's staat, telkens in dezelfde volgorde ten opzichte van de rest van de pagina moet staan. 3.3.7 Overbodige invoer zegt dat mensen informatie die ze in hetzelfde proces al hebben gegeven, niet opnieuw hoeven in te typen.

Consistente hulp verplicht u niet om überhaupt hulp aan te bieden. Het criterium zegt alleen: staat het telefoonnummer op productpagina's in de header, verplaats het dan niet naar de footer bij het afrekenen, waar mensen het het hardst nodig hebben. Mensen met geheugen- of aandachtsproblemen hebben er het meeste aan. De oplossing is meestal een gedeelde template in plaats van hulp per pagina te plaatsen.

Overbodige invoer richt zich op formulieren met meerdere stappen. Een boekingsformulier dat in stap 1 én in stap 3 om uw e-mailadres vraagt, zakt, en dat geldt ook voor een checkout waarin u een identiek factuuradres opnieuw moet typen. Vul het veld automatisch in of laat mensen het selecteren, bijvoorbeeld met een vinkje “Factuuradres is hetzelfde als bezorgadres”. De uitzonderingen: opnieuw invoeren is essentieel, nodig voor de beveiliging, of de eerdere informatie is niet meer geldig.

Toegankelijke authenticatie: kunnen mensen inloggen zonder geheugentest?

Succescriterium 3.3.8 (niveau AA) zegt dat geen enkele stap bij het inloggen mag leunen op een cognitieve functietest, zoals een wachtwoord onthouden, vervormde tekens overtypen of een puzzel oplossen, tenzij u een alternatief of hulpmiddel biedt. In de praktijk: laat wachtwoordmanagers de velden invullen, sta plakken toe en bied een methode die niet van het geheugen afhangt.

WCAG definieert een cognitieve functietest als “een taak waarbij de gebruiker informatie moet onthouden, bewerken of uitschrijven”. Uw naam, e-mailadres of telefoonnummer invullen telt niet mee, omdat die persoonlijk en overal hetzelfde zijn. Een inlogstap slaagt op niveau AA als die ten minste een van deze opties biedt:

• Een alternatief zonder cognitieve test, zoals een passkey of een link per e-mail.
• Een mechanisme dat helpt, zoals ondersteuning voor wachtwoordmanagers, of kopiëren en plakken zodat een eenmalige code niet hoeft te worden overgetypt.
• Objectherkenning, bijvoorbeeld “selecteer de afbeeldingen met een fiets”.
• Persoonlijke content, zoals een afbeelding herkennen die u zelf hebt geüpload.

De AAA-versie, 3.3.9, schrapt de laatste twee opties, dus een CAPTCHA met afbeeldingen kan op AA slagen, maar niet op AAA. Typische fouten: wachtwoordvelden die plakken of wachtwoordmanagers blokkeren, vakjes voor eenmalige codes die het begeven als u plakt, en een tekst-CAPTCHA zonder alternatief. Mensen met dyslexie of geheugenproblemen winnen het meest, maar iedereen die na een lange dag buitengesloten raakt, herkent het probleem.

Is WCAG 2.2 wettelijk verplicht?

Dat hangt af van waar u bent en wie u bent. Wetten noemen zelden direct een WCAG-versie, en verschillende verwijzen nog naar WCAG 2.1 AA. Omdat WCAG 2.2 achterwaarts compatibel is, voldoet u met 2.2 AA ook aan 2.1 AA, afgezien van het geschrapte 4.1.1. Wie op 2.2 mikt, dekt beide af. Noemt een contract een versie, volg dan het contract.

• Europese Unie: onder de European Accessibility Act geldt een vermoeden van conformiteit als u voldoet aan de geharmoniseerde norm EN 301 549. Volgens AccessibleEU (opent in een nieuw tabblad) neemt versie 4.1.1, gepubliceerd in september 2026, WCAG 2.2 over, maar is die nog niet de wettelijke referentie; tot ze in het Publicatieblad is opgenomen, geldt v3.2.1 (gebaseerd op WCAG 2.1 AA). Voor wie de wet geldt, leest u in onze uitleg over de European Accessibility Act.
• Verenigd Koninkrijk: volgens richtlijnen van de overheid (opent in een nieuw tabblad) moeten websites en apps van de publieke sector voldoen aan WCAG 2.2 AA. Die richtlijnen gelden voor overheidsinstanties, niet voor particuliere bedrijven.
• Verenigde Staten: de regel van het ministerie van Justitie voor deelstaten en lokale overheden gebruikt WCAG 2.1 AA, met deadlines die in april 2026 zijn verschoven (opent in een nieuw tabblad) naar 26 april 2027 en 26 april 2028. Voor particuliere bedrijven zeggen de richtlijnen van 2022 (opent in een nieuw tabblad) dat de ADA ook voor hun websites geldt, maar ze leggen geen specifieke technische norm vast.

En WCAG 3?

WCAG 3 is een concept, dus niemand kan er al aan voldoen. Het W3C publiceerde in september 2026 bijgewerkte concepten en verwacht dat WCAG 3 pas “over een paar jaar” een afgeronde standaard is. WCAG 2 wordt daarna nog jarenlang niet afgeschaft, dus 2.2 is de versie om nu mee te werken.

Hoe controleert u de nieuwe criteria in 15 minuten?

De meeste fouten op de zes criteria van niveau A en AA vindt u in ongeveer 15 minuten, met een toetsenbord, een telefoon en uw eigen inlogpagina. Het vervangt geen volledige audit of tests met mensen met een beperking, maar het laat zien waar u moet beginnen en geeft een ontwikkelaar een concrete lijst om mee aan de slag te gaan.

1. Ga met Tab door uw homepage, een productpagina en uw checkout terwijl alle banners zichtbaar zijn. Ziet u de focus altijd? (2.4.11)
2. Voer elke schuifregelaar- of sleeptaak uit met alleen klikken of tikken. (2.5.7)
3. Probeer op een telefoon elke sluitknop, elk paginanummer en elk klein pictogram. (2.5.8)
4. Vergelijk waar hulp en contactgegevens staan op drie soorten pagina's. (3.2.6)
5. Doorloop een aankoop of boeking en noteer elke vraag die u twee keer beantwoordt. (3.3.7)
6. Log in met een wachtwoordmanager en plak daarna een wachtwoord en een eenmalige code. Heeft elke CAPTCHA een alternatief? (3.3.8)

Voor de rest van WCAG behandelt onze gids over hoe u de toegankelijkheid van uw website test gratis tools en handmatige controles, en onze checklist voor websitetoegankelijkheid maakt van veelvoorkomende fouten een takenlijst. Wat u nog niet kunt oplossen, hoort in uw toegankelijkheidsverklaring.

Een opmerking over widgets, de onze inbegrepen: aan geen van deze criteria kunt u voldoen met een paneel voor bezoekers. Een grote cursor maakt kleine aanwijsgebieden makkelijker te raken, maar niet 24 pixels breed, en focus markeren schuift geen vaste banner opzij. Elk nieuw criterium gaat over hoe uw pagina's zijn gebouwd, dus de oplossing zit in uw templates en code.