WCAG 2.2 (website toegankelijkheid) is voor veel organisaties geen technisch zijspoor meer, maar een vast onderdeel van goed webbeheer. De richtlijnen helpen je om een website te bouwen en te onderhouden die bruikbaar is voor mensen met verschillende beperkingen, apparaten en manieren van bedienen. Denk aan bezoekers die met een toetsenbord navigeren, schermlezers gebruiken, moeite hebben met kleine klikvlakken of vastlopen in formulieren en inlogprocessen. WCAG 2.2 geeft daar een duidelijke structuur voor. Tegelijk roept het vaak vragen op. Wat valt er precies onder? Wat is er nieuw ten opzichte van eerdere versies? En hoe pak je het aan zonder te verzanden in losse checklists? In dit artikel zetten we de kern helder op een rij, met aandacht voor de vier WCAG-principes, de belangrijkste vernieuwingen in versie 2.2 en een praktische aanpak voor toetsing en uitvoering.
Wat website toegankelijkheid WCAG 2.2 precies inhoudt
WCAG staat voor Web Content Accessibility Guidelines. Het is de internationale standaard voor digitale toegankelijkheid. De richtlijnen zijn opgebouwd rond vier principes. Webcontent moet waarneembaar, bedienbaar, begrijpelijk en robuust zijn. Die indeling is nuttig, omdat toegankelijkheid daarmee geen losse verzameling eisen wordt, maar een manier om naar een complete gebruikerservaring te kijken.
WCAG staat voor Web Content Accessibility Guidelines. Het is de internationale standaard voor digitale toegankelijkheid.
De vier principes in gewone taal
- Waarneembaar: informatie moet op een manier beschikbaar zijn die gebruikers kunnen waarnemen. Denk aan tekstalternatieven voor afbeeldingen, voldoende contrast en een logische structuur in content.
- Bedienbaar: bezoekers moeten de interface kunnen gebruiken, ook zonder muis. Toetsenbordtoegang, duidelijke focus en genoeg tijd voor interactie horen daarbij.
- Begrijpelijk: content en interactie moeten voorspelbaar en helder zijn. Formulieren, foutmeldingen en navigatie spelen hier een grote rol.
- Robuust: de website moet goed werken met verschillende browsers, hulptechnologieën en toekomstige interpretaties van code.
WCAG werkt met niveaus van conformiteit, waaronder A, AA en AAA. In de praktijk is niveau AA vaak het richtpunt. Dat betekent niet dat je alleen technische vinkjes zet. Je moet ook kijken of een pagina in samenhang werkt. Een formulier kan bijvoorbeeld formeel labels hebben, maar alsnog verwarrend zijn als foutmeldingen onduidelijk zijn of de toetsenbordfocus wegvalt.
Conformiteit is meer dan een losse pagina scoren
De officiële documentatie maakt ook duidelijk dat conformiteit voorwaarden kent. Het gaat niet alleen om afzonderlijke succescriteria, maar om de vraag of een volledige pagina aan de eisen voldoet. Daarbij spelen ook uitzonderingen en nuances mee, zoals content van derden of situaties waarin een deel van de inhoud buiten je directe invloed valt. Dat vraagt om een realistische beoordeling. Je wilt weten wat binnen je eigen platform, ontwerp, code en redactie oplosbaar is, en waar afhankelijkheden zitten.
Wat is er nieuw in WCAG 2.2
Versie 2.2 bouwt voort op eerdere WCAG-versies en voegt een aantal nieuwe aandachtspunten toe. Die zitten vooral in onderdelen waar gebruikers in de praktijk vaak vastlopen: focus, klikvlakken, slepen, herhaalde invoer en authenticatie. Juist daarom is WCAG 2.2 relevant voor websites, webshops, portalen en omgevingen met formulieren of accountfuncties.
Belangrijke wijzigingen in WCAG 2.2
- Focus not obscured: wanneer iemand met het toetsenbord door een pagina navigeert, moet de zichtbare focus niet verborgen raken achter vaste headers, sticky elementen of overlays.
- Target size: interactieve elementen moeten voldoende groot zijn om aan te klikken of aan te tikken, zeker op mobiel of voor gebruikers met beperkte motoriek.
- Accessible authentication: inlogprocessen mogen niet onnodig afhankelijk zijn van cognitief zware taken, zoals het onthouden, oplossen of exact reproduceren van complexe informatie.
- Redundant entry: gebruikers hoeven dezelfde informatie niet onnodig opnieuw in te voeren als die al eerder is opgegeven in hetzelfde proces.
- Dragging movements: als een handeling afhankelijk is van slepen, moet er een alternatief zijn dat zonder sleepbeweging werkt.
Deze aanvullingen laten goed zien waar WCAG 2.2 de praktijk dichter benadert. Toegankelijkheid gaat niet alleen over schermlezers of alt-teksten, maar ook over alledaagse frictie. Een klein icoon in een mobiele navigatie, een focusrand die onder een sticky menubalk verdwijnt of een inlogstap die alleen werkt met een puzzelachtige verificatie: dat zijn precies de situaties waar gebruikers afhaken.
Toegankelijkheid gaat niet alleen over schermlezers of alt-teksten, maar ook over alledaagse frictie.
Waarom deze wijzigingen ertoe doen
De nieuwe criteria maken websites vaak niet alleen toegankelijker voor mensen met een beperking, maar ook prettiger voor een veel bredere groep. Grotere klikvlakken helpen bijvoorbeeld ook op kleine schermen. Minder dubbele invoer scheelt tijd voor iedereen. En een duidelijke focus is nuttig voor elke bezoeker die zonder muis werkt, tijdelijk of structureel. Daarmee is WCAG 2.2 geen los compliance-onderwerp, maar een directe kwaliteitsmaat voor interactie en gebruiksgemak.
Van richtlijn naar praktijk: waar je website vaak op vastloopt
Veel toegankelijkheidsproblemen ontstaan niet in theorie, maar in dagelijkse ontwerp- en ontwikkelkeuzes. Een componentbibliotheek zonder goede focusstijlen, een formulier dat alleen visueel feedback geeft of content die netjes oogt maar semantisch rommelig is: het zijn bekende oorzaken van toegankelijkheidsissues.
Ontwerp en interactie
Designkeuzes hebben veel invloed op toegankelijkheid. Denk aan contrast, leesbaarheid, volgorde in de interface en de zichtbaarheid van interactieve elementen. Een knop moet eruitzien als een knop. Een link moet herkenbaar zijn als link. En een toetsenbordgebruiker moet kunnen zien waar de focus staat. Vooral bij sticky headers, modals en mobiele menu’s gaat dat geregeld mis.
Designkeuzes hebben veel invloed op toegankelijkheid. Denk aan contrast, leesbaarheid, volgorde in de interface en de zichtbaarheid van interactieve elementen.
Content en redactie
Toegankelijke content vraagt om meer dan korte zinnen. Je hebt ook een logische koppenstructuur nodig, beschrijvende linkteksten, duidelijke formulieren en media die bruikbaar blijven voor verschillende gebruikers. Een pagina met vijf keer ‘lees meer’ is voor een schermlezergebruiker veel minder duidelijk dan links die meteen zeggen waar ze naartoe gaan. Hetzelfde geldt voor foutmeldingen. Als een formulier alleen rood kleurt zonder tekstuele uitleg, mist een deel van de bezoekers cruciale informatie.
Code en compatibiliteit
Onder de motorkap draait veel om semantische HTML, correcte labels, foutloze focusvolgorde en een interface die samenwerkt met hulptechnologie. ARIA kan helpen, maar alleen als de basis klopt. Een div die zich gedraagt als knop is vaak kwetsbaarder dan een echte button. WCAG 2.2 vraagt daarom niet om extra lagen complexiteit, maar juist om zorgvuldige keuzes in de basis.
Praktische aandachtspunten per onderdeel
- Formulieren: koppel labels goed aan velden, geef duidelijke foutmeldingen en voorkom dat gebruikers gegevens opnieuw moeten invullen.
- Navigatie: zorg dat menu’s, skiplinks en focusstijlen ook met toetsenbordgebruik logisch werken.
- Knoppen en links: maak klikvlakken ruim genoeg en houd tekst herkenbaar en specifiek.
- Inloggen: kijk kritisch naar verificatiestappen die veel geheugen, interpretatie of precisie vragen.
- Interacties: bied alternatieven voor slepen, hover-afhankelijke bediening en tijdsgevoelige acties.
Wie deze punten vroeg in ontwerp en bouw meeneemt, voorkomt veel herstelwerk achteraf.
Hoe je de toegankelijkheid van je website test
Toegankelijkheid toetsen vraagt om een combinatie van automatische controles en handmatige beoordeling. Tools zijn nuttig, maar ze zien lang niet alles. Een scanner kan bijvoorbeeld een ontbrekend alt-attribuut signaleren, maar niet bepalen of een foutmelding begrijpelijk is of een focusvolgorde logisch aanvoelt.
Een werkbare testaanpak
- Begin met een inventarisatie van belangrijke paginatypen, zoals homepage, categoriepagina, productpagina, formulier, accountomgeving en checkout.
- Voer automatische checks uit om snelle technische signalen op te halen, bijvoorbeeld rond contrast, labels en semantiek.
- Test handmatig met alleen het toetsenbord. Controleer of je overal kunt komen, of de focus zichtbaar blijft en of interactieve onderdelen bruikbaar zijn.
- Bekijk formulieren stap voor stap. Let op labels, foutmeldingen, invoerhulp en onnodige herhaling van gegevens.
- Controleer complexe interacties zoals modals, accordeons, tabs, sliders en drag-and-drop-functionaliteit.
- Beoordeel contentstructuur: koppen, linkteksten, tabellen, media en leesvolgorde.
Toegankelijkheid toetsen vraagt om een combinatie van automatische controles en handmatige beoordeling.
Wat je handmatig altijd wilt nalopen
- Is de toetsenbordfocus zichtbaar en raakt die nergens verborgen?
- Zijn klik- en tikdoelen groot genoeg?
- Kun je alle belangrijke handelingen uitvoeren zonder slepen?
- Zijn inlog- en verificatieprocessen ook bruikbaar voor mensen die moeite hebben met onthouden of interpreteren?
- Moet een gebruiker ergens onnodig dezelfde informatie opnieuw invoeren?
Een goede toetsing stopt niet na één audit. Toegankelijkheid hoort thuis in je workflow. Nieuwe content, nieuwe componenten en redesigns kunnen bestaande problemen terugbrengen of nieuwe veroorzaken. Daarom werkt een vaste werkwijze beter dan een eenmalige controle.
Maak toegankelijkheid onderdeel van je proces
Leg vast wie waarop let. Designers bewaken onder meer contrast, focus en componentgedrag. Developers zorgen voor semantiek, toetsenbordbediening en technische compatibiliteit. Redacteuren letten op structuur, linkteksten en begrijpelijke formulieren. Zo wordt WCAG 2.2 geen eindcontrole, maar een kwaliteitscriterium tijdens ontwerp, bouw en beheer.
WCAG 2.2 en conformiteit: wat je wel en niet kunt claimen
Wie met WCAG 2.2 aan de slag gaat, komt al snel uit bij de vraag wanneer een website echt ‘voldoet’. De officiële richtlijnen zijn daar zorgvuldig in. Conformiteit betekent dat aan de relevante succescriteria is voldaan op het beoogde niveau, maar ook dat de pagina als geheel toegankelijk blijft. Dat vraagt om precisie in hoe je resultaten vastlegt en communiceert.
Wees precies in je beoordeling
Een losse uitspraak als ‘de website is WCAG-proof’ zegt weinig als niet duidelijk is wat is onderzocht, op welk niveau, welke onderdelen zijn meegenomen en welke beperkingen er nog zijn. Zeker bij grotere websites of platforms met externe inhoud is het verstandig om onderscheid te maken tussen eigen componenten, redactionele content en content van derden.
Houd rekening met uitzonderingen en afhankelijkheden
De W3C-documentatie benoemt ook situaties waarin partiële conformiteit een rol kan spelen, bijvoorbeeld bij content van derden of taalonderdelen die buiten de directe invloed van de eigenaar vallen. Daarnaast zijn er privacy- en securityoverwegingen. Toegankelijkheid moet dus zorgvuldig worden afgewogen binnen de context van een website, zonder dat dit een excuus wordt om duidelijke knelpunten te laten liggen. Juist daarom is een onderbouwde audit met heldere scope waardevoller dan een algemene claim.
WCAG 2.2 vraagt om een brede blik
Je kijkt niet alleen naar code, maar ook naar ontwerp, content, interactie en beheer. De richtlijnen geven houvast met vier duidelijke principes en versie 2.2 legt extra nadruk op punten waar gebruikers vaak echt vastlopen, zoals focus, klikvlakken, slepen, dubbele invoer en authenticatie. Wie toegankelijkheid vroeg meeneemt in ontwerp en ontwikkeling, werkt gerichter en voorkomt kostbaar herstelwerk. En wie test met zowel tools als handmatige controles, krijgt een veel realistischer beeld van de werkelijke gebruikservaring. Daarmee wordt WCAG 2.2 geen afvinklijst, maar een praktische standaard voor websites die voor meer mensen bruikbaar zijn.