Je website WCAG 2.2-conform maken

Je website WCAG 2.2-conform maken is een proces, geen eenmalige oplossing. Conformiteit is de uitkomst van een herhaalbare workflow: begrijp de standaard, meet waar je staat, los de juiste dingen in de juiste volgorde op, valideer met echte hulptechnologie en echte gebruikers, documenteer het resultaat en voorkom dat het terugvalt. Deze gids vertaalt die workflow naar een concrete, stapsgewijze routekaart die je team vandaag nog kan gebruiken — zonder gebruik te maken van toegankelijkheids-”overlays”, die problemen in de DOM maskeren in plaats van ze op te lossen en herhaaldelijk in rechtszaken zijn genoemd.

Stap 1: Begrijp wat WCAG 2.2 daadwerkelijk vereist

Voordat je iets audit, moet je duidelijk hebben wat het doel is. De Web Content Accessibility Guidelines zijn georganiseerd rond vier principes, samengevat in het acroniem POUR:

Perceivable (waarneembaar) — gebruikers moeten de inhoud kunnen waarnemen. Denk aan tekstalternatieven voor afbeeldingen, ondertiteling en transcripties voor media, en voldoende kleurcontrast.
Operable (bedienbaar) — elke functie moet werken zonder muis. Volledige toetsenbordbediening, zichtbare focusindicatoren en geen toetsenbordvallen zijn kerneisen.
Understandable (begrijpelijk) — inhoud en gedrag moeten voorspelbaar zijn. Duidelijke labels, consistente navigatie, behulpzame foutmeldingen en leesbare taal horen hier allemaal thuis.
Robust (robuust) — de opmaak moet leesbaar zijn voor huidige en toekomstige hulptechnologie, wat in de praktijk betekent: valide HTML en correct gebruik van ARIA-namen, -rollen en -waarden.

Elk principe valt uiteen in toetsbare succescriteria, en elk criterium krijgt een conformiteitsniveau toegewezen: A (essentieel), AA (de wettelijke en praktische basislijn die de meeste organisaties nastreven) en AAA (verbeterd). Wanneer mensen “WCAG 2.2 AA” zeggen, bedoelen ze het voldoen aan elk succescriterium van niveau A en niveau AA. WCAG 2.2 voegt negen nieuwe criteria toe ten opzichte van 2.1 — waaronder Focus Not Obscured, Dragging Movements, Target Size (Minimum) en Accessible Authentication — die de meeste de ervaring verbeteren voor gebruikers met een toetsenbord, slechtziendheid en motorische beperkingen.

Het helpt om te weten waarom dit het doel is. AA-conformiteit wordt genoemd in de wetten en regelgeving die hoogstwaarschijnlijk op jou van toepassing zijn: lees je in over WCAG-conformiteit als de technische standaard, en kijk vervolgens hoe die zich verhoudt tot de European Accessibility Act, de ADA voor private en publieke Amerikaanse entiteiten, en Section 508 voor Amerikaanse federale instanties en hun leveranciers. Als terminologie je onderweg in de war brengt, houd dan onze toegankelijkheidsverklarende woordenlijst open in een tabblad.

Twee andere concepten bepalen elke eerlijke conformiteitsclaim. Het eerste is conformiteitsscope: WCAG-conformiteit geldt voor volledige pagina’s, niet voor geïsoleerde componenten, en voor complete processen (bijv. een volledige afrekenflow) — je kunt niet beweren dat een pagina conform is als één stap in een meerstapstaak faalt. Het tweede is toegankelijkheidsondersteunde technologie: je mag alleen vertrouwen op manieren om een functie te gebruiken die daadwerkelijk worden ondersteund door de hulptechnologie die je gebruikers hebben. In de praktijk betekent dit testen met actuele schermlezers en browsers in plaats van aan te nemen dat valide opmaak alleen een bruikbaar resultaat garandeert. Houd beide in gedachten terwijl je je werk in de onderstaande stappen afbakent; ze bepalen wat je verdedigbaar kunt zeggen te hebben bereikt.

Stap 2: Voer een geautomatiseerde basisscan uit

Je kunt niet oplossen wat je niet kunt meten, dus stel een basislijn vast. Geautomatiseerd testen is snel, herhaalbaar en uitstekend in het opsporen van de hoogvolume, mechanische fouten die de meeste sites teisteren: ontbrekende alternatieve tekst, laag kleurcontrast, lege links en knoppen, niet-gelabelde formuliervelden, ontbrekende documenttaal en dubbele ID’s.

Tools gebouwd op de open-source axe-core-engine — waaronder QualiBooth’s software voor toegankelijkheidsscans — produceren binnen enkele minuten een geprioriteerde lijst met problemen. Als je gewoon snel wilt weten waar je staat, begin dan met een gratis toegankelijkheidsscan van een paar belangrijke pagina’s.

Een paar regels om je basislijn eerlijk te houden:

Scan representatieve templates, niet je hele site. Test je homepage, een inhouds-/artikeltemplate, een product- of categoriepagina, een formulier (registratie, afrekenen, contact) en eventueel een geauthenticeerd dashboard. Eén template oplossen verhelpt meestal honderden pagina’s.
Test echte statussen, niet alleen de initiële lading. Open menu’s, klap accordeons uit, activeer modals en verstuur formulieren met fouten. Veel overtredingen verschijnen alleen in interactieve statussen.
Noteer de cijfers. Leg het aantal problemen vast per ernst en per succescriterium. Dit is je voor/na-benchmark en de basis van je remediatiebacklog.

Wees eerlijk over het plafond: geautomatiseerde tools detecteren betrouwbaar slechts 30–40% van de WCAG-problemen. Een schone geautomatiseerde scan is noodzakelijk, maar nooit voldoende voor een echte conformiteitsclaim.

Stap 3: Vul automatisering aan met een handmatige audit

De resterende 60–70% van de WCAG-criteria vereist menselijk oordeel. Brengt deze alt-tekst werkelijk de betekenis van de afbeelding over, of beschrijft hij alleen pixels? Is de lees- en focusvolgorde logisch? Vertellen foutmeldingen de gebruiker hoe te herstellen? Wordt een aangepaste dropdown correct aangekondigd, en kun je hem bereiken en bedienen met alleen een toetsenbord? Geen enkele engine kan dit betrouwbaar beantwoorden.

Een gestructureerde handmatige audit dekt doorgaans:

Bediening met alleen het toetsenbord — tab door elk interactief element; bevestig een zichtbare focusindicator, logische volgorde, geen vallen, en dat alles wat je met een muis kunt doen ook zonder kan.
Semantische structuur — koppen in een betekenisvolle hiërarchie, landmarks, lijsten opgemaakt als lijsten, tabellen met correcte koppen.
Formulieren — programmatische labels, gegroepeerde velden, duidelijke aanduiding van verplichte velden, en foutmeldingen gekoppeld aan de invoer die ze beschrijven.
Dynamische inhoud — modals die focus correct vasthouden en herstellen, live regions die updates aankondigen, en ARIA alleen gebruikt waar native HTML de klus niet kan klaren.
Inhoudskwaliteit — betekenisvolle linktekst, voldoende contrast in echte contexten, en inhoud die niet alleen op kleur of vorm vertrouwt.

Onze gids voor handmatige toegankelijkheidsaudits loopt de volledige methodologie door, en de veelvoorkomende toegankelijkheidsproblemen om te vermijden is een snelle checklist van de fouten die auditors het vaakst vinden. Als je het liever laat doen, voert het toegankelijkheidsadviesteam van QualiBooth deskundige handmatige audits uit tegen de WCAG 2.2 AA-criteria.

Stap 4: Prioriteer en remedieer

Een lange lijst met overtredingen is overweldigend totdat je hem ordent. Triageer door gebruikersimpact en bereik te combineren:

Blokkers eerst. Alles wat een taak onmogelijk maakt voor een groep gebruikers — toetsenbordvallen, een ontoegankelijke afrekenflow, een niet-gelabeld inlogformulier — gaat bovenaan, ongeacht hoeveel instanties er bestaan.
Dan hoogfrequente, sitebrede problemen. Een contrast- of focusprobleem in je header, footer of designsysteemcomponent vermenigvuldigt zich over elke pagina. Het één keer oplossen levert het grootste rendement op.
Dan pagina-specifieke en inhoudelijke problemen. Individuele ontbrekende alt-tekst, een enkele verkeerd gelabelde besturing, of een eenmalige kopstructuurfout.

Bij het remediëren los je de bron op, niet het symptoom. Geef de voorkeur aan native HTML-elementen boven met ARIA opgelapte <div>s; corrigeer het designsysteemcomponent in plaats van elke pagina die het gebruikt; en pak grondoorzaken aan in templates en gedeelde componenten zodat de oplossing schaalt. Scan opnieuw na elke batch zodat je de aantallen ziet dalen en geen regressies introduceert. Dit is ook het juiste moment om toegankelijkheid in je design tokens in te bakken — stel contrastveilige kleuren, een minimale doelgrootte van 24×24 px en zichtbare focusstijlen als standaard in zodat nieuw werk conform begint.

Een paar remediatiepatronen komen vaak genoeg terug om expliciet te benoemen:

Gebruik het platform. Een native <button>, <a href>, <input>, <select> en <dialog> komen gratis met toetsenbordgedrag, focusbeheer en een correcte toegankelijke naam. Grijp alleen naar ARIA om echte hiaten op te vullen — en onthoud de eerste regel van ARIA: gebruik geen ARIA als een native element volstaat.
Geef dingen programmatisch een naam. Elke besturing heeft een toegankelijke naam nodig uit een <label>, aria-label of aria-labelledby — niet alleen nabije visuele tekst. Knoppen met alleen een pictogram zijn de meest voorkomende overtreder.
Beheer focus bewust. Wanneer een modal opent, verplaats de focus erin, houd hem vast terwijl hij open is, en geef hem bij sluiten terug aan de trigger. Wanneer inhoud bijwerkt zonder navigatie, gebruik dan een live region zodat schermlezergebruikers horen wat er is veranderd.
Codeer betekenis niet alleen in kleur of vorm. Combineer kleur met tekst, pictogrammen of patronen zodat de informatie behouden blijft voor kleurenblinde en slechtziende gebruikers.

Volg remediatie in je gewone issue tracker, getagd per succescriterium, zodat toegankelijkheidswerk zichtbaar is naast al het andere in plaats van in een aparte spreadsheet te leven die veroudert.

Stap 5: Test met hulptechnologie en mensen met een beperking

Conformiteit gaat uiteindelijk over de vraag of echte mensen je site kunnen gebruiken. Twee validatielagen zijn hier van belang, en ze zijn niet uitwisselbaar.

Schermlezertesten. Verifieer je oplossingen tegen de hulptechnologie die mensen daadwerkelijk gebruiken: NVDA of JAWS met Chrome/Firefox op Windows, en VoiceOver met Safari op macOS en iOS. Luister naar accurate namen, correcte rollen, aangekondigde statuswijzigingen en een zinvolle leesvolgorde. Een schermlezerevaluatie geeft je een professionele controle over de belangrijkste combinaties als je team de ervaring mist.

Bruikbaarheidstesten met gebruikers met een beperking. Voldoen aan elk succescriterium is de ondergrens, niet de bovengrens — een site kan technisch conform zijn en toch frustrerend in gebruik. Het meest betrouwbare signaal komt van audits door mensen met een beperking, die testen met hun eigen hulptechnologie en gewoonten en barrières blootleggen die checklists missen. Dit is het verschil tussen voldoen aan de letter van de standaard en het leveren van echte digitale toegankelijkheid.

Stap 6: Documenteer conformiteit (verklaring en VPAT/ACR)

Zodra je hebt geremediëerd en gevalideerd, leg dan het resultaat vast. Documentatie is wat “we hebben het geprobeerd” verandert in een verdedigbare, communiceerbare claim.

Toegankelijkheidsverklaring. Een openbare pagina die je conformiteitsdoel vermeldt (bijv. WCAG 2.2 AA), beschrijft wat je hebt gedaan, eventuele bekende beperkingen opsomt, en gebruikers een manier biedt om problemen te melden. Veel regelgeving, waaronder de EAA, verwacht er een.
VPAT / Accessibility Conformance Report. Een ingevuld Voluntary Product Accessibility Template wordt een ACR — het standaard artefact dat inkoopteams en zakelijke kopers opvragen als bewijs. Onze gids over wat een VPAT/ACR is legt het document uit, en de dienst VPAT-rapporten produceert een accuraat, door audits onderbouwd rapport dat je kunt overhandigen aan klanten en juridische teams.

Schrijf deze op basis van bewijs uit je werkelijke auditresultaten, niet uit ambities. Een VPAT die de conformiteit overdrijft, is een verplichting, geen troef.

Stap 7: Behoud conformiteit in de loop van de tijd

Toegankelijkheid valt terug op het moment dat een site verandert — een nieuw component, een herontworpen formulier, een widget van derden of een inhoudsbewerking kan stilletjes barrières herintroduceren. Conformiteit is een staat die je behoudt, geen mijlpaal die je één keer passeert.

Bouw toegankelijkheid in je softwarelevenscyclus:

Shift left. Voeg geautomatiseerde controles toe aan je pipeline met CI/CD-toegankelijkheidsintegratie zodat overtredingen worden opgespoord bij pull requests, voordat ze live gaan — de goedkoopst mogelijke plek om ze op te lossen.
Monitor de productie. Plan terugkerende toegankelijkheidsaudits om regressies en inhoudsverloop op te sporen die controles vóór de release niet zien.
Versterk je team. Rust ontwerpers, ontwikkelaars en contentauteurs uit met een toegankelijkheidstoolkit en gedeelde standaarden zodat toegankelijkheid ieders standaard is, niet de bijzaak van een specialist.
Beheer op schaal. Voor grote of multi-site organisaties centraliseert een platform als Agora tracking, rapportage en remediatie over teams heen.

Fouten die conformiteitsinspanningen doen ontsporen

Teams die vastlopen, doen dat meestal om voorspelbare redenen. Let op deze:

Alleen op automatisering vertrouwen. Een groen geautomatiseerd rapport dekt slechts een derde van de criteria. Het behandelen als bewijs van conformiteit is de meest voorkomende — en juridisch meest riskante — fout.
Een overlay kopen. Overlays en “toegankelijkheidswidgets” beloven directe conformiteit door JavaScript te injecteren dat de pagina overschrijft. Ze repareren de onderliggende code niet, verstoren regelmatig de eigen hulptechnologie van gebruikers, en zijn genoemd in een groeiend aantal klachten. Ze zijn een snelweg naar risico, niet naar conformiteit.
Pagina’s repareren in plaats van systemen. Individuele pagina’s remediëren terwijl je het designsysteem kapot laat, betekent dat elke nieuwe pagina dezelfde defecten herintroduceert. Repareer eerst gedeelde componenten en templates.
Het als een eenmalig project behandelen. Zonder CI/CD-controles en terugkerende audits drijft een conforme site binnen een paar releasecycli weg uit conformiteit.
Echte gebruikers overslaan. Technische conformiteit zonder bruikbaarheidstesten kan gebruikers met een beperking nog steeds belemmeren om kerntaken te voltooien.

Het vermijden van deze fouten zorgt ervoor dat je investering niet wegvloeit op het moment dat het project “live gaat”.

Alles samenbrengen

Een realistisch pad naar WCAG 2.2 AA ziet er zo uit: leer de POUR-principes en het AA-doel, voer een geautomatiseerde basislijn uit, leg er een handmatige audit overheen, remedieer op impact en bereik, valideer met schermlezers en gebruikers met een beperking, documenteer je conformiteit in een verklaring en VPAT, en houd het vervolgens gezond met CI/CD-controles en terugkerende audits. Elke stap bouwt voort op de vorige — en niets ervan is afhankelijk van een overlay die de echte code toedekt.

Begin klein en bouw momentum op: scan deze week een handvol templates, repareer de contrast- en focusstijlen van je designsysteem, en zet één geautomatiseerde controle in je pipeline. Vanaf daar brengt de bovenstaande routekaart je de rest van de weg. Wanneer je klaar bent om te versnellen, verken dan onze prijzen, vraag een demo aan, of praat met een expert over een remediatieplan op maat van je stack.