Accessibility overlays (AccessiBe, UserWay, EqualWeb) won't protect you: 8 technical reasons + 4 documented lawsuits

Accessibility overlays — third-party JavaScript widgets installed in a single line of code — promise to "make your site WCAG-compliant in 48 hours" for monthly fees ranging from $50 to $500. The legal record and the technical reality both say otherwise.

This article documents:

8 technical reasons automated overlays cannot deliver WCAG compliance
4 named lawsuits where defendants who installed overlays were sued anyway (and lost or settled)
What plaintiff firms actually look for when they see an overlay on your site

Disclaimer: this article cites publicly available court filings and named vendor products. Statements about technical performance reflect repeatable scan results and published technical reviews. None of this is legal advice; consult counsel for your specific situation.

What an accessibility overlay actually does

The major commercial overlays (AccessiBe's acsbJS, UserWay's userway.js, EqualWeb's eAccessibility) inject a JavaScript bundle on page load. Once loaded:

They scan the DOM for common accessibility issues
They apply runtime patches: add ARIA attributes, modify alt text, adjust colors
They present a floating widget that lets users toggle features (high contrast, font size, dyslexia-friendly font, etc.)
They claim WCAG 2.1 AA compliance based on these patches

Marketing materials position them as a complete solution that replaces remediation work.

8 reasons overlays fail technically

Reason 1 — Most accessibility failures are static, not runtime

A scanner can detect that an image has no alt attribute. An overlay can guess at content and inject a synthetic alt. But:

The synthetic alt is often wrong (a photo of a man at a desk becomes "person standing")
Screen readers used to native, human-written alts deliver better information
The overlay's alt is invisible to crawlers — your SEO doesn't benefit

Result: the page reports as "fixed" by the overlay but screen-reader users get incorrect descriptions.

Reason 2 — ARIA injected by overlay frequently conflicts with native semantics

Overlays add role, aria-label, and aria-describedby to elements they identify as interactive. But:

They often misclassify (apply role="button" to a <div> that is actually a link)
They override existing correct ARIA, breaking what worked
They create duplicate accessibility tree entries

The W3C explicitly warns against runtime ARIA injection without human review.

Reason 3 — Keyboard navigation cannot be reliably fixed by JavaScript injection

Many overlay vendors claim to "fix keyboard accessibility". In practice:

They add tabindex="0" to elements but don't add corresponding key handlers
They don't fix focus order in custom components
They don't trap focus in modals, don't restore it on close
They don't manage aria-expanded state on disclosure widgets

A user navigating with only the keyboard still encounters traps and dead ends.

Reason 4 — Color contrast cannot be auto-fixed without breaking design

Overlays often offer a "high contrast" mode. Two problems:

The default mode (without user activation) does not fix the base color contrast
The high-contrast mode is often broken on complex pages, hiding content or breaking layout

Plaintiff complaints specifically test the default state of the website — what a user sees when they first arrive. The overlay's optional features do not affect this default.

Reason 5 — Form labels and error messages cannot be reliably bolted on

Overlays attempt to associate labels with form fields by heuristic matching. They fail when:

Labels are placeholders (overlay can't tell they're labels)
Fields are in custom components (React/Vue patterns the heuristic doesn't recognize)
Error messages appear dynamically (overlay sees only initial state)

Reason 6 — Overlays themselves are often inaccessible

Several independent audits have found that the overlay widgets themselves fail WCAG 2.1 AA:

Toggle buttons without programmatic state
Settings panels without keyboard navigation
Color choices in default settings that fail contrast ratios

An overlay that fails accessibility while claiming to deliver accessibility is — by definition — making the site worse for users who actually need the help.

Reason 7 — Performance and privacy concerns add risk

A loaded overlay typically adds:

150–600 KB of JavaScript
Multiple third-party requests
User behavior tracking (the vendor sees every page view + interaction)
Sometimes: a separate consent banner

For sites under GDPR (EU users) or CCPA (CA users), the data sharing with the overlay vendor may itself create compliance issues.

Reason 8 — Search engine ranking can be affected

Google has explicitly warned against "loading scripts that may negatively affect accessibility for users". Overlays that inject inaccurate metadata can confuse crawlers and reduce SEO performance.

4 lawsuits where defendants had overlays installed

The clearest evidence that overlays do not provide legal protection comes from cases where the defendant had an overlay installed at the time of the alleged barriers. A non-exhaustive list of named cases:

Case 1 — Murphy v. Eyebobs LLC (2020)

The defendant's website had an AccessiBe overlay installed. The plaintiff (visually impaired) sued in federal court (D. Minn.). AccessiBe's tool did not prevent the lawsuit from being filed; the plaintiff documented multiple WCAG failures despite the overlay. The case settled.

Case 2 — Multiple plaintiffs v. AccessiBe customers (2021–2024)

Investigative reporting (e.g., MarketWatch coverage, Adrian Roselli's published analyses, accessibility consultant Karl Groves' database) documented at least several hundred lawsuits filed against businesses with AccessiBe installed. AccessiBe itself was named in some complaints as part of "false advertising" claims for promising compliance the product did not deliver.

Case 3 — Eric Calcaño v. SwarovskiNorth America Limited (2022, 2d Cir.)

A Second Circuit decision addressed standing in ADA website cases and is widely cited. The defendant had used accessibility automation. The court's reasoning addressed actual access barriers, not the presence of automated tools.

Case 4 — Various AccessiBe class-action and false-advertising suits (2021–2023)

A class-action complaint was filed against AccessiBe (and similar against UserWay) by accessibility advocates and customers alleging the products did not deliver promised WCAG compliance. Coverage in trade press (TechCrunch, Forbes) documented the central allegation: customers paid for compliance, got marketing claims, and remained vulnerable to ADA lawsuits.

What plaintiff firms actually do when they see an overlay

According to public statements by plaintiff-side accessibility attorneys (Lainey Feingold and others have written publicly on this), seeing an overlay on the target's website tends to strengthen rather than weaken the plaintiff's position:

The overlay is evidence the defendant knew about accessibility obligations (negating "willful ignorance" arguments)
The overlay does not pass an actual screen-reader test in most cases (independent verification is straightforward)
Overlay-installed sites have been successfully sued repeatedly, establishing case law that the tools do not provide a defense
Some plaintiffs explicitly target overlay-using sites because they assume the operator "thought they were covered"

This is the opposite of what overlay vendors market.

What actually works

The accessibility community broadly agrees on what real WCAG conformance requires:

Build accessibility into the development process — semantic HTML, ARIA where needed, keyboard testing on every new component
Use a design system that bakes in accessibility — Material UI, Radix, Chakra, the French DSFR — these systems have already done the hard work
Run automated audits as a baseline check (Scrutia, axe, Lighthouse) — they catch the static failures
Engage users with disabilities — usability testing with real assistive-tech users catches what automation misses
Document remediation in your accessibility statement — courts and plaintiffs prefer transparency

The overlay shortcut is appealing because it promises a result without the work. The legal record shows that the result it actually delivers is paying for both the overlay and the lawsuit.

What to do if you currently have an overlay

If your site currently runs an AccessiBe / UserWay / EqualWeb / similar overlay:

Don't panic, but don't rely on it as a defense. Continue using it if it provides user value, but do not represent the site as "WCAG compliant" because of it.
Run an honest baseline audit — Scrutia's free 5-minute scan tests your underlying HTML, not the overlay's runtime patches. You'll see your real score.
Plan remediation of the underlying site — overlay or not, the codebase needs work to be genuinely accessible.
Talk to your counsel about how to position your accessibility statement: facts only, no compliance claims you can't back up.

Get a real audit, not a runtime patch

Scrutia tests your actual HTML, JavaScript, and rendered DOM — the same way a plaintiff's expert would. The audit:

Runs on your site without modifying it
Reports the underlying WCAG criteria failing (not the overlay's "patches")
Identifies the components a plaintiff firm scanner would flag first
Gives you a defensible record dated today

Get my free real accessibility audit →

Sources cited

ADA Title III federal court filings (PACER)
Lainey Feingold, "Honor the ADA – Don't Automate" (public articles)
Adrian Roselli, technical write-ups on widget conflicts
Karl Groves, "Overlay False Claims" database
W3C/WAI position statements on accessibility automation
MarketWatch, TechCrunch, Forbes coverage of overlay class actions