Geschreven door: Doeke Norg

Freelance software-ontwikkelaar uit Vries. Schrijft over toegankelijkheid, AI en het web.

6 min lezen

Je gooit je site door een AI-tool, wacht een paar seconden, en de toegankelijkheidsproblemen zijn opgelost, toch? Was het maar zo simpel!

Ondertussen wordt dat wél verkocht. Scanners die een WCAG-audit automatiseren. Widgets die met één regel script beloven dat je site voldoet aan WCAG 2.1 AA. Met de European Accessibility Act die sinds 2025 ook voor webshops geldt, is de verleiding groot om voor de snelle oplossing te gaan.

Ik snap die verleiding overigens wel. Toegankelijk maken kost tijd, en AI is inmiddels overal zo goed in geworden dat je denkt dat dit ook zo'n klus is. En automatische tools helpen zeker, maar ze doen niet het werk dat nodig is om een site echt bruikbaar te maken voor iemand die een screenreader gebruikt, alleen het toetsenbord bedient, of geen fijne motoriek heeft voor een muis.

Hoe ver een scanner komt

Tools zoals axe, Lighthouse en de nieuwere AI-scanners zijn dus geen onzin. Ze controleren razendsnel dingen die met regels vast te stellen zijn:

  • ontbreekt een alt-attribuut?
  • is het contrast tussen tekst en achtergrond te laag?
  • mist een formulierveld een label?
  • springt de documentstructuur van een h2 naar een h4?

Dat soort dingen laten zich automatiseren, en daar zijn deze tools goed in. Maar de WCAG-richtlijnen bevatten, naast succescriteria die met een regel te toetsen zijn, óók succescriteria die een oordeel vragen. Een scanner ziet dát er een alt-attribuut staat, maar niet of de tekst erin klopt met wat de afbeelding op die plek betekent.

Hoeveel een scanner precies dekt, hangt af van hoe je telt. Van de 50 succescriteria in WCAG 2.1 AA laten er zich zo'n 16 automatisch toetsen. Deque, dat zelf zo'n scanner verkoopt, telt liever losse fouten in plaats van criteria en komt dan op 57%. Dat cijfer wordt trouwens flink omhooggetrokken door contrastfouten, die veel voorkomen en makkelijk te meten zijn. Zelfs dat gunstigste cijfer laat ruim 40% over voor iemand die kijkt, leest, en (handmatig) test.

Waarom één regel script niet volstaat

Overlay-widgets beloven het tegenovergestelde: plak één stukje JavaScript in je site, en je voldoet automatisch aan WCAG. Zo werkt toegankelijkheid alleen niet. Dat is niet alleen mijn mening: ruim duizend toegankelijkheidsexperts en gebruikers met een beperking, onder wie veel dagelijkse screenreader-gebruikers, ondertekenden de Overlay Fact Sheet. Daarin spreken ze af om overlays die automatische WCAG-conformiteit claimen nooit aan te raden.

Een overlay draait in de browser, ná het laden van je pagina. Hij scant de DOM en plakt er op dat moment ARIA-attributen, contrastaanpassingen en een bedieningsmenu overheen: een pleister op iets dat in de bron fout zit. Hij herstelt geen toetsenbordnavigatie die niet klopt met de leesvolgorde, en weet niet of een element een knop hoort te zijn of een link. Erger nog: omdat hij bovenop de pagina draait, botst hij soms met de screenreader die iemand al gebruikt. Extra elementen, verschoven focus, dubbele aankondigingen.

Iets is beter dan niets, zou je zeggen. Hier niet: een widget die de indruk wekt dat je site voldoet, terwijl bezoekers er nog steeds op vastlopen, dekt jou en niemand anders. Die schijnzekerheid is precies waarom toegankelijkheidsorganisaties en de overheid overlays niet als oplossing erkennen. DigiToegankelijk, het loket van het ministerie van Binnenlandse Zaken, is er kort over: met een overlay voldoe je niet aan de wet.

Waar AI wél goed in is

Dit is trouwens geen pleidooi tegen AI in dit werk. Ik gebruik het zelf, alleen ergens anders in het proces.

  • Alt-tekst voorstellen. Een model schrijft een eerste beschrijving van een afbeelding. Niet blind publiceren, want of een afbeelding decoratief is of juist inhoud toevoegt, weet het model niet. Maar als startpunt, in plaats van een leeg tekstveld, scheelt het tijd.
  • Het meetbare werk opsporen. Eén scan door je hele site geeft je in een paar minuten een lijst met contrastfouten, ontbrekende labels en scheve koppenstructuur, in plaats van dat je pagina voor pagina met de hand moet uitkammen.
  • ARIA-boilerplate schrijven, onder toezicht. Een aria-expanded toevoegen aan een uitklapmenu of een role op een custom component: AI genereert de code snel. Jij checkt of die klopt met hoe het component zich daadwerkelijk gedraagt.
  • Transcripties en ondertiteling als startpunt. Spraak-naar-tekst is inmiddels goed genoeg voor een eerste transcript. Nalezen op fouten en interpunctie blijft nodig, zeker bij vaktermen en namen.

In elk van die gevallen doet AI het eerste stuk werk. De controle blijft mensenwerk.

Wat alleen een mens kan beoordelen

De punten waar AI op vastloopt, zijn precies de punten waar toegankelijkheid om draait.

  • Is deze afbeelding decoratief, of vertelt hij iets dat nergens anders op de pagina staat?
  • Springt de focus door de sidebar voordat iemand bij de hoofdinhoud is?
  • Vertelt een linktekst als "lees meer" waar die link heen gaat, als je hem hoort tussen twintig andere links?
  • Komt de foutmelding van je formulier op het juiste moment binnen, of hoort iemand na het versturen gewoon stilte terwijl de melding allang op het scherm staat?

Een scanner ziet dát er een aria-live-regio bestaat. Hij hoort niet wanneer die afgaat. Geen van deze vragen beantwoord je door code te lezen; je beantwoordt ze door de pagina zelf te doorlopen, met alleen het toetsenbord en met VoiceOver of NVDA aan.

En dan is er een vraag die geen tool voor je beantwoordt: wat betekent dit succescriterium eigenlijk, in déze interface? WCAG 2.1 AA is een set richtlijnen, geen invuloefening. Twee sites kunnen allebei aan hetzelfde criterium voldoen en toch totaal anders aanvoelen voor iemand die ze daadwerkelijk gebruikt.

Wat je hiermee doet

Gebruik AI om te prioriteren. Een lijst van honderd bevindingen wordt hanteerbaar zodra je hem sorteert op impact voor bezoekers, in plaats van op de volgorde waarin de scanner ze toevallig tegenkwam. Verifieer daarna met een echte test, het liefst door iemand die deze hulpmiddelen dagelijks gebruikt en niet alleen voor een audit. Daarna is het gewoon werk: punt voor punt, testen, afvinken.

Heb je al een auditrapport met tientallen bevindingen liggen? Dan is dat rapport niet het eindpunt, maar de startlijst. Het oplossen ervan is veelal codewerk, geen configuratiescherm. Dat is ook precies waar ik bij help: niet nog een rapport, maar de bevindingen daadwerkelijk oplossen in de bestaande code van je site.

Zie je dit anders, of loop je zelf tegen een auditrapport aan dat blijft liggen? Ik hoor het graag: via de contactpagina of op LinkedIn.