Why accessibility overlays do not actually make sites WCAG-compliant

An accessibility overlay is a JavaScript widget you install on your site to "auto-fix" accessibility issues at runtime. The pitch is that one line of code makes your site WCAG-compliant and ADA-safe. The pitch is wrong. The accessibility community has been saying so for years, ADA lawsuits keep naming overlay-using sites as defendants, and in April 2025 the FTC fined accessiBe $1 million for marketing exactly that claim. This page is the long version, with sources.

What an accessibility overlay actually is

The major overlay vendors (accessiBe, UserWay, AudioEye, EqualWeb) sell the same product architecture with different marketing layers. You paste a snippet of JavaScript into your site's HTML, typically just before the closing </body> tag. When a visitor's browser loads the page, it loads the widget script. The script then runs:

• A scan of the rendered DOM (the live page in the visitor's browser) for accessibility issues the widget knows how to detect: missing alt text, low color contrast, missing form labels, unlabeled buttons, and similar surface-layer findings.
• An attempt to patch those issues in place by injecting ARIA attributes, modifying the contrast of style rules, generating alt text via AI, and similar interventions.
• A floating accessibility menu icon, usually anchored in a corner, that visitors can click to toggle features like high contrast, larger text, and link highlighting.

The overlay never touches the source code on your server. Your underlying HTML, CSS, and JavaScript stay exactly as they were. The "fix" exists only in the rendered DOM in the visitor's browser, only for as long as the widget is loaded, and only for the issues the widget's scanner knows how to detect.

Why this architecture fails in practice

1. The overlay may not load

An overlay is JavaScript. If the visitor's connection is slow, the widget loads late and the page is already usable (or broken) before it arrives. If the visitor uses a content blocker that recognizes the widget domain, the widget never loads at all. If the visitor has JavaScript disabled, same outcome. If the visitor uses an older assistive technology that interacts oddly with the widget's injected attributes, the experience can be worse than the unmodified page.

This is the part of overlay marketing that is technically true: "one line of code." It is also why the line of code is doing less than the marketing implies. The line of code loads a script. The script does what it can, when it can, on the visitor's machine.

2. The source code remains inaccessible

WCAG 2.1 conformance is, fundamentally, a property of the document you serve. If your HTML is missing alt text, has unlabeled form fields, uses color as the only indicator of meaning, or fails any of the other 50 Level A and AA criteria, those failures live in the file. An overlay paints over the rendered DOM in the visitor's browser; it does not edit the file. Search engines, AI scrapers, web archive crawlers, accessibility-testing pipelines, and any visitor whose browser does not run the overlay see the original document.

Section 508 and the European Accessibility Act both reference WCAG conformance directly. The DOJ's April 2024 Title II rule for state and local government web content also references WCAG 2.1 Level AA. Conformance is evaluated against the page, not against the rendered experience of a single visitor with a specific widget loaded.

3. Disabled users frequently report overlays make things worse

Over 700 accessibility professionals and disabled users have signed onto overlayfactsheet.com, a community-maintained document cataloging specific failure modes by vendor and by issue type. The complaints are not abstract. Screen-reader users report widgets that hijack keyboard focus, announce links twice, generate hallucinated alt text that misdescribes images, and re-label elements in ways that confuse the page's semantic structure.

The lawsuit data: overlays do not stop ADA complaints

UsableNet's 2024 digital accessibility lawsuit report counted 4,187 federal ADA Title III digital cases in 2024. Roughly a quarter of those targeted websites that had an accessibility tool installed at the time of filing. The widget did not, on its own, defeat the complaint. In some cases (Murphy v. UserWay is the canonical example) the widget itself was cited as a barrier.

The recurring pattern in the case data:

• A plaintiff or their attorney visits the site, often with a screen reader.
• They document specific WCAG failures the overlay did not catch or could not fix.
• A demand letter or a complaint follows.
• The defendant settles, usually by hiring an actual accessibility audit and remediation team to fix the source code.

If the end of the path is "hire someone to do a real audit and fix the source," the overlay subscription was a years-long detour. A 2024 class action against accessiBe (Tribeca Skin Care v. accessiBe) framed exactly that: plaintiffs argued they had paid accessiBe based on its compliance promises and were sued anyway.

The 2025 FTC action: regulators now treat compliance claims as enforceable claims

In January 2025 the FTC filed a proposed complaint against accessiBe alleging that the company's claim that its AI widget could make any website WCAG-compliant was false, misleading, or unsubstantiated. The complaint also addressed undisclosed astroturfing of third-party reviews. The final order took effect in April 2025. accessiBe paid $1 million. The order forbids accessiBe from making compliance claims without substantiating evidence and runs for 20 years.

The FTC also published a plain-English business-guidance post explaining the case to small business owners. The FTC's takeaway: AI compliance claims are still claims, and the website owner ends up holding the bag if they fail. Vendors selling into the overlay category should now assume the regulator is watching.

What accessibility experts recommend

The independent voices in the accessibility field are consistent. Karl Groves, Adrian Roselli, Lainey Feingold, the WebAIM team, and the National Federation of the Blind have all written publicly about why overlays are not a substitute for accessible code. Adrian Roselli, in particular, was sued by AudioEye for criticizing overlay products; AudioEye dropped the case in January 2024 and agreed to pay at least $10,000 to the NFB. The settlement language acknowledged Roselli's statements were expressions of opinion. The chilling-effect attempt did not succeed.

The mainstream expert recommendation is the same one it has been for a decade:

• Run a real audit against your actual source code, scoped to WCAG 2.1 Level A and AA.
• Fix the findings in code, either yourself, with a developer, or by feeding the findings to a capable LLM and reviewing the output.
• Re-test after fixes to confirm conformance.
• Keep the source code accessible going forward, treating it as part of your development process rather than as a one-time project.

When you might genuinely be stuck with an overlay

There are two narrow cases:

• You have no developer, no budget to hire one, and no ability to apply audit findings even with LLM assistance. If a fix list is unusable to you, a widget that changes the rendered experience is at least something. Be honest with yourself about the trade-off: the widget is comfort, not compliance.
• Your platform locks you out of the source. Some white-labeled SaaS storefronts and locked-down legacy CMS installs do not let you edit markup. If you cannot apply audit findings even when you have them, the overlay is the only intervention available.

Outside those two cases, a one-time accessibility audit (priced at about a quarter of one year of an overlay subscription) is the better buy.

What an honest audit gets you instead

Site Brace runs a one-time WCAG 2.1 Level AA audit of up to 25 pages for $149. The output is a written report that lists every violation found, references the specific WCAG criterion it failed, ranks the violations by severity, and gives you a copy-paste prompt block per finding so you (or Claude or GPT) can generate code-ready fixes. Twelve re-scans are included for 12 months so you can confirm the fixes worked. There is no widget on your site, no auto-renewal, and no compliance claim we cannot defend.

If you want continuous monitoring after the initial audit, Site Brace Watch ($129/year) runs weekly scans and emails you a diff when issues appear. Watch Pro ($399/year) runs daily and surfaces new issues within 24 hours.

For per-vendor side-by-side comparisons:

• accessiBe alternative (the FTC story, head to head)
• UserWay alternative (the Murphy class action, page-view pricing)
• AudioEye alternative (the Roselli SLAPP, the hybrid premium)
• EqualWeb alternative (the most honest overlay, still an overlay)

Start a Site Brace audit, $149

Site Brace is not affiliated with accessiBe, UserWay, AudioEye, EqualWeb, or the other vendors named on this page. Trademarks belong to their respective owners. Citations link to primary sources where available; secondary press coverage where the primary record is sealed (Murphy v. UserWay settlement terms) or is community documentation (overlayfactsheet.com). This page is opinion, informed by the cited sources, and is not legal advice. If you are facing a demand letter or active complaint, talk to an attorney. If we have something wrong, tell us and we will fix it. Last updated 2026-05-24.