Why accessibility overlays don't work

Accessibility overlays don't work because they try to repair a website from the outside, in the visitor's browser, while the barriers live in the site's own code and content. They can change how a page looks, but they cannot reliably fix missing labels, broken keyboard flows or meaningless image descriptions. Regulators and lawsuit data point the same way.

What an overlay is

An overlay is a JavaScript snippet you add to your site. It usually does two things:

1. Adds a toolbar with options such as bigger text, high contrast, a dyslexia-friendly font, stopping animations or a reading mask.
2. Applies automatic "repairs", often marketed as AI: guessing alt text for images, adding ARIA attributes, changing focus behaviour.

The pitch is attractive: one line of code, a monthly fee, done.

Why the toolbar does not help much

People who need larger text, high contrast or reduced motion usually already have these settings — in their operating system, browser or assistive technology — and they use them on every site, not only yours. A separate panel on each website, all different, is something they have to discover and learn again. For screen reader users, the panel is one more thing to navigate past.

Why automatic repairs fall short

The hard accessibility problems are about meaning and behaviour:

• Alt text must say what matters about a product photo. An algorithm can guess "a shoe"; it cannot know that the important detail is "suede, burgundy, block heel".
• Form labels must match what the shop actually asks for. Guessing from placeholder text breaks when the placeholder is an example rather than a label.
• Keyboard flows depend on how the theme builds menus, filters and modals. Reordering focus from the outside often creates new traps.
• Custom widgets — size selectors, sliders, mini-carts — need correct roles and states. Adding ARIA without understanding the widget can make it worse: wrong ARIA tells assistive technology something false.

And because repairs are applied at runtime in the browser, the source code that other tools and many users see stays the same.

What the FTC decided

On 22 April 2025 the US Federal Trade Commission finalised an order against accessiBe, one of the best-known overlay vendors. The company had to pay $1 million and is prohibited from claiming that its automated products can make any website conform to WCAG unless it has evidence for that claim. The case is a reminder for every vendor in this space, including us: claims about accessibility must be true.

What lawsuit data shows

Overlays are often sold as protection against lawsuits. The numbers do not support that. UsableNet's report on 2025 found that websites using an overlay were still sued — at roughly 85 to 132 lawsuits per month in the US.

In the EU, the European Accessibility Act sets requirements for the service — the shop, the app, the checkout. Authorities inspect the service, not whether a widget is installed.

What the people affected say

Many disability advocates and accessibility professionals have publicly criticised overlays. When the people a product claims to serve are sceptical of it, that is worth taking seriously.

What works instead

The alternative is less magical but reliable:

1. Scan your site to find the issues automation can detect: missing alt attributes, unlabelled fields, buttons without names, low contrast, missing language. Our scanner does this weekly; it is an automated check, not a full audit, and not legal advice.
2. Fix them in the theme and content. Most issues sit in a handful of templates. Fix the product template once, and every product page improves.
3. Test what automation cannot: navigate the checkout with only a keyboard, check that focus is visible, read your alt texts aloud. Our WCAG 2.2 checklist guides you.
4. Train content editors to write alt text and use headings properly.
5. Monitor after every update, because themes and apps change.
6. Publish honest information about your accessibility and its known limitations. See the accessibility statement guide.

How to evaluate any accessibility vendor

Ask a few simple questions, of us as much as of anyone else:

• Does the product change your site's code and content, or only add a layer on top?
• Does the vendor say clearly what automated testing cannot find?
• Are the claims specific and verifiable, or do they promise legal outcomes?
• Can you export the findings and keep working on them without the vendor?

A trustworthy answer admits limits. Ours: our scanner finds a subset of WCAG 2.2 AA issues, explains them and tracks them over time — the fixing happens in your site.

"We already pay for an overlay. What now?"

You do not have to remove it today. But do not rely on it as your accessibility strategy. Scan your site with the overlay disabled if you can, so you see the real state of your code. Fix the issues, then decide whether the toolbar still adds anything for your visitors. Many businesses end up cancelling it once the underlying problems are gone.

The honest version of "quick"

Real accessibility work on a typical shop does not have to be a huge project. A first round — labels, contrast, button names, alt texts for the main products, keyboard access to the menu and checkout — mostly means fixing a handful of templates. It is not one line of code, but it lasts.

More: overlays vs real fixes, the 10 most common e-commerce errors, and for US sites, ADA website compliance. Start with a free check.