Section 1
What the data actually shows
The case against overlays is not opinion; it's documented across litigation, regulators, professionals, and users. Businesses with overlays get sued anyway, at high rates. In 2024, accessibility widgets were explicitly cited as barriers (not solutions) in about 25% of all US digital accessibility lawsuits, over 1,000 cases, and businesses using overlays were sued at rates equal to or exceeding businesses with no accessibility solution at all (1). The widget that promised to prevent lawsuits is itself being named in them. A regulator fined the largest overlay vendor for false claims. The US Federal Trade Commission fined accessiBe $1 million for deceptive advertising about its product's ability to make websites compliant (1). When the FTC fines a compliance product for lying about compliance, the product's core promise is in serious doubt. Courts reject overlays as evidence of good faith. Courts have repeatedly rejected the argument that installing an overlay demonstrates a good-faith compliance effort, on consistent reasoning: software that claims to fix accessibility doesn't prove accessibility, and when expert testing shows the barriers remain, the marketing claims are legally irrelevant (1). Settlements routinely require removal of the overlay, in the LightHouse v. ADP settlement, the agreement explicitly stated that overlay solutions "will not be sufficient to achieve accessibility" (1). 700+ accessibility professionals signed a statement against them. The Overlay Fact Sheet, signed by more than 700 accessibility experts, including practitioners from Google, Microsoft, Apple, Shopify, and academics from MIT and Carnegie Mellon, declares that overlays "do not repair the underlying problems with inaccessible websites" (1). When the field's leading experts unite against a product, that's a signal worth heeding.
Section 2
Why overlays fail (the mechanism)
The reason overlays don't work is structural, not a matter of one bad vendor. An overlay is JavaScript that runs after your page loads and tries to mask accessibility problems on the surface, but the underlying code violations remain in your source, unfixed and still detectable (1). It's the difference between fixing a building's broken wheelchair ramp and putting up a sign that says "accessible building", the sign doesn't move anyone up the stairs. Worse, overlays often run after a screen reader has already processed the page, so the user with a disability never benefits from the attempted fix (1). And there's a cruel irony for the users overlays claim to serve. People with disabilities typically already have their own assistive tools, screen readers, browser settings, magnifiers, carefully tuned and learned over years. An overlay frequently interferes with those tools, forcing the user to abandon their familiar setup and learn a new, unfamiliar widget on every site that uses one (1). For many disabled users, overlays make the web harder, which is why disability advocates are among their fiercest critics. An overlay is a sign that says "accessible" bolted to the front of a building with no ramp. It reassures the owner, satisfies no regulator, and helps none of the people who actually needed the ramp, while the lawsuit-shaped truth sits unfixed in the source code behind it.
Section 3
What to do instead
The alternative is less seductive but actually works: fix the underlying code to meet WCAG 2.1 AA, the standard that the European Accessibility Act and US courts reference. That means a real audit (start with the plain-English checks in the companion piece, then a professional audit), genuine remediation of the source-code issues, and ongoing maintenance as the site changes. It's more work than pasting a widget, but it's the only approach that genuinely reduces legal risk, actually serves disabled users, and, as the conversion companion piece argues, improves usability for everyone. The appeal of overlays is the appeal of every too-good-to-be-true shortcut: they promise to make a real problem disappear for a small fee and no effort. The evidence, from courts, the FTC, 700+ experts, and disabled users themselves, is that they don't make the problem disappear; they hide it from the owner while leaving it fully present for users and litigators. The businesses relying on a widget for protection are, in many documented cases, exactly the businesses getting sued. (The "do real remediation instead" conclusion follows directly from the cited evidence.)
Section 4
Execute This With AI
Here is a workflow to assess your overlay situation and plan real remediation with any capable AI model. Step 1, Inputs. Note whether you currently use an overlay/widget (accessiBe, UserWay, EqualWeb, AudioEye, etc.), and run the plain-English accessibility checks from the companion piece. Step 2, Run the assessment prompt: You are an accessibility strategist (not a lawyer). I want an honest assessment of accessibility overlays vs. real remediation. Context: overlays mask issues with surface JavaScript without fixing source-code violations; they were cited as barriers in ~25% of 2024 US accessibility lawsuits; the FTC fined accessiBe $1M for false compliance claims; 700+ experts signed the Overlay Fact Sheet against them; courts reject them as good-faith evidence and settlements require removal. My situation: overlay installed? [which one / none]. Basic accessibility check results: [LIST what failed]. Do five things: 1. If I have an overlay, explain plainly what it is and isn't doing for me. 2. Assess whether it's likely reducing or increasing my real risk, and why. 3. Lay out the real-remediation path (audit → fix source → maintain) in steps a non-developer can follow. 4. Tell me what to ask an accessibility specialist or developer to actually fix. 5. Note where I should get legal/professional confirmation. Be honest, not reassuring; cite the consensus against overlays. Step 3, Reality check. "With my overlay active, navigate a key page as a screen-reader user. Does the overlay actually help, or does it get in the way? What's still broken underneath?" Tools and expected output. Any frontier chat model for assessment; an accessibility specialist for real remediation; an attorney for legal questions. Expect an honest overlay assessment, a risk verdict, a real-remediation path, and a specialist brief. The QA discipline: don't let a reassuring vendor pitch, or a reassuring AI summary, substitute for the documented expert consensus and litigation record against overlays. The fix that works is the unglamorous one: real remediation of the underlying code, confirmed by professional audit. The model can explain and plan; the actual accessibility comes from fixing the source, not masking it. The accessibility overlay is the rare product that can leave you worse off than doing nothing, sued at high rates, fined-vendor-backed, rejected by courts, condemned by 700+ experts, and actively obstructing the disabled users it claims to serve. Its only genuine product is the owner's false sense of security. Skip the widget and do the real work: audit your site, fix the underlying code to WCAG 2.1 AA, and maintain it. It's more effort than a line of JavaScript, and it's the only thing that actually protects you, serves your users, and, conveniently, makes your site better for everyone.
Section 5
Keep reading
Keep reading in the Accessibility & the EAA cluster and across the library: [The Business Case for Accessibility (Beyond Compliance)](/blog/the-business-case-for-accessibility-beyond-compliance), [Accessible Forms: Designing Lead Capture Everyone Can Complete](/blog/accessible-forms-designing-lead-capture-everyone-can-complete), [Is Your Service Business Exposed to the European Accessibility Act?](/blog/is-your-service-business-exposed-to-the-european-accessibility-act). Also relevant: [The Motion Accessibility Mistake That Excludes Real Customers](/blog/the-motion-accessibility-mistake-that-excludes-real-customers), [The Service-Business Website Priority Stack: What to Fix First When Everything Needs Work](/blog/the-service-business-website-priority-stack-what-to-fix-first-when-everything-needs-work), [What Is Conversion-First Web Design? A Plain-English Guide for Founders](/blog/what-is-conversion-first-web-design-a-plain-english-guide-for-founders).