Do accessibility overlays make you compliant? What the FTC's accessiBe case means
In short: No. Overlay widgets such as accessiBe, UserWay and AudioEye adjust pages in the browser but leave the underlying code inaccessible, so they cannot reliably make a site WCAG or EAA compliant. In January 2025 accessiBe agreed to a $1 million settlement with the US FTC over misleading compliance claims. Real compliance means fixing the source code.
Overlay widgets promise instant accessibility compliance with a single line of code. Here's what they actually do, what they can't do, and why regulators have started pushing back.
What is an accessibility overlay?
An accessibility overlay is a third-party JavaScript widget — products like accessiBe, UserWay, and AudioEye are the best-known examples — that you add to your site with a single snippet of code. It runs in the browser and tries to adjust the page on the fly: adding ARIA attributes, generating alt text for images, changing contrast, or offering a floating toolbar with font-size and motion controls.
The pitch is appealing: no developer time, no code review, install once and (the marketing claims) become accessible and legally compliant. That promise is exactly what's drawn regulatory scrutiny.
What overlays can actually do
To be fair, overlays aren't useless. A well-built one can offer real user-facing conveniences: adjustable font size and line spacing, a reduced-motion toggle, a high-contrast mode, or a more visible focus outline. Some of these features genuinely help some users, and there's nothing wrong with offering them as an addition to an accessible site.
What they struggle with is anything that requires understanding the actual meaning and structure of your content — which is most of what WCAG conformance requires.
What overlays can't reliably do
Overlays run after your page has already loaded, patching the DOM at runtime rather than fixing the underlying markup. That approach breaks down on the things that matter most for real accessibility: auto-generated alt text for images is frequently wrong or meaningless — an image-recognition guess is not the same as a human describing what an image means in context; a broken heading hierarchy or missing document structure can't be reliably rebuilt by a script bolted on afterward; custom interactive widgets such as date pickers, dropdown menus, and modal dialogs that were built without keyboard support usually stay broken, because the overlay doesn't know your component's intended behavior; and the overlay's own DOM manipulation can conflict with screen readers, sometimes making a page harder to use than before the overlay was installed. This last point is one disability advocates and screen reader users have raised consistently and publicly for years.
None of this means the people building overlay products are acting in bad faith about the underlying technology — pattern-matching accessibility fixes at runtime is a genuinely hard problem. The issue is what gets claimed about the result.
The FTC's case against accessiBe
In January 2025, the U.S. Federal Trade Commission announced a settlement with accessiBe, one of the largest overlay vendors, requiring the company to pay $1 million. The FTC's action centered on allegations that accessiBe made deceptive claims about its overlay's ability to make websites compliant with accessibility standards and laws, and that it used fake or misleading customer reviews to support those claims.
The settlement is a regulatory signal, not a court ruling that overlays are illegal to use — but it confirms that marketing an overlay as a guarantee of legal compliance is the kind of claim a regulator will scrutinize. If you're evaluating any accessibility product, that's worth remembering: be skeptical of any vendor — overlay or otherwise — that promises full legal compliance from a single install.
Why fixing the source is the durable solution
WCAG conformance is a property of your actual content and code, not of a script that runs on top of it. A page with proper semantic HTML, real alt text, a logical heading structure, and accessible custom components works correctly across the full range of assistive technology combinations — different screen readers, different browsers, different user settings — because there's nothing fragile layered on top that can break or conflict.
Source-level fixes are also auditable: a developer, an auditor, or a regulator can inspect your actual markup and verify it. An overlay's runtime behavior is much harder to verify consistently, because it can behave differently depending on load timing, browser quirks, and how your page's JavaScript interacts with the overlay's own script.
The honest role for overlays
If you already like some of an overlay's user-preference features — font scaling, motion reduction, contrast toggles — there's a reasonable case for keeping them as an addition on top of a genuinely accessible, source-level-fixed site. What doesn't hold up is using an overlay in place of fixing your code, or marketing it as a compliance guarantee.
See what a code-level scan actually finds
Run a free automated WCAG scan of your site in about 20 seconds — the same kind of source-level check that an overlay can't replace.
Scan your site free →Are accessiBe, UserWay, and AudioEye illegal to use?
What's a real alternative to an overlay?
Can I use an overlay and fix my code at the same time?
Did the FTC say overlays don't work at all?
How do I know if my current overlay is 'enough'?
This article is general information, not legal advice. Whether any specific accessibility approach satisfies a particular law in your jurisdiction depends on your situation — consult a lawyer for a binding assessment.
EU (EAA) guide · Overlay vs. code fix · accessiBe alternative · UserWay alternative · AudioEye alternative · Methodology · European Accessibility Act (EAA) 2025: the complete guide · BFSG: what German businesses must do