WordPress Toegankelijkheidsgids: WCAG 2.2 en de EU EAA

De kern: WCAG 2.2 AA is de technische standaard waar het meeste EU-toegankelijkheidsrecht naar verwijst, en komt neer op vier principes — waarneembaar, bedienbaar, begrijpelijk, robuust — maar in de praktijk falen de meeste WordPress-sites op een kleine, herhaalbare set problemen: kleurcontrast, ontbrekende alt-tekst, gaten in toetsenbordnavigatie en kapotte kopstructuur.

Waarom dit nu telt, niet ooit

De European Accessibility Act (Richtlijn (EU) 2019/882) geldt sinds 28 juni 2025 en vereist dat specifieke categorieën producten en diensten die aan EU-consumenten worden verkocht — waaronder e-commerce, bankieren, e-books, vervoersdiensten en telecommunicatie — voldoen aan toegankelijkheidsvereisten. Het is geen toekomstige deadline meer; het is al actieve wetgeving in EU-lidstaten.

De wet verwijst naar WCAG 2.2 op conformiteitsniveau AA als de praktische technische standaard die de meeste organisaties gebruiken om conformiteit aan te tonen, zelfs waar de EAA zelf in bredere juridische taal is geschreven. Dat maakt WCAG 2.2 AA het concrete doel om naartoe te werken, ongeacht of een specifieke site precies binnen het toepassingsgebied van de EAA valt.

Wat WCAG 2.2 AA daadwerkelijk vereist

WCAG organiseert zijn vereisten rond vier principes, gewoonlijk afgekort als POUR:

• Waarneembaar — content moet op manieren gepresenteerd kunnen worden die gebruikers kunnen waarnemen, waaronder alt-tekst voor afbeeldingen en voldoende kleurcontrast voor tekst.
• Bedienbaar — interface-onderdelen moeten alleen met het toetsenbord bruikbaar zijn, niet alleen met een muis, en gebruikers hebben genoeg tijd nodig om content te lezen en ermee te interacteren.
• Begrijpelijk — content en interfacegedrag moeten voorspelbaar en leesbaar zijn, inclusief duidelijke formulierlabels en consistente navigatie.
• Robuust — content moet betrouwbaar werken bij ondersteunende technologieën zoals schermlezers, wat sterk afhangt van schone, semantische HTML en correct ARIA-gebruik.

WCAG 2.2 voegde negen nieuwe succescriteria toe bovenop 2.1, waarvan er meerdere specifiek gericht zijn op mobiele en cognitieve toegankelijkheid — een minimale doelgrootte voor klikbare elementen, consistente plaatsing van hulpmechanismen over pagina's heen, en duidelijkere zichtbare focusindicatoren voor toetsenbordgebruikers.

De meest voorkomende WordPress-toegankelijkheidsfouten

We voerden een volledige axe-core-plus-Playwright-toegankelijkheidsaudit uit over deze site — 14 pagina's in zowel donkere als lichte modus — en het is een nuttig praktijkvoorbeeld van precies waar WordPress-sites doorgaans falen, aangezien de gevonden problemen volledig typisch waren in plaats van sitespecifiek.

• Kleurcontrast op decoratieve elementen. Categorielabels en gekleurde badges gebruikten ruwe merk-hexkleuren rechtstreeks als tekstkleur op getinte achtergronden, wat slechts ongeveer 3,3-4,0:1 haalde — onder het minimum van 4,5:1 voor normale tekst bij AA. De oplossing was het definiëren van aparte, doelgerichte "tekstveilige" kleurtokens in plaats van merkkleuren rechtstreeks als tekst te hergebruiken.
• Overgeslagen kopstructuur. Een overzichtspagina sprong van een H1 rechtstreeks naar H3-secties zonder H2 ertussen, wat visueel onzichtbaar is maar de logische documentstructuur breekt waarop schermlezergebruikers vertrouwen om te navigeren.
• Links die alleen door kleur worden onderscheiden. Inline links in langere tekstblokken hadden een andere kleur dan de omringende tekst maar waren niet onderstreept, wat niet voldoet aan de eis dat het onderscheid link-versus-tekst niet alleen mag afhangen van kleurwaarneming.
• Ontbrekende ARIA-attributen op aangepaste interactieve componenten. Een aangepast FAQ-accordeon had geen aria-expanded, aria-controls of role="region" — functioneel voor een muisgebruiker, maar dubbelzinnig voor een schermlezergebruiker zonder enig signaal over de status van het accordeon.

Geen van deze problemen werd opgemerkt door simpelweg naar de pagina te kijken — ze kwamen naar boven via gecombineerd geautomatiseerd scannen en handmatige beoordeling, het patroon dat het waard is om op elke WordPress-site te herhalen.

Een praktisch auditproces

Stap	Tool/methode	Spoort op
Geautomatiseerde scan	axe-core of WAVE browserextensie	Ontbrekende alt-tekst, contrastfouten, ontbrekende formulierlabels
Alleen-toetsenbordtest	Door de hele pagina tabben zonder muis	Kapotte focusvolgorde, onbereikbare interactieve elementen
Schermlezer-steekproef	VoiceOver (Mac) of NVDA (Windows)	Dubbelzinnige ARIA, verwarrende kopstructuur
Handmatige contrastcontrole	Browser-ontwikkelaarstools of een contrastchecker	Contrastproblemen in staten die geautomatiseerde tools missen (hover, focus)
Beide kleurmodi	Herhaal al het bovenstaande in donkere en lichte modus	Contrastregressies die alleen in één thema optreden

Veelvoorkomende WordPress-specifieke probleempunten

• Standaardinstellingen van thema's en page builders komen vaak met contrast- of kopstructuurproblemen die in templates zijn ingebakken, wat zich vervolgens herhaalt op elke pagina die dat template gebruikt.
• Door plugins toegevoegde widgets (sliders, accordeons, tabs) missen vaak de juiste ARIA-attributen, aangezien niet elke plugin-auteur test met ondersteunende technologie.
• Geüploade afbeeldingen zonder alt-tekst zijn een van de meest voorkomende en makkelijkst te verhelpen overtredingen — een mediabibliotheek in bulk controleren op ontbrekende alt-tekst vangt jarenlang opgebouwde gaten in één keer op. Erdo Image Optimizer bevat een ingebouwde audit die afbeeldingen zonder alt-tekst markeert in een hele mediabibliotheek, naast de bestandsgrootte-optimalisatie die we behandelen in onze afbeeldings-SEO-gids.
• Cookiebanners en modals worden vaak over het hoofd gezien bij toetsenbordfocustests, omdat ze worden toegevoegd nadat de hoofdpagina is geladen en gemakkelijk buiten de reguliere tabvolgorde van een site vallen.

Toegankelijkheid is onderhoud, geen eenmalig project

Een WCAG-audit lost op wat bestaat op het moment dat deze wordt uitgevoerd; elk nieuw blogbericht, elke nieuwe plugin en elke templatewijziging is een nieuwe kans om een probleem opnieuw te introduceren dat die audit al had gesloten. Toegankelijkheidscontroles behandelen als onderdeel van de reguliere publicatie- en ontwikkelworkflow — niet als een project dat één keer als afgerond wordt gemarkeerd — is wat een site zes maanden later nog conform houdt, niet alleen op de lanceringsdag.

Veelgemaakte fouten

• Alleen vertrouwen op een geautomatiseerde scanner, waardoor handmatige toetsenbord- en schermlezerproblemen worden gemist die geen enkele scanner kan beoordelen.
• Contrast alleen in lichte modus corrigeren, terwijl een site met een donkeremodus-schakelaar beide onafhankelijk moet controleren.
• Aannemen dat een populair thema of page builder standaard toegankelijk is, terwijl contrast- en kopproblemen op templateniveau zich herhalen op elke pagina die ermee is gebouwd.
• Een toegankelijkheidsaudit behandelen als een eenmalige taak in plaats van een doorlopende controle die wordt toegepast op nieuwe content en functies naarmate ze worden gepubliceerd.
• Alt-tekst overslaan bij nieuwe afbeeldingsuploads, zelfs nadat een bulkaudit de bestaande achterstand heeft opgelost, waardoor het gat zich stilletjes weer opbouwt.

Tot slot

Kortom, WCAG 2.2 AA-conformiteit voor een WordPress-site komt neer op een korte, herhaalbare lijst van praktijkfoutpunten — kleurcontrast, ontbrekende alt-tekst, toetsenbordnavigatie, kopstructuur en ARIA-gebruik bij aangepaste componenten — die alleen betrouwbaar wordt opgespoord door een combinatie van geautomatiseerd scannen en handmatig testen, en wordt onderhouden door een doorlopende gewoonte in plaats van een eenmalige audit. Nu de EU-toegankelijkheidswet al van kracht is in plaats van in afwachting, maakt het behandelen als routineonderhoud in plaats van een toekomstige taak het verschil tussen een conforme site en een aansprakelijkheidsrisico.