Accessibility Overlays Are the CMP Mistake, Again

Every compliance market eventually produces the same product: a single script tag that promises to make a legal problem disappear. In consent it was the CMP that a client installed, never configured, and assumed was working while their pixels kept firing before consent. In accessibility it is the overlay — a JavaScript widget that injects a little accessibility icon in the corner of the page and claims to remediate the site at runtime.

The parallel is not a metaphor. It is the same mistake, and in 2025 it got expensive enough to be worth writing down.

What the FTC actually found

On 3 January 2025 the Federal Trade Commission announced an order against accessiBe, one of the largest overlay vendors, finalised in April 2025 with a $1 million payment. The company had marketed its accessWidget product as being able to make a website “automatically comply” with WCAG 2.1 level AA.

The FTC’s complaint alleged that it did not. The plug-in failed to make many basic components accessible — navigation menus, form fields and image descriptions, which is to say the parts of a website people actually use. The order also covered a second problem worth flagging to anyone who evaluates vendors by their reviews: the FTC alleged accessiBe formatted third-party articles and reviews to look like independent opinions while failing to disclose its material connections to the reviewers.

Note what the order is and is not. It is a deceptive-advertising action about the claims, not a ruling that overlays are illegal. But “a US federal agency fined the market leader a million dollars for saying this works” is a fact that belongs in any procurement conversation.

Overlays correlate with getting sued, not with not getting sued

The uncomfortable number comes from UsableNet’s 2025 midyear report: in the first half of 2025, 456 digital accessibility lawsuits — 22.6% of all filings — targeted websites that had an accessibility overlay installed. The equivalent figure for full-year 2024 was around 25%.

That is not proof the widget causes lawsuits, and the honest reading is partly selection effect: sites that know they have a problem are likelier to have bought something, and an overlay is a visible marker that makes a site easy to find and easy to plead. But it comprehensively kills the sales pitch. Whatever an overlay is buying, it is not immunity, and a fifth of the plaintiff market has learned to treat the icon as a target rather than a deterrent.

Why they fail, technically

An overlay runs as third-party JavaScript after the page loads and tries to infer, from the rendered DOM, what the developer meant. That framing explains every category of failure:

It cannot supply information that was never there

Alternative text describes intent — what an image means in context. A script can generate a plausible caption, but it cannot know that the photo on your checkout page is load-bearing rather than decorative. The same limit applies to form labels, heading structure and reading order: these encode authorial meaning, and inferring them is guessing.

It can conflict with the assistive tech it is meant to help

Screen reader users already have a working stack — the reader, its keyboard model, its shortcuts. An overlay that injects its own control panel and rebinds keys can introduce new barriers rather than remove them, which is precisely the complaint that shows up in the filings. This is why the accessibility community’s objection to overlays is not about product quality; it is that the intervention is unwanted by the users it names.

It leaves the source untouched

Runtime patching means the underlying markup still fails. Turn the script off, or load the page anywhere the script does not run, and the site is exactly as inaccessible as before. Auditors test the site, not the widget.

The consent parallel, made explicit

Readers of this site have run this argument already, in the other direction. A CMP does not block anything by itself; it fires events, and something else has to act on them. A banner does not create a legal basis; it records a choice, and your tags have to honour it. The vendor script is a component in a compliance process, never a substitute for one.

Accessibility works the same way. There is a real automated layer — scanning finds contrast failures, missing alt attributes, unlabelled inputs, empty links, and those categories genuinely make up the bulk of detected errors on the web. But scanning produces a list of defects to fix in your code. It does not produce compliance by existing, and neither does a widget.

And there is a specific overlap worth auditing today: your consent banner is a modal dialog shown to every first-time visitor, and if an overlay is the only thing standing between it and a keyboard user, you have two vendor scripts arguing about focus management on the highest-traffic component of your site.

What to do instead

1. Run an automated WCAG scan to get the machine-detectable failures. Free tools do this; it costs an afternoon.
2. Fix them in the source, in the codebase, where they will survive.
3. Test the paths that matter — navigation, forms, checkout, and your consent banner — with a keyboard only, then with a screen reader.
4. Publish an accessibility statement describing where you are, honestly.
5. Re-scan on deploy, because accessibility regresses like every other quality attribute.

If you want the longer version — what an automated scan can and cannot cover, where human review is mandatory, and what a defensible audit report contains — we wrote it up as what a WCAG audit actually covers on WCAG Inspector.

One script tag has never been a compliance programme. Scan what your site loads before consent with CookieInspector, and join the WCAG Inspector early-access waitlist to find the accessibility failures a widget was supposed to be hiding.