Accessibility overlay: lost een AI-widget de EAA op?

Nee, een accessibility overlay lost de EAA niet op. Zo'n widget legt een laag over je website, maar repareert de code eronder niet. Ontbrekende labels, een rommelige kopstructuur of een checkout die niet met het toetsenbord werkt, blijven gewoon bestaan. De Europese Commissie noemt overlays geen passende oplossing, en accessiBe moest in 2025 na een schikking met de Amerikaanse FTC 1 miljoen dollar betalen vanwege misleidende claims. AI helpt wel bij scannen en eerste versies. Testen doet een mens.

Wat is een accessibility overlay?

Een accessibility overlay is een stukje JavaScript dat je in je website plakt. Bezoekers zien daarna een rond icoontje, vaak met een poppetje erin. Klik je erop, dan opent een menu waarmee je de tekst groter maakt, het contrast verhoogt, animaties stopt of een ander lettertype kiest. De meeste aanbieders zetten daar AI onder: die scant je pagina en past de code tijdens het laden aan, bijvoorbeeld door alt-teksten bij afbeeldingen te raden of labels aan knoppen toe te voegen.

De belofte klinkt aantrekkelijk. Eén regel code, een abonnement per maand, en je site zou toegankelijk zijn voor mensen met een beperking. Sinds de European Accessibility Act (EAA) geldt, wordt die belofte vaak gekoppeld aan de wet: installeer de widget en je voldoet. Bekende namen zijn accessiBe, UserWay en EqualWeb, en ook in WordPress vind je gratis widgetplugins.

Of de EAA voor jouw website geldt, en wat de wet precies vraagt, lees je in website toegankelijkheid verplicht. Kort: webshops en boekingssites die aan consumenten verkopen en geen micro-onderneming zijn, moeten voldoen aan WCAG 2.1 op niveau AA. De ACM verwacht dat WCAG 2.2 niveau AA in de loop van 2026 de maatstaf wordt. In dit artikel gaat het om de vraag of een overlay je daar brengt.

Waarom een accessibility overlay de EAA niet oplost

De kern is simpel. De wet vraagt dat je website zelf toegankelijk is. Een overlay verandert je website niet, hij legt er tijdens het laden een laag overheen. Wat in je thema, je formulieren en je checkout fout zit, blijft fout. Dat levert in de praktijk vier problemen op.

1. De belangrijkste fouten zitten in de structuur. Een formulierveld zonder label, een pop-up die je niet met Escape sluit, een menu dat alleen met de muis opent, een betaalstap die de focus kwijtraakt: dat zijn de dingen waardoor iemand met een schermlezer niet kan bestellen. Een script dat achteraf code bijplakt, raadt wat de bedoeling was. Soms klopt die gok, vaak niet, en soms maakt hij het erger.

2. AI kent je context niet. Een overlay die automatisch alt-teksten maakt, ziet "een vrouw achter een laptop". Hij weet niet dat het om je klantenservice gaat, of dat de foto alleen decoratie is en een lege alt-tekst hoort te krijgen. Wat een goede alt-tekst is, lees je in alt-tekst schrijven.

3. Bezoekers hebben hun eigen hulpmiddelen al. Iemand die slecht ziet, heeft zijn telefoon of computer allang ingesteld: grotere tekst, inzoomen, een schermlezer, een hoog contrast. Een widget met dezelfde knoppen voegt weinig toe. Het European Disability Forum (EDF) en de internationale beroepsvereniging IAAP waarschuwden in mei 2023 in een gezamenlijke verklaring dat overlays zulke hulpmiddelen kunnen hinderen en de instellingen van gebruikers kunnen overschrijven.

4. Privacy en snelheid. Volgens dezelfde verklaring herkennen sommige overlays of een bezoeker hulptechnologie gebruikt. Dat zegt iets over iemands beperking, en dat is gevoelige informatie. Daarnaast is elke widget een extra script dat je pagina trager maakt. Hoe je dat meet en oplost, lees je in WordPress website sneller maken.

Wat de Europese Commissie, de FTC en experts zeggen

Je hoeft mij niet op mijn woord te geloven. Dit zeggen de instanties die erover gaan:

• De Europese Commissie schrijft op haar pagina over webtoegankelijkheid dat overlays, en andere tools die er niet voor zorgen dat de website zelf aan de norm voldoet, geen passende oplossing zijn. Haar advies: los problemen op bij de bron.
• Het EDF en de IAAP stellen in hun verklaring dat een overlay een website niet toegankelijk maakt en niet laat voldoen aan de Europese wetgeving. Ze raden aan om experts en mensen met een beperking zelf te betrekken.
• De Amerikaanse FTC trof in januari 2025 een voorlopige schikking met accessiBe. Het bedrijf had volgens de FTC ten onrechte beweerd dat zijn AI-widget elke website aan WCAG kon laten voldoen, en had reviews als onafhankelijk gepresenteerd terwijl er een band was. In april 2025 werd de definitieve order goedgekeurd: accessiBe betaalt 1 miljoen dollar en mag die claim niet meer doen zonder bewijs.
• De ACM gaat op haar pagina over de EAA niet specifiek in op overlays. Wel is de maatstaf helder: je website en app moeten voldoen aan WCAG op niveau AA. Een audit of keurmerk is niet verplicht. Het gaat erom of consumenten je dienst echt kunnen gebruiken.

Belofte en werkelijkheid naast elkaar

Let ook op wat je zelf over je site zegt. Zet je in je toegankelijkheidsverklaring dat je site "volledig toegankelijk" is omdat de leverancier van de widget dat belooft, dan is dat jouw claim, niet die van de leverancier. Schrijf liever eerlijk op wat je hebt getest en wat nog niet werkt.

Waar AI wél helpt bij toegankelijkheid

AI is hier geen tegenstander. Het is alleen het verkeerde gereedschap om het werk mee over te slaan. Als hulp bij het echte werk scheelt het veel tijd. Zo zou ik de taken verdelen:

Welke AI-functies er in WordPress zitten en wat ze kosten, lees je in WordPress AI-plugin.

Een voorbeeldprompt om een formulier te laten nalopen. Je plakt de HTML van het formulier erbij, niet de gegevens van klanten:

Hieronder staat de HTML van het contactformulier op onze website. Controleer het op WCAG 2.2 niveau AA: labels, foutmeldingen, verplichte velden, toetsenbordvolgorde, focus en ARIA-attributen. Geef per probleem het succescriterium, waarom het een probleem is voor iemand met een schermlezer of zonder muis, en een voorstel voor de code. Noem alleen problemen die je echt in de code ziet. Zeg het als je iets niet kunt beoordelen zonder de pagina te zien.

Die laatste twee zinnen doen ertoe. Een taalmodel vult gaten graag op met algemene adviezen. Je wilt een lijst die over jouw code gaat.

Wat een mens moet testen

Een scanner vindt een deel van de problemen. Lighthouse zegt er in zijn eigen rapport bij dat automatische detectie maar een deel van de problemen vindt en dat handmatig testen nodig blijft. Ook het W3C, dat de WCAG-richtlijnen opstelt, zegt dat tools je helpen maar niet kunnen bepalen of een site toegankelijk is. Deze checks doe je dus zelf, of laat je doen door iemand die WCAG goed kent:

• Toetsenbord. Doorloop je belangrijkste route zonder muis: van de homepage naar een product, in de winkelwagen, door de checkout. Zie je steeds waar je bent?
• Schermlezer. Probeer dezelfde route met VoiceOver op een Mac of iPhone, of met het gratis NVDA op Windows. Hoor je wat elke knop doet?
• Inzoomen. Zoom in tot 200 en 400%. Valt er tekst weg of moet je opzij scrollen?
• Formulieren. Laat bewust een veld leeg. Zegt de foutmelding wat er mis is, en hoort een schermlezer die melding ook?
• Pop-ups en cookiebanner. Kun je de cookiebanner met het toetsenbord bedienen? Sluit een pop-up met Escape? Deze twee vergeet bijna iedereen, terwijl ze bovenop elke pagina staan.
• Betaalstap. Werkt de overgang naar je betaalprovider en terug, ook met een schermlezer?
• Echte gebruikers. Kun je iemand met een beperking vragen om een bestelling te doen, betaal die persoon dan voor zijn tijd. Dat leert je meer dan elke scan.

De volledige zelftest van een kwartier staat in het EAA-artikel dat ik bovenaan noemde. Wil je deze routes na elke update laten nalopen, ook met hulp van AI, lees dan website testen met AI.

Heb je al een overlay? Zo pak je het aan

Staat er al een widget op je site, dan hoef je niet in paniek te raken. Ga zo te werk:

1. Test met en zonder. Doe de toetsenbordtest en de schermlezertest één keer met de widget aan en één keer met de widget uit. Hindert hij, dan gaat hij er als eerste af.
2. Scan zonder widget. Draai Lighthouse of WAVE op een versie zonder overlay. Dat is wat je website echt doet.
3. Repareer bij de bron. Begin bij de onderdelen die elke pagina raken: kleuren en lettertypen in je thema, het menu, je formulieren en de checkout. In WordPress los je veel op in het thema en in de instellingen van je formulierplugin.
4. Pas je toegankelijkheidsverklaring aan. Beschrijf wat je hebt getest, wat werkt en wat nog niet, met een datum. Noem de widget niet als reden dat je voldoet.
5. Zeg het abonnement op zodra de site zelf op orde is, of houd alleen de functies die bezoekers aantoonbaar gebruiken en die niets in de weg zitten.
6. Borg het. Toegankelijkheid gaat stuk bij elke nieuwe plugin, pop-up of campagnepagina. Neem een korte toetsenbordtest op in je vaste controle na updates.

Bouw je een nieuwe site, neem toegankelijkheid dan vanaf het ontwerp mee. Contrast, koppen en formulieren achteraf repareren kost meer dan het meteen goed doen. Dat geldt ook voor sites die door een AI-bouwer zijn gemaakt: die zien er vaak netjes uit, maar missen labels of contrast.

Dit artikel is geen juridisch advies. Twijfel je of je onder de EAA valt of hoe je een probleem meldt, lees dan de uitleg van de ACM.

Conclusie: repareer de bron, gebruik AI als hulp

Een accessibility overlay is een pleister op de verkeerde plek. Hij verandert niets aan de code waar de echte problemen zitten, hij kan bezoekers met een schermlezer hinderen, en de Europese Commissie, het EDF en de FTC zijn er duidelijk over: een widget maakt je site niet toegankelijk. Zet AI in waar het goed in is, scannen, eerste alt-teksten, ondertitels en uitleg bij foutmeldingen, en laat een mens de routes testen waar je klanten echt op afhaken.

Laat je een site bouwen met AI, lees dan ook website laten maken door AI: daar staat waar zulke sites op toegankelijkheid tekortschieten. Wat een nieuwe WordPress-site of het onderhoud ervan bij mij kost, staat in de prijslijst.