Digitale toegankelijkheid: wat is verplicht?

Een toegankelijke website werkt voor bezoekers die een schermlezer gebruiken, alleen een toetsenbord bedienen, slecht contrast moeilijk kunnen lezen of moeite hebben met complexe taal. In de praktijk gaat het om alt-teksten bij afbeeldingen, voldoende kleurcontrast, een logische koppenstructuur, formulieren met duidelijke labels en knoppen die u zonder muis kunt bedienen.

De vier basisprincipes komen uit de internationale WCAG-richtlijnen: waarneembaar, bedienbaar, begrijpelijk en robuust. Wie aan WCAG niveau AA voldoet, dekt daarmee het overgrote deel van de wettelijke eisen af. De actuele versie is WCAG 2.2; die voegt onder meer criteria toe over focus, sleepbewegingen en aanraakdoelen die ook op mobiel zwaar wegen.

Toegankelijkheid is geen 'extra laag' bovenop design. Het is de vraag of iemand de taak kan afronden: een product bestellen, een afspraak boeken, een formulier versturen. Wat voor één groep een harde blokkade is, is voor anderen vaak gewoon slechte UX. Daarom loont het ook zonder wettelijke plicht.

Voor de overheid geldt het Besluit digitale toegankelijkheid overheid: websites en apps van rijksoverheid, provincies, gemeenten, waterschappen en publiekrechtelijke instellingen moeten toegankelijk zijn en een toegankelijkheidsverklaring publiceren. Digitoegankelijk is de centrale Nederlandse uitleg van die plicht.

Voor bedrijven is sinds 28 juni 2025 de European Accessibility Act (EAA) van kracht. De Rijksoverheid vat samen dat producten en diensten toegankelijker moeten zijn voor mensen met een beperking. De EAA raakt onder meer e-handelsdiensten: websites en apps waar consumenten iets kunnen kopen, boeken, reserveren of afsluiten.

Volgens de uitleg van toezichthouder ACM geldt de plicht voor bedrijven met 10 of meer medewerkers of een jaaromzet boven de 2 miljoen euro. Micro-ondernemingen die onder beide grenzen blijven, zijn uitgezonderd. Let op: een keurmerk of externe audit is niet wettelijk verplicht. De wet eist dat uw dienst toegankelijk is, niet dat u daar een certificaat voor hebt. Een onafhankelijke controle helpt wel om te weten waar u staat.

De technische meetlat is WCAG niveau AA. In Europa verwijst wetgeving via EN 301 549 naar die criteria: EN 301 549 is de bredere ICT-norm; voor webcontent zijn de WCAG-succescriteria het relevante deel. ACM hanteert WCAG AA als uitwerking van de eisen voor e-handelsdiensten en adviseert om alvast met WCAG 2.2 te werken.

Wie nu bouwt of verbouwt, kan het beste direct tegen WCAG 2.2 AA toetsen. De verschillen met 2.1 zijn beperkt, en de nieuwe criteria zijn vooral relevant voor mobiel gebruik en formulieren. Toetsen tegen een verouderde versie betekent later opnieuw werk.

Een toegankelijkheidsverklaring is voor overheden verplicht. Voor e-handelsdiensten onder de EAA geldt ook een verklaringsplicht: u legt uit hoe uw dienst aan de regels voldoet, op een plek die makkelijk vindbaar is. De verklaring vervangt geen echte toegankelijkheid; het is documentatie van de status, inclusief bekende tekortkomingen en een planning.

Begin met meten. Een geautomatiseerde scan laat binnen enkele minuten zien welke basisproblemen er spelen: ontbrekende alt-teksten, te laag contrast, lege links en knoppen, ontbrekende formulierlabels. Los eerst de fouten op die bezoekers direct blokkeren: onbedienbare navigatie, formulieren zonder labels en contrast onder de norm.

Plan daarna een handmatige check voor wat een machine niet kan beoordelen: de logica van foutmeldingen, de volgorde van toetsenbordnavigatie, of alt-teksten inhoudelijk kloppen, of een checkout met alleen toetsenbord te voltooien is. Laat iemand die niet bij de bouw betrokken is de kernflows doorlopen; blinde vlekken ontstaan sneller bij het eigen team.

Koppel toegankelijkheid aan uw releaseproces. Elke nieuwe pagina, cookie-banner of chatwidget kan nieuwe drempels introduceren. Neem checks op in pull requests of staging, en test periodiek opnieuw op productie. Zo blijft compliance geen eenmalig project voor 28 juni 2025, maar doorlopend onderhoud.

Toegankelijkheid is een van de vier pijlers van de WebYes-scan, naast snelheid, veiligheid en mobiel. We voeren geautomatiseerde controles uit op basis van WCAG 2.2 AA. Automatische checks vangen niet alles (zo'n 30 tot 50 procent van de criteria is machinaal toetsbaar), maar ze vinden wel de meest voorkomende problemen die bezoekers en toezichthouders als eerste zien.

De scan dekt maximaal zes pagina's per run. Het keurmerk vereist een gemiddelde score van minstens 80 én minstens 60 per pijler. Een site die 'bijna goed' scoort op toegankelijkheid maar onder de 60 zakt, krijgt geen GEKEURD-status, ook niet als de andere pijlers hoog zijn. Dat dwingt eerlijke prioriteit: a11y is geen bijzaak.

In het rapport ziet u per bevinding wat er mis is en hoe u het oplost, vaak met een link naar de herstelgids. Gebruik de scan als startpunt, niet als volledige WCAG-audit. Voor wettelijke zekerheid bij complexe flows blijft een handmatige audit met experts en gebruikers met een beperking de volgende stap.

Deel bevindingen niet als één lange lijst naar 'de developer'. Groepeer op eigenaarschap: content (alt-teksten, koppen), design (contrast, targetgrootte), engineering (labels, ARIA, toetsenbordvallen). Zo voorkomt u dat drie mensen dezelfde knopfixen en niemand de cookie-banner oppakt.

Koppel de WebYes-pijler toegankelijkheid aan uw sprintboard. Een score onder 60 is een blocker voor het keurmerk (gemiddelde ≥80 blijft daarnaast gelden). Plan herkeuring na fixes: gratis scan tot zes pagina's, full audit tot vijftien. Zonder herhaalde meting weet u niet of de pijler echt boven de vloer staat.

Houd naast de technische backlog een korte lijst handmatige checks bij (checkout met toetsenbord, schermlezer op formulieren). Die lijst is wat de wet in de praktijk van u vraagt bovenop automatische regels; de scan alleen is nooit het volledige bewijs. Deel die lijst met product owner én developer, zodat a11y niet alleen bij één specialist blijft hangen.