Wat is WCAG? De Web Content Accessibility Guidelines uitgelegd

Bijna 94,8% van de top één miljoen websites voldoet niet aan de basisnormen voor toegankelijkheid, met gemiddeld ongeveer 51 detecteerbare fouten per homepage. Ondertussen werden er in de Verenigde Staten in 2025 alleen al meer dan 5.100 ADA-rechtszaken over digitale toegankelijkheid aangespannen — en de juridische en reputatieschade van het negeren van toegankelijkheid neemt snel toe. Of je nu een e-commercestore, een SaaS-platform of een overheidsportaal beheert, één document staat centraal in bijna elk gesprek over toegankelijkheid: WCAG, de Web Content Accessibility Guidelines. Als je je ooit hebt afgevraagd wat WCAG nu precies is, waarom het bestaat en wat het concreet van je vraagt, dan is deze gids de uitleg in gewoon Engels waar je naar op zoek was.

De oorsprong van WCAG: waar de standaard vandaan komt

WCAG wordt gepubliceerd door het Web Accessibility Initiative (WAI), een programma van het World Wide Web Consortium (W3C) — hetzelfde internationale orgaan dat HTML, CSS en de meeste fundamentele webtechnologieën standaardiseert. De richtlijnen bestaan omdat het web, door zijn aard, de belofte van universele toegang in zich draagt. In de praktijk valt die belofte zonder bewuste ontwerpkeuzes uiteen voor miljoenen gebruikers.

De wortels van richtlijnen voor webtoegankelijkheid gaan terug tot 1995, toen Gregg Vanderheiden de eerste richtlijn voor webtoegankelijkheid opstelde, kort nadat Tim Berners-Lee toegankelijkheid voor mensen met een beperking noemde in een keynote op de Second International Conference on the World-Wide Web. In de jaren daarna ontstonden meer dan 38 verschillende richtlijnen voor webtoegang van diverse auteurs en organisaties, die uiteindelijk samenkwamen in de Unified Web Site Accessibility Guidelines aan de University of Wisconsin–Madison. Versie 8 van dat document, gepubliceerd in 1998, werd het startpunt voor WCAG 1.0, dat op 5 mei 1999 een officiële W3C Recommendation werd.

WCAG 2.0 verscheen in december 2008 en was belangrijk genoeg om in oktober 2012 te worden aangenomen als ISO-standaard — ISO/IEC 40500:2012. WCAG 2.1, gepubliceerd in juni 2018, breidde de 2.0-criteria uit met 17 nieuwe succescriteria gericht op mobiele bruikbaarheid, slechtziendheid en cognitieve toegankelijkheid. En de huidige versie, WCAG 2.2, werd op 5 oktober 2023 gepubliceerd als W3C Recommendation en is sindsdien goedgekeurd als ISO/IEC 40500:2025. W3C moedigt iedereen aan om de nieuwste versie te gebruiken, en met goede reden: content die voldoet aan WCAG 2.2 voldoet automatisch ook aan WCAG 2.1 en WCAG 2.0.

Het is de moeite waard om duidelijk te zijn over wat WCAG wel en niet is. Het is een technische standaard — een nauwkeurige, testbare specificatie die is ontwikkeld via een rigoureus W3C-proces met meerdere belanghebbenden, in samenwerking met individuen en organisaties over de hele wereld. Het is op zichzelf geen juridisch document, maar het is door verwijzing opgenomen in wetten en regelgeving in tientallen rechtsgebieden, waardoor het wereldwijd het feitelijke regelboek voor digitale toegankelijkheid is geworden.

Voor wie WCAG is ontworpen

WCAG pakt toegankelijkheidsbarrières aan voor mensen met een breed scala aan beperkingen, waaronder visuele, auditieve, fysieke, spraak-, cognitieve, taal-, leer- en neurologische beperkingen. Dat is een opmerkelijk brede groep. De Wereldgezondheidsorganisatie schat dat ongeveer 1,3 miljard mensen — grofweg 16% van de wereldbevolking — leven met een vorm van beperking die hun dagelijks leven en online toegang beïnvloedt. Elk van deze individuen kan op dit moment een potentiële klant, burger, student of werknemer zijn die probeert jouw website te gebruiken.

Maar de voordelen van WCAG-naleving reiken veel verder dan gebruikers met permanente beperkingen. De richtlijnen helpen ook oudere mensen met leeftijdsgebonden beperkingen — verminderd zicht, gehoorverlies, tragere motorische reacties — en verbeteren vaak de bruikbaarheid voor iedereen. Denk aan ondertiteling bij video: die is ontworpen voor dove gebruikers, maar komt ook ten goede aan kijkers in lawaaierige omgevingen, anderstaligen die willen meelezen en iedereen die liever leest dan luistert. Op vergelijkbare wijze helpt toetsenbordnavigatie power users die de muis traag vinden, en voldoende kleurcontrast helpt iedereen die met samengeknepen ogen naar een fel scherm buiten kijkt.

WCAG heeft ook betrekking op content op vrijwel elk type digitaal apparaat — desktops, laptops, kiosken en mobiele apparaten — en is bewust technologieneutraal. De succescriteria zijn geformuleerd als testbare uitspraken die geen specifieke technologie voorschrijven, waardoor ze relevant blijven naarmate HTML, JavaScript-frameworks en ondersteunende technologieën zich blijven ontwikkelen.

De POUR-principes: de conceptuele basis van WCAG

Elk succescriterium in WCAG — alle 86 in versie 2.2 — is ondergebracht onder vier principes op hoog niveau, gezamenlijk bekend onder het acroniem POUR. Deze principes vormen de conceptuele basis van de hele standaard. Ze begrijpen geeft je een intuïtief denkkader voor toegankelijkheid, nog voordat je een enkel specifiek criterium hebt gelezen.

• Perceivable (waarneembaar): Informatie en gebruikersinterfacecomponenten moeten op manieren aan gebruikers kunnen worden gepresenteerd die zij kunnen waarnemen. In de praktijk betekent dit dat content niet onzichtbaar mag zijn voor al iemands zintuigen. Als een gebruiker een afbeelding niet kan zien, moet er een tekstalternatief zijn dat hij via een schermlezer kan horen. Als een video een gesproken voice-over heeft, moeten er ondertitels zijn voor gebruikers die niet kunnen horen. Praktische vereisten onder dit principe zijn onder meer alt-tekst voor afbeeldingen, ondertiteling voor video, voldoende kleurcontrast tussen tekst en achtergrond en de mogelijkheid om tekst te vergroten zonder verlies van content.
• Operable (bedienbaar): Gebruikersinterfacecomponenten en navigatie moeten bedienbaar zijn. Geen enkele interactie mag invoer vereisen die een gebruiker niet kan uitvoeren. De meest voorkomende implicatie: alle functionaliteit moet met alleen een toetsenbord uitvoerbaar zijn, en niet alleen met een muis. Dit principe omvat ook het geven van voldoende tijd om content te lezen en ermee te interageren, het vermijden van content die aanvallen kan uitlokken, en het bieden van meerdere manieren om op een site te navigeren.
• Understandable (begrijpelijk): Informatie en de werking van de gebruikersinterface moeten begrijpelijk zijn. De content mag niet zo complex of verwarrend zijn dat gebruikers die niet kunnen gebruiken zoals bedoeld. Dit omvat leesbare taal (inclusief het in de code specificeren van de paginataal zodat schermlezers de juiste uitspraak gebruiken), voorspelbaar pagina­gedrag, duidelijke instructies en behulpzame foutmeldingen die gebruikers vertellen wat er misging en hoe ze het kunnen oplossen.
• Robust (robuust): Content moet robuust genoeg zijn om betrouwbaar te worden geïnterpreteerd door een grote verscheidenheid aan user agents, inclusief ondersteunende technologieën. Een robuuste site gebruikt schone, geldige semantische markup zodat schermlezers, brailleleesregels en andere ondersteunende hulpmiddelen de content correct kunnen ontleden en overbrengen — nu en naarmate de technologie zich ontwikkelt.

Zie POUR als vier filters waar elk element van je website doorheen moet. Als een component zelfs maar voor één van de vier filters faalt, is het waarschijnlijk een barrière voor sommige van je gebruikers.

Deze vier principes zijn stabiel gebleven in elke versie van WCAG — 2.0, 2.1 en 2.2 — ook al zijn de specifieke succescriteria eronder gegroeid en geëvolueerd. Die stabiliteit maakt van POUR een duurzaam perspectief om toegankelijkheid te beoordelen, ongeacht naar welke versie een bepaalde wet verwijst.

Conformatieniveaus: A, AA en AAA uitgelegd

Onder de vier POUR-principes vallen 13 richtlijnen, en onder die richtlijnen vallen de 86 testbare succescriteria — de daadwerkelijke, specifieke vereisten waaraan je moet voldoen om WCAG-conformiteit te claimen. Elk succescriterium is ingedeeld in één van drie conformatieniveaus.

• Niveau A is het minimum. Dit zijn de meest kritieke vereisten, die barrières vertegenwoordigen die zo ernstig zijn dat bepaalde gebruikers de content simpelweg helemaal niet kunnen benaderen. Voorbeelden zijn het bieden van tekstalternatieven voor niet-tekstuele content en ervoor zorgen dat alle functionaliteit met het toetsenbord toegankelijk is. Alleen niveau A is voor de meeste regelgeving niet voldoende, maar het niet halen ervan betekent een fundamentele mislukking.
• Niveau AA is de standaard op middelhoog niveau en degene die door de overgrote meerderheid van wetten en regels wereldwijd wordt vereist. Het voldoet aan alle A-criteria plus aanvullende vereisten, zoals het waarborgen van tekst-naar-achtergrondkleurcontrastverhoudingen van minimaal 4,5:1, het bieden van consistente navigatie op pagina’s en het aanbieden van ondertiteling voor vooraf opgenomen video. De meeste wereldwijde toegankelijkheidswetten — waaronder Section 508 in de VS, EN 301 549 in Europa en AODA in Ontario, Canada — vereisen conformiteit op niveau AA. Dit is het doel waar vrijwel elke organisatie prioriteit aan zou moeten geven.
• Niveau AAA is de hoogste standaard en omvat criteria die meer ambitieus dan universeel haalbaar zijn. W3C erkent zelf dat het niet mogelijk is om aan alle AAA-criteria te voldoen voor alle soorten content, dus deze criteria worden doorgaans niet als algemene beleidsvereiste gesteld. Voorbeelden zijn gebarentaaltolken voor alle audiocontent en een leesniveau dat niet moeilijker is dan lager secundair onderwijs.

Een belangrijk nuancepunt: conformatieniveaus zijn cumulatief. Het behalen van niveau AA betekent dat je ook aan alle A-criteria voldoet. Het behalen van niveau AAA betekent dat je ook aan A en AA voldoet. En cruciaal: conformiteit is alles-of-niets op elk niveau — je kunt geen AA-conformiteit claimen als zelfs maar één AA-criterium op een bepaalde pagina niet wordt gehaald.

Voor de meeste organisaties is WCAG 2.2 niveau AA het juiste doel. Het is het niveau dat in de wet is verankerd, het niveau dat rechtbanken als referentie gebruiken en het niveau dat je digitale ervaring daadwerkelijk openstelt voor het breedst mogelijke publiek.

Wat er veranderde in WCAG 2.2: de negen nieuwe succescriteria

WCAG 2.2, gepubliceerd in oktober 2023, voegde negen nieuwe succescriteria toe bovenop alles wat in WCAG 2.1 stond. Deze aanvullingen zijn ingegeven door doorlopend onderzoek naar waar gebruikers met een beperking — met name mensen met cognitieve beperkingen, motorische beperkingen en slechtziendheid — nog steeds vaak barrières tegenkwamen die in de eerdere richtlijnen niet voldoende werden aangepakt. WCAG 2.2 verwijdert of wijzigt geen bestaande WCAG 2.1-vereisten; het breidt ze alleen uit.

Van de negen nieuwe criteria vallen er vier onder niveau AA (en zijn dus juridisch relevant voor de meeste organisaties), twee onder niveau A en drie onder niveau AAA. Dit is wat elk criterium op AA-niveau en lager in de praktijk betekent:

• 2.4.11 Focus niet verduisterd — minimum (AA): Wanneer een toetsenbordgebruiker naar een interactief component navigeert, mag dat component niet volledig worden verborgen door andere, door de auteur gecreëerde content. Dit is een directe reactie op een veelvoorkomend modern ontwerppatroon: sticky headers, cookiebanners en vaste footers die over paginacontent schuiven en toetsenbordfocus stilletjes opslokken, waardoor gebruikers stranden zonder zichtbare indicatie van waar ze zich op de pagina bevinden.
• 2.5.7 Sleepbewegingen (AA): Elke functionaliteit die een sleepactie vereist — denk aan drag-and-drop-bestandsuploads, sorteerbare lijstitems of aangepaste sliders — moet een alternatief met één aanwijzer hebben dat geen slepen vereist. Voor een gebruiker met handtremoren of beperkte fijne motoriek kan het vrijwel onmogelijk zijn om continue druk uit te oefenen terwijl een aanwijzer over het scherm wordt bewogen. Het bieden van klik-om-te-selecteren-en-dan-klik-om-te-plaatsen-alternatieven, of op/neer-pijltjes op sorteerbare lijsten, lost dit op.
• 2.5.8 Doelgrootte — minimum (AA): Interactieve doelen zoals knoppen en links moeten minimaal 24×24 CSS-pixels zijn. Kleine tikdoelen zijn een goed gedocumenteerd bruikbaarheidsprobleem voor mobiele gebruikers met motorische beperkingen, oudere gebruikers en eigenlijk iedereen die op een telefoon typt terwijl hij multitaskt.
• 3.3.8 Toegankelijke authenticatie — minimum (AA): Authenticatieprocessen mogen gebruikers niet verplichten een cognitieve functietest op te lossen — zoals een traditionele CAPTCHA die tekenherkenning of het oplossen van puzzels vereist — tenzij er een alternatief wordt geboden. Dit is een belangrijk criterium voor elke site die standaard CAPTCHA-uitdagingen gebruikt in inlog- of registratieflows. Oplossingen zijn onder meer ondersteuning voor wachtwoordmanagers, e-mail- of sms-magic links, biometrische authenticatie of alternatieven op basis van objectherkenning.
• 3.2.6 Consistente hulp (A): Als een site een hulpmiddel aanbiedt (zoals een livechatknop, FAQ-link of ondersteuningsnummer) op meerdere pagina’s, moet dat hulpmiddel op dezelfde relatieve locatie op die pagina’s verschijnen. Gebruikers met cognitieve beperkingen die hulp nodig hebben, profiteren er sterk van als ze precies weten waar ze die kunnen vinden zonder elke keer te hoeven zoeken.
• 3.3.7 Redundante invoer (A): Informatie die eerder door een gebruiker is ingevoerd in een proces met meerdere stappen, moet automatisch worden ingevuld of selecteerbaar zijn in plaats van opnieuw te moeten worden ingevoerd. Dit vermindert frictie voor gebruikers met cognitieve of motorische beperkingen voor wie het invullen van formulieren bijzonder belastend is.

WCAG 2.2 heeft ook formeel één criterium uit 2.1 verwijderd: 4.1.1 Parsing. Dit criterium vereiste oorspronkelijk strikt geldige HTML om ervoor te zorgen dat ondersteunende technologieën markup correct konden ontleden. Het is buiten gebruik gesteld omdat moderne browsers en ondersteunende technologieën nu robuust omgaan met onjuiste markup via hun eigen foutcorrectiemechanismen, waardoor het criterium niet langer praktisch betekenisvol is voor toegankelijkheid.

WCAG en de wet: wat niet-naleving daadwerkelijk kost

WCAG is een technische standaard, geen wet. Maar het is verweven in het juridische weefsel van digitale toegankelijkheid in de meeste grote rechtsgebieden, wat betekent dat niet-conformiteit reële juridische risico’s met zich meebrengt.

In de Verenigde Staten, hoewel noch de ADA noch Section 508 WCAG 2.2 expliciet bij naam noemen, wordt WCAG consequent gebruikt als technische referentie in rechtszaken en handhaving. Het Department of Justice publiceerde in 2024 een Final Rule waarin WCAG 2.1 niveau AA werd vastgesteld als de officiële standaard voor naleving van Section 508 en ADA Title II voor overheden op staats- en lokaal niveau. ADA Title III — dat van toepassing is op public accommodations, waaronder de meeste private bedrijven die online actief zijn — wordt actief gehandhaafd via particuliere rechtszaken. In 2024 werden meer dan 4.000 ADA-rechtszaken met betrekking tot digitale eigendommen aangespannen bij federale en staatsrechtbanken, en de trend zette zich in 2025 stijgend voort. De civiele boetes voor een eerste ADA-overtreding werden in 2024 aangepast aan de inflatie en kunnen nu oplopen tot $115.231, oplopend tot $230.464 voor herhaalde overtredingen.

In Europa is het beeld even significant. De European Accessibility Act (EAA) werd op 28 juni 2025 juridisch van toepassing in EU-lidstaten en vereist dat websites, apps, e-books, e-commerceplatforms en pdf’s voldoen aan de WCAG 2.1 AA-criteria. De Europese norm EN 301 549 verwijst momenteel naar WCAG 2.1, en de volgende versie zal naar verwachting worden bijgewerkt naar WCAG 2.2. Voor organisaties met een aanwezigheid in Europa is naleving van de EAA niet langer optioneel.

De procescijfers laten ook een bijzonder pijnlijk patroon zien voor kleinere bedrijven: het idee dat klein blijven je veilig houdt, is een mythe. In 2023 was 77% van de ADA-rechtszaken over digitale toegankelijkheid gericht op bedrijven met minder dan $25 miljoen jaaromzet. E-commerce blijft met grote voorsprong de meest aangeklaagde sector. En cruciaal: één keer worden aangeklaagd biedt geen bescherming tegen opnieuw worden aangeklaagd — bijna de helft van alle rechtszaken over digitale toegankelijkheid in de afgelopen jaren was gericht op bedrijven die al minstens één eerdere claim hadden gehad.

De meest voorkomende WCAG-fouten (en hoe je ze herkent)

Aangezien bijna 95% van de websites niet voldoet aan de basisnormen voor toegankelijkheid, is het de moeite waard om te weten welke specifieke fouten het meest voorkomen. Het jaarlijkse WebAIM Million-rapport, dat de homepages van de top één miljoen websites onderzoekt, identificeert consequent hetzelfde handjevol problemen dat op de overgrote meerderheid van de pagina’s voorkomt:

• Laag kleurcontrast: Tekst met laag contrast trof 79,1% van de homepages in de analyse van 2025, met gemiddeld bijna 30 gevallen per pagina. Dit is tegelijk de meest voorkomende fout en een van de gemakkelijkste om met geautomatiseerde tools te detecteren. Tekst moet een contrastverhouding van minimaal 4,5:1 hebben ten opzichte van de achtergrond (3:1 voor grote tekst) om aan niveau AA te voldoen.
• Ontbrekende alternatieve tekst: Ontbrekende alt-tekst treft 55,5% van de pagina’s. Voor schermlezergebruikers die blind of slechtziend zijn, is een afbeelding zonder alt-tekst simpelweg onzichtbaar — de ondersteunende technologie slaat deze ofwel stilzwijgend over of leest een betekenisloze bestandsnaam voor. Gelinkte afbeeldingen zonder alt-tekst breken de navigatie volledig.
• Ontbrekende formulierlabels: Formuliervelden zonder gekoppelde labels betekenen dat een schermlezergebruiker niet kan achterhalen welke informatie in een veld moet worden ingevuld. Dit vormt een ondoordringbare barrière bij elk afreken-, registratie- of contactformulier.
• Lege links: Links zonder beschrijvende tekst — vaak links die alleen uit een pictogram bestaan of afbeeldingslinks zonder alt-tekst — laten toetsenbord- en schermlezergebruikers zonder context over waar de link naartoe gaat.
• Ontbrekende documenttaal: Het niet declareren van de taal van een pagina in de HTML betekent dat schermlezers content mogelijk voorlezen met de uitspraakregels van de verkeerde taal, waardoor de tekst onbegrijpelijk wordt.

Wat opvalt aan deze lijst, is dat geen van deze problemen exotische randgevallen zijn die geavanceerde engineering vereisen. Het zijn eenvoudige beslissingen in markup en ontwerp. Het feit dat ze op het overgrote deel van het web blijven bestaan, weerspiegelt een structurele kloof in hoe toegankelijkheid wel of niet wordt geïntegreerd in typische webontwikkelworkflows, niet een fundamentele technische barrière.

Hoe je WCAG-naleving als organisatie benadert

Om te komen van waar de meeste websites nu staan naar daadwerkelijke WCAG 2.2-naleving op niveau AA, is een systematische aanpak nodig. Het is geen eenmalig project — het is een doorlopend proces, omdat content verandert, frameworks worden bijgewerkt en componenten van derden worden vervangen. Zo structureer je de inspanning effectief.

Begin met een nulmeting. Voordat je iets kunt oplossen, moet je weten wat er kapot is. Geautomatiseerde scantools kunnen snel en op schaal een betekenisvolle subset van problemen identificeren — kleurcontrastproblemen, ontbrekende alt-tekst, ontbrekende formulierlabels. Maar geautomatiseerde tools hebben bekende beperkingen; ze kunnen ongeveer 30–40% van de WCAG-problemen detecteren. De rest vereist handmatige tests: je site alleen met een toetsenbord bedienen, testen met echte schermlezers zoals NVDA of JAWS op Windows en VoiceOver op macOS en iOS, en idealiter gebruikers met een beperking betrekken bij je testproces.

Prioriteer op impact en frequentie. Niet alle problemen zijn even zwaarwegend. Ontbrekende alt-tekst op een decoratief pictogram is veel minder kritisch dan een toetsenbordval waar een gebruiker niet uit een modaal dialoogvenster kan ontsnappen, of een inlogformulier dat volledig onbruikbaar is met een schermlezer. Richt je eerste remediatiesprint op de barrières die kerngebruikersreizen blokkeren — afrekenen, account aanmaken, zoeken, contact — voordat je cosmetische of minder impactvolle punten aanpakt.

Bouw toegankelijkheid in de ontwikkelworkflow in, niet erachteraan. Het duurste toegankelijkheidswerk is remediatie na livegang. Toegankelijkheidscontroles integreren in je design system, componentenbibliotheek, code review-proces en CI/CD-pijplijn zorgt ervoor dat problemen worden onderschept op het moment dat ze het goedkoopst zijn om op te lossen. Wijs een duidelijke eigenaar voor toegankelijkheid binnen je team aan en bied rolspecifieke training voor designers, developers en contentbeheerders.

Onderhoud een toegankelijkheidsverklaring. Het publiceren van een duidelijke, eerlijke toegankelijkheidsverklaring op je website — waarin je beschrijft welke standaard je nastreeft, hoe gebruikers barrières kunnen melden en hoe je op meldingen reageert — toont goede wil en is in sommige rechtsgebieden zelfs wettelijk verplicht, onder meer door de EU Web Accessibility Directive. Het creëert ook een feedbackloop die je helpt problemen te ontdekken die je in tests hebt gemist.

Gebruik overlay-widgets als aanvulling, niet als vervanging voor toegankelijkheid in de code. Overlay-widgets en SDK’s voor toegankelijkheid — waaronder Accsible — kunnen waardevolle tools zijn om gebruikersgestuurde voorkeuren aan te bieden, zoals tekstgrootte, contrastmodi en verbeteringen voor toetsenbordnavigatie. Maar de data is duidelijk: widgets die worden ingezet in plaats van fundamenteel toegankelijkheidswerk voorkomen geen rechtszaken. De juridische bescherming komt voort uit het feit dat je onderliggende code aan de WCAG-criteria voldoet, niet uit een widget die bovenop een ontoegankelijke basis is geïnstalleerd. Gebruik overlays als aanvulling op echte remediatie, niet als vervanging.

De weg vooruit: WCAG 3.0 aan de horizon

Terwijl organisaties nog bezig zijn WCAG 2.2 te halen, werkt de W3C Accessibility Guidelines Working Group aan WCAG 3.0, een ingrijpendere herstructurering van richtlijnen voor webtoegankelijkheid. De eerste publieke working draft werd begin 2021 uitgebracht en eind 2025 ondergaat de working draft nog steeds aanzienlijke ontwikkeling. Geen enkel onderdeel van WCAG 3.0 is al een officiële aanbeveling en er is geen vaste releasedatum vastgesteld.

Verwacht wordt dat WCAG 3.0 wezenlijk zal afwijken van het A/AA/AAA-conformiteitsmodel, een score-gebaseerde benadering zal introduceren en een breder scala aan digitale contenttypen zal omvatten, waaronder native mobiele applicaties en opkomende technologieën. Voor nu moeten organisaties zich richten op WCAG 2.2 niveau AA — dat is de huidige afdwingbare standaard en zal dat in de nabije toekomst blijven. Organisaties die nu een solide WCAG 2.2-basis leggen, zullen veel beter gepositioneerd zijn om zich aan te passen wanneer WCAG 3.0 uiteindelijk een aanbeveling wordt.

Belangrijkste punten

• WCAG 2.2 is de huidige wereldwijde standaard voor webtoegankelijkheid, gepubliceerd door W3C en goedgekeurd als ISO/IEC 40500:2025. Content die voldoet aan WCAG 2.2 voldoet automatisch aan 2.1 en 2.0 — richt je op de nieuwste versie.
• Niveau AA is het niveau dat ertoe doet. Vrijwel alle wereldwijde toegankelijkheidswetten — ADA, Section 508, EAA, EN 301 549, AODA — verwijzen naar WCAG-niveau AA als vereist conformatieniveau. Richt je inspanningen daar eerst op.
• De meest voorkomende fouten zijn oplosbaar. Laag kleurcontrast, ontbrekende alt-tekst, ontbrekende formulierlabels en lege links zijn verantwoordelijk voor het merendeel van de toegankelijkheidsfouten op het web. Deze zijn met relatief weinig moeite op te lossen en hebben grote impact.
• Geautomatiseerd testen is noodzakelijk maar niet voldoende. Tools kunnen ongeveer 30–40% van de WCAG-problemen detecteren. Combineer geautomatiseerde scans met toetsenbordtests, schermlezertests en idealiter gebruikerstests met mensen met een beperking om een volledig beeld te krijgen.
• Toegankelijkheid is een doorlopend proces, geen eenmalig project. Content verandert, componenten van derden veranderen en standaarden evolueren. Bouw toegankelijkheid in je ontwerp-, ontwikkel- en contentworkflows in, zodat deze continu wordt onderhouden en niet reactief wordt opgelost na een klacht of rechtszaak.