Accessibility overlays: the one-line fix that gets you sued

Short answer: no. An accessibility overlay, the script that drops a widget on an existing site, does not make it compliant. Independent testing finds overlays catch only a fraction of WCAG issues, a rising share of accessibility lawsuits name sites that have one installed, and the FTC has already fined a major overlay vendor for claiming otherwise. Real compliance is built into the components, not bolted on top.

What is an accessibility overlay, and why does it get sold as a fix?

An overlay is a single <script> tag a vendor sells as a shortcut to compliance. Once installed, it adds a floating widget with controls for font size, contrast, and a "pause animations" toggle, and it runs automated scripts that try to patch the page on the fly: guessing at alt text, adjusting color values, rewriting ARIA attributes it did not write.

The pitch is genuinely appealing: no code review, no designer time, and a badge that says the site is protected. What it leaves out is the part that matters: the widget is guessing at a site it did not build, on top of a page it cannot fully see.

How much of WCAG can an overlay actually detect?

Not most of it. Automated tools, including the scanners inside overlay widgets, can meaningfully test only a minority of WCAG success criteria on their own.

(Deque, Deque coverage report, to re-verify.)

The gap is structural, not a bug the next update fixes. A script can confirm an image has an alt attribute. It cannot tell whether that text describes the image, whether a custom widget responds to a keyboard, or whether reading order makes sense to a screen reader. Those are judgment calls, and judgment is what an overlay lacks. The WebAIM Million, an annual scan of one million home pages, still found detectable WCAG 2 failures on 95.9 percent of them in 2026, up from 94.8 percent the year before (WebAIM, to re-verify). Automated detection alone is not closing that gap. It is widening.

Are overlays actually named in accessibility lawsuits?

Yes, and the trend does not favor the widget. UsableNet's 2024 lawsuit report found that roughly a quarter of all digital accessibility lawsuits filed that year targeted websites with an overlay already installed, the overlay itself cited as a barrier rather than a fix (reported via secondary coverage of UsableNet's data, Accessibility.Works, to re-verify). UsableNet's own 2025 monitoring shows the pattern holding, with lawsuits mentioning accessibility widgets recorded every month: 85 in January, climbing to 132 in February, then settling between 99 and 119 a month through June (UsableNet, to re-verify).

A widget being present does not prove it caused the suit, or that sites without one are safer. Across two years of tracking, an overlay has not been a credible substitute for fixing the underlying code. Plaintiffs' firms test past it, and courts have not treated it as a shield.

What happened with the FTC and accessiBe?

This is the case that turned "overlays don't really work" from a community complaint into federal law. In January 2025, the Federal Trade Commission announced a complaint and proposed settlement against accessiBe, one of the best-known overlay vendors, finalized as an order on April 21, 2025. The claim: accessiBe's accessWidget was marketed as able to make any website WCAG compliant using AI, and that was false, failing to fix basic components like navigation menus, form fields, and image descriptions. The complaint further alleged accessiBe dressed up third-party endorsements to look independent without disclosing its own involvement. The company paid $1 million and is barred from claiming its product can make a site WCAG compliant, or keep it compliant over time, without evidence (FTC, to re-verify).

That is one of the category's largest vendors, found by a regulator to have oversold what the category can do. Treat that as the ceiling of what any overlay can honestly promise, not the floor.

So what actually works instead?

There is no shortcut. The fix is the same discipline that makes a site good in every other respect.

1. Start at the component, not the page. Every button, form field, menu, and modal gets built with correct semantic HTML and ARIA from the first pass, not patched afterward.
2. Make keyboard navigation a first-class path. A feature that only works with a mouse is not finished, regardless of its score.
3. Test with real assistive technology. A screen reader, a keyboard-only pass, and a person who relies on that technology daily catch what a scanner cannot.
4. Hold contrast and motion to the standard, not the eye test. WCAG 2.2 AA contrast ratios and prefers-reduced-motion support are checked, not assumed.
5. Re-test after every change. Compliance is a property of the current build, not a certificate earned once.

This is why Thabrew Effect treats accessibility as part of the same system as visibility and conversion, never a line item handed to a plugin. A component built accessibly the first time serves every visitor and every audit at once. A widget bolted on afterward serves a screenshot.

A plain note before the FAQ: none of this is legal advice. It summarizes publicly reported research and one federal enforcement action. Anyone facing an active accessibility complaint needs a lawyer, not a blog post.