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 are in the code of the page itself, and the script does not change that code.
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 has two functions. 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, or more space between lines and letters
- 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
Vendors promise that one line of code will quickly make a site demonstrably compliant, without any changes to the site itself. A script placed on a finished page from the outside, however, can only correct what it recognises, and it recognises only part of it.
The promises are made without anyone having looked at your forms or your checkout.
| The promise | What happens |
|---|---|
| WCAG compliance from one line of code | One script loads. The structure of your page does not change. |
| 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 depends on 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, but does not say why the photo is on the page. In an online store, that difference can decide whether someone is able to place an order.
Practitioners and users reach the same verdict. In the WebAIM survey of web accessibility practitioners from January 2021, 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 overrides their own settings and gets in the way of navigation, and browser extensions exist for no purpose other than switching overlays off.
The script also has no effect in a number of cases.
- 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
- Pages that rebuild their own content: when they do, the page overwrites the script's corrections
- Visitors who have switched off JavaScript or block the script with a content blocker
The menu does what the browser already does
The buttons in the menu offer functions the operating system and the browser already provide: zoom, a contrast theme, a larger system font, reduced motion, a reading mode. Those settings work on every site.
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 dyslexia typeface Dyslexie 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 has no effect, because a screen reader reads the code of the page and the menu only changes how the page looks.
Why it is not evidence of compliance
The accessibility act sets requirements for the service itself, and the ACM, which has supervised online stores since 28 June 2025, looks at what a visitor can do on the site, whichever tool you bought. The article on the accessibility act covers which businesses fall under the act and who supervises the other sectors.
The law does allow exceptions, but relying on one requires an assessment you carry out yourself: 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 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 in the settlement it committed to making its site accessible under 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 in a number of instances menus and images 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, some overlays check 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.
Under the GDPR, health data is a special category of personal data, subject to the strictest rules. Whether such detection falls into that category 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, data is stored on the visitor's device, and the rules on cookies and similar techniques apply.
Separately, every page loads a script that you do not control yourself. If the vendor changes the script, your site changes with it without you having changed anything. The script also increases load time, including on the pages where speed matters most.
What does work
You fix the faults in the source code of the site. You adjust the structure of the page, the names of the controls, the contrast, the focus order and the error messages in your own code, and those changes work for everyone, including when no script loads.
- Test the site against WCAG 2.2 AA, automated and by hand, with a screen reader and with the keyboard alone
- Repair the faults in the source code, starting with the parts customers use to order or get in touch
- Record what was tested and what does not yet comply
- Build the check into your regular workflow, so every new page is tested as well
Sources
Frequently asked questions
Is there an accessibility widget that does work?
A widget can at most offer extra display options on a site that already complies, and even then the browser does most of that better. The repair itself happens in the code.
We already have an overlay installed. What should we do now?
Have the site tested with the script switched off first. You then repair the faults in the source code and remove the script.
Does an overlay protect us against a complaint or against enforcement?
A regulator assesses what a visitor can do on the site, whichever tool was bought. As long as the faults remain in the code, an overlay does not protect you from that assessment.
What is the alternative to an overlay?
Have the site tested against WCAG 2.2 AA, with a screen reader and with the keyboard alone, and repair the faults in your own code.
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.