An accessibility overlay is a JavaScript widget, usually shown as a floating icon, that a website adds with one line of code and that promises to make the site accessible or ADA compliant automatically. The short answer to whether they work is no. Overlays cannot fix the code problems that make up most of WCAG, they frequently interfere with the assistive technology people already use, sites running them are sued every month, and in April 2025 the Federal Trade Commission finalized a $1 million order against the largest vendor, accessiBe, for claiming its widget could make any website WCAG compliant. This article explains what overlays actually do, why the claims fail, what has happened in court and at the FTC, and what to do instead if you have one installed.

What an overlay does

Overlays fall into two categories, often bundled in the same product.

  • Display adjustments. A panel that lets a visitor change font size, contrast, spacing, cursor size, or pause animations. These are real features, but every one of them already exists in the visitor’s browser, operating system or assistive technology, usually configured once for every site rather than per widget. People who need them have them; a per-site panel that overrides their settings is a nuisance at best.
  • Automated “remediation.” A script that runs after the page loads and tries to patch the markup: guess alt text for images, add ARIA attributes to elements, relabel form fields, adjust heading levels. This is the part sold as compliance, and it is the part that fails.

Why automated remediation cannot deliver conformance

  • Most of WCAG is about meaning and behavior, not markup patterns. A script can add alt text to an image; it cannot know what the image is for. It can add a role to a div; it cannot make a custom dropdown open on Enter, announce its options, or return focus when closed. Keyboard operability, focus order, error handling, meaningful labels, captions, reading order and reflow are code and content decisions, and a script layered on top cannot change how the underlying components were built.
  • Guessing at scale produces wrong answers at scale. Machine-generated alt text is frequently inaccurate or generic, and wrong alt text is often worse than none, because it tells a screen reader user something false.
  • Injected ARIA breaks things that worked. When a script adds roles and labels to elements that already had correct semantics, screen readers can announce elements twice, announce the wrong thing, or lose keyboard behavior that native HTML provided. The people most likely to be harmed are exactly the people the overlay claims to help.
  • It runs after load, client-side, and depends on the visitor’s setup. Some assistive technology configurations never see the changes; some see them inconsistently. Conformance that exists only for some visitors some of the time is not conformance.
  • It fixes nothing in the source. The site’s actual code still fails every audit, every scanner run without the widget, and every test by a screen reader user who has blocked the overlay, which many do because of the interference described above.

None of this is controversial among practitioners. The Overlay Fact Sheet, an open letter signed by hundreds of accessibility professionals, including people who are blind or have other disabilities, has documented these problems since 2021 and asks site owners not to use overlays.

What the FTC decided

In January 2025 the Federal Trade Commission announced a proposed complaint and order against accessiBe, the largest overlay vendor. The FTC alleged that accessiBe claimed its accessWidget plug-in could make any website compliant with WCAG, and that it presented paid reviews and articles as independent endorsements without disclosing the financial relationships. The final order, approved April 22, 2025, requires accessiBe to pay $1 million and bars it from representing that an automated product can achieve WCAG compliance unless it has the evidence to support the claim, and from misrepresenting endorsements.

That order matters beyond one company. The central marketing claim of the overlay category, that a script makes a site compliant, is now a claim the FTC has formally found deceptive. Any vendor still making it, and any site owner repeating it in an accessibility statement or a VPAT, is standing on a position a federal regulator has rejected.

What the lawsuits show

  • Overlays do not stop demand letters. UsableNet’s 2025 midyear report found plaintiffs filed lawsuits against companies using accessibility widgets every month in the first half of 2025, including 132 in February alone, out of 2,019 total digital accessibility suits in the period. Plaintiffs’ firms can detect an overlay from the page source, and several treat it as evidence that the owner knew about accessibility and chose a shortcut.
  • Customers are now suing the vendors. BloomsyBox, a small online florist, bought a UserWay overlay subscription in July 2023 on the strength of the vendor’s promises, was sued by a disabled user in December 2023 anyway, and filed a class action against UserWay in federal court in Delaware. In February 2026 a magistrate judge recommended that the consumer fraud and negligent misrepresentation claims proceed. A dermatology practice has filed a similar class action against accessiBe.
  • The volume keeps rising. Digital accessibility lawsuits grew from roughly 4,200 in 2024 to over 5,000 in 2025, and overlays have not bent that curve.

If you have an overlay installed

  1. Do not treat it as compliance. Remove any statement on your site, in your accessibility statement, or in a conformance report that relies on it.
  2. Find out what the site actually does without it. Run the ten-check self-test with the overlay disabled, then get a proper accessibility audit. The audit tells you whether the failures are content, code or structural.
  3. Fix the code. Headings, labels, focus, keyboard support, component semantics and contrast are theme-level work. On a hand-coded site it is a scoped project; on a page-builder site it may be a rebuild, and the audit will say which.
  4. Remove the overlay once the fixes are in. Keeping it after remediation reintroduces the interference problems and keeps the lawsuit-scanner flag on your page.
  5. Publish an honest accessibility statement with your real conformance status and a working contact route, and keep the checklist in your publishing process.

What overlays are legitimately for

There is a narrow, honest use: as a temporary display-preference panel on a site that is already being remediated properly, for the minority of visitors who do not know their own browser settings. Even that is marginal, and it is never a substitute for the code work. If a vendor’s pitch includes the words “compliant,” “protected,” “guaranteed” or “lawsuit,” the pitch is the problem.

Frequently asked questions

Will an accessibility overlay protect me from an ADA lawsuit?

No. Sites running overlays are sued every month, and some plaintiffs’ firms specifically look for them. The only thing that reduces legal exposure is a site that actually conforms, documented by an audit and an accessibility statement.

Does the FTC order apply to all overlay vendors?

The order binds accessiBe. But the FTC’s finding, that claiming an automated product achieves WCAG compliance is deceptive without evidence, describes the category’s core claim, and other vendors are facing private lawsuits on the same theory.

Are overlays better than nothing?

For most sites, no, because of the interference with real assistive technology and the false sense of security. A site with an overlay and no code fixes is generally in a worse position than the same site with neither, and much worse than a site whose problems are being fixed in the code.

What should I use instead?

An audit, code-level remediation, a content checklist for editors, an accessibility statement with a contact route, and periodic re-testing. That is the whole list, and none of it is a widget.

Fix the site, not the symptom

Our ADA compliance services audit sites against WCAG 2.2 AA, remediate in the code, re-test, and give you a status you can publish truthfully. Every site we build is developed to WCAG 2.2 AA from the first template, with no overlay.

Book a Discovery Call →

or call 919-200-0201

Sources