Lawsuit risk guide

Do Accessibility Overlays Prevent ADA Lawsuits?

Tens of thousands of websites pay monthly subscription fees for accessibility overlay products like accessiBe, UserWay, and AudioEye, expecting them to provide legal protection under the ADA. They don't. Here is what the evidence actually shows — and what does reduce your risk.

The short answer: No

Accessibility overlays do not reliably prevent ADA website lawsuits. Courts evaluate whether disabled users can actually access your site — not whether a particular product is installed. Multiple companies have been sued for ADA inaccessibility despite running overlay products. No overlay vendor's "compliance certificate" carries legal weight in court.

What accessibility overlays actually do

Accessibility overlays are JavaScript widgets that site owners add with a single script tag. When a visitor loads your page, the overlay's script runs after your HTML renders and attempts to:

  • Inject a floating toolbar that lets users increase font size, adjust contrast, or enable a simplified reading mode
  • Apply aria-label attributes to elements it detects are missing them
  • Attempt to increase color contrast on rendered text by modifying inline styles
  • Provide a keyboard navigation mode that tries to route focus through the page

The pitch is compelling: install one script tag, get automated compliance. The reality is more complicated — and the gap between what overlay vendors promise and what they deliver technically is the core of why they fail legally.

Why overlays don't provide legal protection

ADA Title III's standard for websites is not "did you buy an accessibility product." It is whether disabled individuals can access and use your site on substantially equal terms. Courts evaluate this through:

  • Expert witness testimony — accessibility specialists who test the site using actual screen readers (JAWS, NVDA, VoiceOver) and demonstrate specific failures
  • Plaintiff testimony — the disabled individual describing what they could not do on your site
  • WCAG 2.1 AA audit results — whether the site meets the technical criteria the DOJ and courts recognize as the accessibility standard for websites

None of these are satisfied by an overlay subscription. If your site's source HTML has missing alt text, broken form labels, or JavaScript components that trap keyboard focus, a JS widget running after page load does not make those failures disappear — it attempts to mask them, with inconsistent results.

The National Federation of the Blind (NFB) — the largest organization of blind Americans — has explicitly and publicly opposed several overlay products, describing them as inaccessible and harmful to screen reader users. Hundreds of working accessibility professionals signed the Overlay Fact Sheet documenting specific technical failures. When plaintiffs and their expert witnesses are drawing on this established body of critique, an overlay installation is not a defense — it can become a liability.

What overlays cannot fix

Overlays cannot reliably fix

  • Missing alt text — the overlay doesn't know what an image shows
  • Unlabeled form inputs — late ARIA injection often conflicts with how screen readers have already parsed the form
  • Broken keyboard navigation in custom JS components (tabs, modals, date pickers)
  • Focus trap bugs — when keyboard focus gets stuck inside a component
  • Missing heading hierarchy — headings skipped from h2 to h4
  • Incorrect or missing ARIA roles on dynamic content
  • Inaccessible PDFs, media without captions, or embedded third-party widgets

Overlays may help with

  • A visible font-size control for sighted users with low vision
  • A high-contrast toggle that some sighted users prefer
  • Line-spacing adjustments for users with dyslexia
  • A basic keyboard-navigation mode as a supplement — not a substitute — for real keyboard support

The core technical problem is timing: screen readers like JAWS and NVDA begin reading and building their internal model of the page as the DOM loads. Overlay scripts run after the page renders and attempt to patch attributes retroactively. This frequently creates conflicts — duplicate or misapplied ARIA labels, focus sequences that don't match the reader's existing model, and announcements that are late or out of order. Many screen reader users report that overlay products make sites harder to use, not easier.

The "compliance certificate" problem

Several overlay vendors offer a "compliance certificate," an AI-powered "certification," or a badge stating that your site has been assessed and is accessible. These carry no legal standing in any court or regulatory proceeding.

Courts and the DOJ measure accessibility against WCAG 2.1 AA — a specific set of testable success criteria published by the W3C. A vendor-issued certificate does not map to those criteria in a verifiable way. An expert witness on the opposing side will test your site with real assistive technology and document specific WCAG failures. That evidence outweighs a badge.

Additional risk: Displaying a "certified accessible" badge on a site that expert testing shows is not accessible to screen reader users can be characterized as misleading. It tells disabled visitors they can use your site when in practice they cannot — which courts may view as an aggravating factor rather than a mitigating one.

What actually reduces ADA lawsuit risk

The most defensible position against an ADA website lawsuit is documented, genuine, code-level remediation. Courts weight these factors favorably:

  • Fix foundational WCAG failures in source code — alt text on images, labels on form inputs, lang attribute on <html>, skip navigation link, heading hierarchy, keyboard navigation through all interactive elements.
  • Document the work — a git history with descriptive commit messages provides timestamped, verifiable evidence of good-faith remediation. Save before-and-after screenshots and audit results.
  • Run a real audit — not just automated — automated scanners (including ShipSafe and Axe) catch roughly 30–40% of WCAG criteria. Supplement with keyboard-only testing: can you Tab through every interactive element without getting trapped? Do modals close on Escape? Is focus managed when content changes?
  • Publish an accessibility statement — a page on your site stating your WCAG 2.1 AA commitment, a contact email for reporting accessibility issues, and the date of your last review. Courts and regulators view this as evidence of good faith.
  • Schedule quarterly checks — sites change. New pages, updated components, and CMS changes introduce new failures. Run ShipSafe and Axe every quarter and document results.
  • Consult an attorney if you receive a demand letter — do not send a written response before speaking to an ADA accessibility attorney. See the demand letter response guide for what to do first.

If you already have an overlay installed

Don't remove it immediately — that alone won't help, and the decision involves trade-offs worth considering carefully. Instead:

  1. Run an independent audit now. Use ShipSafe for a quick first look, then Axe DevTools for a full page scan, then do a keyboard-only walkthrough. Identify what actually fails.
  2. Fix the failures in your source code. This is the work the overlay was supposed to avoid — but there is no substitute for it.
  3. Do not rely on the overlay's compliance certificate as evidence of accessibility. Do not display it as a trust signal.
  4. Evaluate whether the overlay is causing screen reader conflicts. The easiest test: turn on VoiceOver (Mac, iPhone) and navigate your page with it. If the overlay's modifications create duplicate announcements or unexpected focus jumps, it is actively making your site harder to use for blind visitors.
Practical note: If the overlay is adding user-preference controls (font size, line spacing) that you want to keep for sighted users with visual impairments, that's a valid reason to keep it as a supplemental layer — as long as your underlying code is also accessible. The mistake is treating the overlay as the accessibility solution rather than an optional preference layer on top of real remediation.

Verify your site with ShipSafe

ShipSafe scans your page's live HTML for the WCAG failures that appear most frequently in ADA demand letters — missing lang attribute, unlabeled form inputs, images without alt text, contrast failures, and missing skip navigation. It runs in your browser and checks your live site directly — which means it sees your page the way automated plaintiff scanners do, with or without any overlay running.

Check my site with ShipSafe →

More ShipSafe guides:

Frequently asked questions

Do accessibility overlays prevent ADA lawsuits?

No. Overlays do not reliably prevent ADA website lawsuits. Courts evaluate whether disabled users can actually access and use your site — not whether a product is installed. The standard is WCAG 2.1 AA measured by testing with real assistive technology. Multiple companies have been sued despite having overlay products running on their sites.

Is an accessibility overlay compliance certificate legally valid?

No. Vendor-issued certificates have no legal standing. Courts and the DOJ measure accessibility against the WCAG 2.1 AA technical criteria, not against a certificate from the product vendor. An expert witness testing your site with a screen reader will produce evidence that outweighs any badge. Displaying an inaccurate compliance badge on an inaccessible site may be viewed as an aggravating factor in litigation.

Why do screen reader users say overlays make sites harder to use?

Screen readers begin building their model of the page as the DOM loads. Overlay scripts run after the page renders and patch attributes retroactively. This causes timing conflicts: late or duplicate ARIA announcements, focus sequences that don't match the reader's internal model, and modifications that contradict the reader's expectations. The National Federation of the Blind and hundreds of accessibility professionals have documented these issues publicly.

What do overlays actually fix vs. what they miss?

Overlays can sometimes provide useful visual preference controls (font size, line spacing, high contrast) for sighted users with some visual or cognitive impairments. They cannot reliably fix the foundational issues that appear in ADA lawsuits: missing image alt text, unlabeled form inputs, broken keyboard navigation in custom components, focus trap bugs, or missing heading structure. Those require code-level changes.

Does the DOJ recognize overlays as a compliance method?

No. The DOJ's April 2024 final rule on web accessibility specifies WCAG 2.1 Level AA as the technical standard and makes no mention of overlay products as an acceptable compliance method. Compliance is measured by whether the site meets specific WCAG success criteria when tested with assistive technology — not by what third-party products are installed.

What actually reduces my risk of an ADA lawsuit?

Genuine, documented, code-level WCAG 2.1 AA remediation is the most defensible position. Fix alt text, form labels, keyboard navigation, heading hierarchy, and color contrast in your source code. Document the work with timestamped git commits and before-and-after audit results. Publish an accessibility statement. Run quarterly audits. These are what courts weigh — not widget subscriptions.

If I already have an overlay installed, should I remove it?

Focus first on fixing your underlying accessibility failures in code — that is the work the overlay cannot do for you. If the overlay is causing screen reader conflicts (you can test this with VoiceOver or NVDA), removing it may improve the experience for blind users. If it is providing useful visual preference controls and not creating conflicts, it can stay as a supplemental layer. But it cannot be your primary or only accessibility strategy.

Are some overlay products better than others?

The core limitation is shared across all overlay products: they operate at render time and cannot fix foundational source-code issues. Some products are more technically careful than others, and some add genuinely useful user-preference controls. No overlay on the market can reliably bring a fundamentally inaccessible site to WCAG 2.1 AA conformance. Treat the best-case overlay as a supplemental preference layer on top of real code remediation — never as a substitute for it.

Also in the Copper Bay Labs suite

Accessibility is one layer of pre-launch risk. These free tools cover the rest:

Privacy policy ComplyKit

Generate a privacy policy, terms of service, and cookie notice for your site — free, in your browser, no account.

 Security headers HardenCheck

Scan your live site's HTTP headers for missing CSP, HSTS, and other security hardening flags.

 Secret scanning LeakCheck

Paste code or a config file and see exposed API keys and secrets flagged before they reach the repo.

 Post-deploy ExposureCheck

Scan your live URL for exposed .env files, .git directories, source maps, and bundled secrets.