Accessibility overlays don't fix your site's code, so the barriers plaintiffs scan for are still there. What the FTC, the courts and practitioners say, and what to do instead.
Accessibility overlay widgets don't protect you from ADA lawsuits, because they don't change the code that causes accessibility barriers. A plaintiff's scanner reads your page the way a browser does, finds the same missing labels and broken buttons, and the widget's toolbar icon tells them you knew accessibility mattered. Fixing the source code is what actually removes the risk.
This is general information, not legal advice.
An overlay is a third-party script, usually one line pasted into your site header, that loads a toolbar and runs code in the visitor's browser. Vendors typically promise two things:
The first is harmless, though most people who need those settings already have them in their browser or operating system. The second is the problem. A script running after the page loads can't reliably guess what an unlabeled button does, what an image means, or how a custom dropdown should behave with a keyboard. And the underlying HTML that a crawler, a screen reader or an expert witness inspects stays the same.
The FTC. In January 2025 the US Federal Trade Commission announced an order requiring accessiBe, one of the largest overlay vendors, to pay $1 million. The FTC said the company misrepresented that its AI tool could make any website compliant with WCAG, and that it used reviews that looked independent but weren't. The order bars those claims unless they can be backed up.
The lawsuits. Businesses running overlays keep getting sued. A well-known example is Murphy v. Eyebobs (2021), filed against an eyewear retailer that already had an overlay installed. Lawsuit trackers such as UsableNet report hundreds of cases every year against sites that had a widget in place when they were sued.
The practitioners. The Overlay Fact Sheet is signed by hundreds of accessibility professionals, including people who use assistive technology every day. It asks site owners not to rely on overlays and explains how they can interfere with screen readers that users have already configured.
Three reasons come up again and again:
Run an automated audit to find the machine-detectable problems, then do a short manual pass: Tab through the page with a keyboard, zoom to 200%, and try key flows with VoiceOver or NVDA. A free scan is a good starting point, and our automated vs. manual testing guide explains what each method catches.
Most fixes are a line or two in a template or component:
<!-- An unlabeled search box (fails WCAG 1.3.1 and 4.1.2) -->
<input type="search" placeholder="Search">
<!-- Fixed: a real label, visually hidden if the design needs it -->
<label for="site-search" class="visually-hidden">Search products</label>
<input type="search" id="site-search" placeholder="Search">
.visually-hidden {
position: absolute;
width: 1px;
height: 1px;
margin: -1px;
overflow: hidden;
clip: rect(0 0 0 0);
white-space: nowrap;
}
If a third-party app or theme section causes the problem, report it to the vendor or replace it. You're responsible for the barrier either way.
An accessibility statement in your footer, with a real contact method, shows good faith and gives people a way to reach you before they reach a lawyer. See how to protect your website from an ADA lawsuit for what to put in it.
Every theme update, new app or marketing pop-up can introduce new problems. Re-test on a schedule and after releases.
Not necessarily. What matters is what the product claims and does. A small toolbar that only offers reading preferences and a "report a barrier" form, and doesn't claim to repair your site, is a convenience, not a compliance strategy. Accessibility Shield's optional ~5 KB toolbar works this way. It doesn't rewrite your page, and we tell customers plainly that remediation happens in their source code. Many sites are better served by a simple footer link to their accessibility statement and reporting form, with no widget at all.
Accessibility Shield runs axe-core in a real browser against your pages every week, shows each issue with the WCAG criterion and a code-level fix (plus a ready-made prompt for AI coding tools), and hosts your accessibility statement and barrier reporting form. It finds the problems overlays hide and helps you fix them for real. Try a free scan or see plans.
No. They don't change the underlying code, and no automated tool can make a site fully WCAG conformant on its own. The FTC took action against accessiBe in 2025 over exactly that kind of claim.
Yes. Sites using overlay products are sued regularly. Having a widget installed is not a defense if the barriers are still in your site's code.
If you keep it, don't treat it as your compliance plan, and test that it doesn't interfere with screen readers. Most teams are better off spending the subscription money on fixing the source code and testing regularly.
Fix the common automated issues yourself (contrast, alt text, labels, button names, page language), do a manual keyboard check, publish an accessibility statement, and monitor for regressions. For a small site, that costs far less than a typical overlay subscription.
Your site is ADA compliant only if it meets the technical requirements of WCAG 2.1 AA and you can show a good‑faith effort to keep it that way.
The European Accessibility Act has applied since June 2025. Here's whether your US SaaS or store is covered, who enforces it, how fines work, and a practical plan.
A structured, calm triage guide for business owners who received an ADA Title III accessibility demand letter. Learn how to verify claims and protect your business.