Accessibility overlays: what the record actually shows

On 3 January 2025 the United States Federal Trade Commission announced an order requiring accessiBe to pay one million dollars. The FTC's complaint alleged that accessiBe had falsely claimed its AI product, accessWidget, could make any website compliant with the Web Content Accessibility Guidelines, and that the company had deceptively presented paid promotional content as though it were independent third-party review. The Commission approved the order as final in April 2025.

The operative part is what the order forbids going forward. It bars accessiBe from representing that its automated products "can make any website WCAG-compliant or can ensure continued compliance with WCAG over time" without evidence to support the claim.

That is a regulator, on the record, telling an overlay vendor to stop saying the thing the entire category is sold on.

Separately, Level Access — a long-established accessibility firm that had publicly advised against overlays — announced in December 2023 that it would acquire UserWay for $98.7 million, completing the transaction in March 2024. A class action was filed against UserWay in 2024 alleging that compliance claims were exaggerated and that the widget made some sites harder to use. We have found no decision in that case and we are not going to characterise one; "filed" is the whole of what we can say.

The Overlay Fact Sheet is a community statement calling for the removal of accessibility overlays. At the time of checking it carried 1,031 signatories, including contributors and editors of the WCAG, ARIA and HTML specifications, accessibility staff at large technology companies, disability lawyers and screen reader developers.

Its central claim is not hedged:

No overlay product on the market can cause a website to become fully compliant with any existing accessibility standard.

This is not a marketing counter-position from a competing vendor. It is the considered view of the people who wrote the specifications the overlays claim to satisfy, alongside the people who build the assistive technology the overlays claim to help.

The part of the record that gets quoted least is the part that matters most. The Overlay Fact Sheet collects first-hand accounts from disabled people who encountered these widgets in the wild, and the complaints are consistent and specific rather than vague: focus jumping unpredictably around the page, the page suddenly flooded with headings that do not correspond to anything, sites becoming harder to use with the widget active than without it, and users resorting to blocking the scripts outright in order to get their work done.

Think about what that last behaviour means. A tool marketed as an accommodation has produced a population of people who install blockers to escape it. That is not a subtle signal.

Set the conduct aside for a moment and consider the engineering claim on its own terms, because the argument stands without any of the above.

An overlay is JavaScript running in the visitor's browser after your page has loaded. It reads the rendered document and guesses. Some of what it guesses is tractable — it can see that an img has no alt attribute. What it cannot do is know what the image is for. SC 1.1.1 Non-text Content does not ask for an attribute to be present; it asks for text that serves an equivalent purpose. A generated description of a photograph on a bakery's home page might be accurate and still be wrong, because the point of the image was "our shop, on the corner of Mill Street" and the machine said "a building".

The same gap runs through the specification. Automation cannot decide whether an image is decorative, which is a question about editorial intent. It cannot tell you whether a tab order matches the visual reading order in a way that makes sense to a human. It cannot judge whether a form's error message explains what to do. It cannot know whether colour is carrying information on its own, because it cannot know what the colour was supposed to mean. SC 1.3.1, SC 1.4.1, SC 2.4.3 and SC 3.3.1 all turn on meaning, and meaning is exactly what a script arriving after the fact does not have.

And an overlay operates at the worst possible layer. It cannot change your markup at the source; it can only intervene in the live document, which puts it in direct competition with the assistive technology already interpreting that document. When two systems try to describe the same page at once, the user is the one who arbitrates — usually by leaving.

We are not going to print a percentage for how much of WCAG automated testing catches. Figures circulate widely and we could not trace one to a methodology we could read, so it is not on this site. The structural point does not need a number.

The compliance promise is what sells overlays, and it is the part of the pitch that fails most completely.

No product makes a website compliant, because compliance is not a property a script can install. It is a legal determination about a specific site, measured against a specific obligation, in a specific jurisdiction. In the United States the Department of Justice's 2024 web rule sets WCAG 2.1 Level AA as the standard for state and local government entities under Title II; it does not establish a technical standard for private businesses under Title III at all. In the European Union the European Accessibility Act has applied through national measures since 28 June 2025. Neither instrument contains anything resembling a safe harbour for having installed a widget.

This is not legal advice and nothing on this site is. But we can say one thing without hesitation: a paid promise of legal protection is a promise the seller is in no position to make, and the FTC's January 2025 order is the clearest available evidence of what happens when that promise is examined.

If you have an overlay on your site now, this is the sequence we would work through.

1. Turn it off and use your own site with a keyboard only. You will learn more in twenty minutes than the widget's dashboard has told you in a year. The keyboard test walks through it.
2. Fix contrast first. It is the most common detected failure on the web, it is the cheapest to fix, and it is entirely within your control on every platform.
3. Write real alternative text for images that carry meaning, and empty alt attributes for the ones that do not. Where each builder hides the alt-text field covers the mechanics.
4. Label every form field properly. Placeholders are not labels.
5. Then choose your platform with your eyes open, which is what the assessment of ADA-compliant website builders is for.
6. If you have a real obligation, get real testing — by people who use assistive technology — and talk to a lawyer about the obligation itself.

Every one of those steps changes the underlying site. That is the difference. A repair at the source survives the next visitor, the next browser and the next assistive technology; a repair performed in the browser has to win an argument with the user's own software, every single time, on every single page load.