An accessibility overlay does not make your website accessible
An overlay is a single script that adds a menu of buttons and tries to correct the page from the outside. The faults sit in the code underneath, and they stay there.
What an accessibility overlay is
An accessibility overlay, also sold as an accessibility widget, is a piece of third-party JavaScript. You paste one line into your template, and from then on every page loads the script from the vendor's server. Your own HTML does not change.
The script does two things. It puts a button on the page that opens a menu where visitors can adjust the appearance, and it scans the page to automatically correct whatever it recognises as a fault.
That menu looks much the same on almost every site.
- More contrast, or inverted colours
- Larger text, more line spacing, more letter spacing
- A different typeface, often offered as help for dyslexia
- A larger cursor or a reading mask across the line
- Motion switched off, sometimes offered as an epilepsy-safe mode
What is sold, and what actually happens
The pitch is appealing: one line of code, no rebuild, done quickly and demonstrably compliant. That last part does not hold. A script dropped onto a finished page from the outside can only correct what it recognises, and it recognises only some of it.
The promises are generic enough to be made without reference to your site at all. Nobody has looked at your forms, your checkout or your documents.
| The promise | What happens |
|---|---|
| WCAG compliance from one line of code | One script loads. The structure of your page is exactly what it was before. |
| Automatic alt text for images | Image recognition guesses what is pictured, with no idea why the image is there. |
| Forms get labelled | Labels are inferred from nearby text, which often goes wrong on compound fields and error messages. |
| Full keyboard operation | Anything that looks clickable is given focus. The order and the logic of the page are untouched. |
| Visitors adjust it themselves in the menu | The menu works on this site only, and sits alongside the settings the visitor already has. |
Why the underlying problems remain
Accessibility lives in the structure of a page: what the elements are, what they are called, what order they come in and what happens when something goes wrong. An overlay sees that structure from the outside and has to guess at the intent behind it.
Generated alt text describes what is in the photo, not why the photo is on that page. In an online shop, that difference decides whether someone can place an order. The same goes for error messages, compound form fields and the order a screen reader reads the page in.
There is also a great deal the script simply cannot reach.
Practitioners and users reach the same verdict. In the WebAIM survey of web accessibility practitioners, 67 percent rated these tools not at all or not very effective; among respondents with disabilities that figure was 72 percent. Screen reader users report that an overlay hijacks their own settings and gets in the way of navigation, and browser extensions exist for no purpose other than switching overlays off.
- Text in PDF files, video without captions, and imagery drawn in canvas or SVG
- Third-party components, such as a payment screen or a booking module in an iframe
- Interfaces that rebuild themselves: a modern front end overwrites the injected corrections on the next render
- Anything the visitor does with JavaScript off, or with a blocker in front of it
The menu does what the browser already does
The buttons in the menu control things the operating system and the browser already offer: zoom, a contrast theme, a larger system font, reduced motion, a reading mode. Those settings work on every site, and most visitors have set them long ago.
A per-site menu works on that one site and sits alongside those settings, sometimes cutting straight across them. Anyone whose browser is already set to large text gains nothing from a button that does it again.
Some buttons also promise more than they deliver. A study of the best known dyslexia typeface found no difference in reading speed or accuracy for children with or without dyslexia, and participants chose that typeface less often than an ordinary one (Annals of Dyslexia, 2018).
For anyone using a screen reader the menu changes nothing at all. A screen reader reads the code, not the appearance.
Why it is not evidence of compliance
The Dutch implementation act for the European Accessibility Act sets requirements for the service itself. Since 28 June 2025 the ACM has supervised e-commerce services and electronic communications services, and the RDI the products covered by the directive; banking, e-books, audiovisual media and passenger transport each have their own regulator. They look at what a visitor gets, not at which tool you bought. Not every business is in scope: micro-enterprises providing a service are exempt, micro-enterprises placing a product on the market are not. Under the directive that means a business employing fewer than ten people that stays below the turnover or balance sheet threshold.
The standard behind the law is EN 301 549, which for web content points to WCAG 2.1 AA. We test against WCAG 2.2 AA, because the W3C states that content conforming to 2.2 also conforms to 2.1, which covers the legal floor. The law does allow exceptions, but they call for a file rather than a script: anyone invoking disproportionate burden must document that assessment and keep the results for five years, and service providers repeat the assessment at least every five years (Article 14 of Directive (EU) 2019/882). An overlay is not an assessment and produces no document.
The technical consensus points the same way. The W3C, the organisation behind WCAG, states that no tool alone can determine whether a site meets the standard: knowledgeable human evaluation is required. On 17 May 2023 the European umbrella body for disability organisations and the international professional association for accessibility jointly stated that overlays do not make a site accessible or compliant with European legislation, and are not an acceptable alternative to fixing the site itself.
In the United States this has been litigated for longer. An eyewear retailer running such a widget was sued by a blind customer, and the settlement committed it to removing the overlay and to manual remediation to WCAG 2.1 within two years. In early January 2025 the United States consumer protection regulator also announced a settlement with a vendor of one of these widgets over deceptive advertising: the marketing claimed one line of code would bring any site into WCAG compliance within two days, while navigation menus, form fields and image descriptions were left inaccessible. That settlement became final in April 2025.
What else the overlay brings to your site
To decide whether to act at all, an overlay checks whether assistive technology is running on the visitor's device. An outside party is therefore concluding that someone probably has a disability, without that visitor having clicked anything to say so.
Health data falls into the strictest category under the GDPR. Whether such detection belongs there depends on what is recorded and transmitted, and you cannot tell that from the outside of a third-party script. If an overlay also remembers the chosen setting across sites, something is stored on the visitor's device, and the rules on cookies and similar techniques apply.
Separately, you are taking on a script that runs on every page and that you do not control. If the vendor changes it, your site changes with it without you deploying anything, and load time goes up on exactly the pages where speed matters.
What does work
Repair at the source. The structure of the page, the names of the controls, the contrast, the focus order and the error messages are all changes in your own code. They work for everyone, including when no script loads.
The route there is the same every time.
We build the software we test with ourselves, so we know where the machine stops and the manual work starts. If an overlay is on your site today, we map what sits underneath it before anything comes off.
- Test the site against WCAG 2.2 AA, automated and by hand, with a screen reader and with the keyboard alone
- Repair the faults at the source, starting with the paths your revenue and your service delivery run through
- Record what was tested and what does not yet comply, so you hold a file rather than an assumption
- Build the check into the process, so a new page does not start from zero again
Sources
Frequently asked questions
Is there an accessibility widget that does work?
Not as a replacement for repair in the code. A widget can at best add something on top of a site that already complies, and even then the browser does most of it better. The question that counts is whether the page underneath is sound.
We already have an overlay installed. What should we do now?
Have the site tested with the script switched off first. That is the real state of things. You then repair the faults at the source and the script can go. Removing it before you know what sits underneath only makes matters less clear.
Does an overlay protect us against a complaint or against enforcement?
No. A regulator looks at what the visitor gets, not at which tool was bought. In March 2026 the ACM examined around a hundred of the largest Dutch online shops: at 61 percent it proved impossible to place an order using assistive technology, and a further 33 percent had serious problems.
What is the alternative to an overlay?
A test against WCAG 2.2 AA with a screen reader and with the keyboard alone, repair of the faults found in your own code, and a report of both. That holds up even when no script loads.
Can our accessibility statement list the overlay as a measure?
A statement should describe what was tested and what does not yet comply. An installed script is neither, so it adds nothing to the evidence.
Can you assess where our site stands?
Yes. We test the site and deliver a report of what does not comply and what is needed to repair it. All we need is access to the site.