Accessibility Overlays Are a Lawsuit Magnet, Not a Shield

The widget that was supposed to be a shield

The pitch is irresistible to a busy team: paste a single script tag, and an AI-powered overlay scans your site on load, "fixes" accessibility issues client-side, and shows a little wheelchair icon that opens a panel of toggles. Compliance, solved, for a monthly subscription and zero engineering time. It is the accessibility equivalent of a "this site is secure" badge.

The problem is that plaintiffs and their testers learned the pattern years ago, and the data now shows overlays attract litigation rather than deflect it. Per EcomBack's 2025 mid-year ADA report, 456 of the 2,014 federal website accessibility lawsuits filed in the first half of 2025,22.6%, were against sites that already had an accessibility overlay or widget installed. Nearly one in four suits hit a defendant who believed they had bought protection.

The FTC put a number on the deception

This is no longer just an advocacy-community complaint. In January 2025 the Federal Trade Commission fined accessiBe $1 million and barred it from making unsupported accessibility claims. Per the reporting compiled in RatedWithAI's post-FTC review, the FTC's complaint alleged that accessiBe deceptively marketed its accessWidget as able to make any website WCAG 2.1 AA compliant, and that the company funded and published reviews disguised as independent third-party assessments. The regulator's finding is blunt: the core marketing claim was not true.

That matters legally for every overlay customer. If a vendor's central promise, "this makes you compliant", has been formally found deceptive by a federal regulator, then relying on it as your compliance strategy is relying on a claim the government has already discredited. It is also discoverable: in litigation, "we installed a widget the FTC fined for false compliance claims" is not a defense, it is an admission.

Why overlays cannot fix what they promise to fix

The technical reason overlays fail is structural. An overlay is JavaScript that runs in the browser after the page loads. It can do superficial things, inject some ARIA attributes, restyle for contrast, add a font-size control. It cannot rebuild your information architecture, fix a heading hierarchy that is semantically wrong, restructure a form so labels are programmatically associated, or untangle a custom widget that traps keyboard focus. The disability-advocacy and accessibility-engineering communities documented this exhaustively in the overlay factsheet and the litigation analysis at Accessibility.Works. The recurring findings:

• Overlays often break assistive technology. Screen-reader users frequently report that overlays interfere with the AT they already use, creating new barriers, double-announcements, intercepted keystrokes, broken navigation.
• They address a small fraction of WCAG. The criteria an overlay can plausibly touch are a minority; the structural and content criteria that dominate real complaints are untouched.
• They depend on auto-detection that is wrong a lot. Auto-generated alt text and auto-inferred ARIA roles are frequently inaccurate, which can be worse than nothing because they assert false information to AT.
• They are bypassable and toggleable. A "fix" a user has to discover and enable is not a fix; the default experience, the one a plaintiff's tester records, is the broken one.

This is why, as TestParty's analysis of overlay litigation details, hundreds of businesses running the most popular overlay were sued anyway: the tester turns off the widget, or simply tests the real DOM the widget sits on, and the underlying violations are all still there.

What a tester actually does to your overlay

Understanding the test reveals why the widget provides no cover. A competent accessibility tester does not evaluate the overlay's marketing panel, they evaluate the page a real assistive-technology user experiences. The overlay's injected attributes are easy to detect and strip, and the underlying violations are then plainly visible.

# Detect an overlay, then audit the page WITHOUT it, 
# which is exactly what a plaintiff's tester does.
from playwright.sync_api import sync_playwright

OVERLAY_SIGNATURES = [
    'acsbapp.com', 'accessibe', 'userway', 'audioeye',
    'equalweb', 'accessiway', 'maxaccess'
]

with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.goto(url)

    # 1. Is an overlay present? (the beacon plaintiffs look for)
    scripts = page.eval_on_selector_all(
        'script[src]', 'els => els.map(e => e.src)')
    overlay = [s for s in scripts
               if any(sig in s.lower() for sig in OVERLAY_SIGNATURES)]
    print('Overlay detected:', overlay or 'none')

    # 2. Block the overlay and re-audit the REAL DOM
    page2 = browser.new_page()
    page2.route('**/*', lambda r: r.abort()
                if any(sig in r.request.url.lower()
                       for sig in OVERLAY_SIGNATURES) else r.continue_())
    page2.goto(url)
    # Run axe-core here against the un-overlaid page.
    # These are the violations your subscription did not fix.

The widget's presence is trivially detectable, and removing it exposes the unmodified markup. Everything the overlay claimed to fix, and could not structurally fix, is right there for the complaint.

The only thing that works is fixing the source

There is no shortcut around the underlying truth: accessibility is a property of your HTML, your components, and your content. It has to be built in, not bolted on. That sounds expensive compared to a script tag, but the work is bounded and largely machine-guided, because the violations that drive litigation are the machine-detectable ones, low contrast, missing alt text, unlabeled inputs, bad ARIA, keyboard traps, empty links. An automated scan against the real DOM enumerates them; engineers fix them in the source; a gate keeps them from coming back.

# The honest workflow overlays pretend to replace
# 1. Scan the real DOM (no overlay) against WCAG 2.1/2.2 AA
# 2. Triage by impact: fix critical + serious first
# 3. Fix in source: real alt text, <label for>, semantic
#    headings, focusable + escapable widgets, AA contrast tokens
# 4. Verify with a keyboard pass + a screen reader, not a panel
# 5. Gate CI so new violations cannot ship
- name: a11y gate (real DOM, no overlay)
  run: npx axe-ci --tags wcag2a, wcag2aa, wcag21aa, wcag22aa \
       --exit-on critical, serious

The bottom line

Accessibility overlays were sold as a way to make legal risk disappear with one line of code. The market has rendered its verdict: nearly a quarter of 2025 web accessibility lawsuits hit overlay users, and the FTC fined the category's flagship vendor $1 million for the very compliance claim that made overlays attractive. The widget is a beacon that advertises a broken site behind a cheap shortcut. Real remediation means scanning the underlying DOM, fixing the source code, verifying with actual assistive technology, and gating deploys so regressions cannot ship. It is more work than a script tag, and it is the only work that actually protects you.