Do accessibility overlays protect businesses from ADA website accessibility lawsuits?
No. The Federal Trade Commission, federal courts, and the international accessibility community have all weighed in on this. And yet overlays are still being sold to thousands of businesses every month as a compliance solution.
In April 2025, the FTC approved a final order requiring accessiBe to pay $1 million for making deceptive claims that its AI-powered widget could make any website WCAG-compliant. The FTC found the claims were “false, misleading, or unsubstantiated.”
That ruling should have ended the debate. This post explains exactly why overlays fail technically, what users with disabilities encounter when one is installed, and what genuine WCAG 2.2 compliance actually requires.
Key Takeaways
- The FTC fined accessiBe $1 million in April 2025 for falsely claiming its widget could make websites WCAG-compliant.
- In 2025, 3,948 ADA website accessibility lawsuits were filed in the US, a 23.84% increase over 2024.
- 22.6% of all US web accessibility lawsuits in the first half of 2025 targeted websites that had accessibility overlays installed.
- Over 600 accessibility professionals, including contributors to the WCAG, ARIA, and HTML specifications, have signed the Overlay Fact Sheet stating overlays do not achieve compliance.
- Screen readers like JAWS, NVDA, and VoiceOver interact with the HTML DOM, not with overlay scripts. Overlays cannot fix barriers in code they do not change.
- Genuine ADA compliance requires fixing the underlying HTML, CSS, and JavaScript through real remediation and manual testing.
What Is an Accessibility Overlay?
An accessibility overlay is a third-party JavaScript widget, typically a small floating button on the corner of a web page, that claims to automatically fix accessibility issues without changing your website’s underlying source code. Well-known overlay products include accessiBe, UserWay, and AudioEye.
The sales pitch is simple: install a script tag, pay a monthly subscription, and your site becomes “accessible” and “ADA compliant.”
The technical reality is that an overlay sits on top of your existing HTML, CSS, and JavaScript. It does not rewrite your source code. Instead, it attempts to inject modifications in real time using AI or rule-based heuristics, adding alt text attributes, adjusting colour contrast, or modifying focus behaviour after the page has already loaded in the browser.
This approach has one structural flaw that no amount of AI can solve. Screen readers do not interact with overlays. They interact with the DOM.
Why Accessibility Overlays Do Not Work for Screen Reader Users
When a person with a visual disability visits your website using a screen reader like NVDA, JAWS, or VoiceOver, the screen reader parses the HTML document directly. It reads the DOM tree as the browser rendered it. It does not wait for a third-party script to finish modifying the page.
Here is what this means in practice:
Missing alt text. If your image has no alt attribute in the HTML, the screen reader announces “image” or reads the filename. The overlay may detect the missing attribute and plan to inject a description, but by the time that injection runs, the screen reader has already moved to the next element.
Unlabelled form inputs. If your form field has no associated <label> element, a JAWS user hears only the input type with no context about what to type. The overlay’s automatic labelling logic runs after DOM load, but the timing does not reliably align with how assistive technology reads the page.
Keyboard focus traps. If a modal dialog on your site traps keyboard focus behind it, a keyboard-only user is stuck. An overlay script layered on top of broken JavaScript focus management cannot retroactively fix the logic baked into your components.
Custom widget failures. ARIA-based components like accordion menus, tab panels, and date pickers require specific keyboard interaction patterns defined by the ARIA Authoring Practices Guide (APG). An overlay cannot rewrite the event listeners that handle those interactions.
The WebAIM Screen Reader User Survey found that over 70% of screen reader users find overlays make websites harder to use. Many users say they immediately try to disable overlay widgets when they encounter them. Some users report that the “screen reader mode” offered by overlays actually conflicts with their actual screen reader.
I have tested websites with overlays installed. I turned the overlay on. I opened the page with NVDA running. The barriers were still there. The overlay added a floating button and a settings panel. The underlying accessibility failures remained exactly as they were before installation.
What the FTC and Courts Have Said
The FTC Fined accessiBe $1 Million
In April 2025, the Federal Trade Commission approved a final order requiring accessiBe to pay $1 million for falsely claiming its AI-powered widget could make any website compliant with WCAG for people with disabilities. The order bars accessiBe from representing that its automated products can make any website WCAG-compliant unless it has evidence to support that claim.
This is not a minor regulatory note. The United States federal government’s consumer protection authority found that the core marketing claim of the accessibility overlay industry — “install our widget, get compliance” — was false.
Overlays Do Not Stop Lawsuits
According to EcomBack’s 2025 ADA Website Lawsuit Annual Report, 3,948 ADA website accessibility lawsuits were filed in the US in 2025, a 23.84% increase over 2024. The first half of 2025 alone saw 2,014 lawsuits, a 37% jump over the same period in 2024.
More specifically: 22.6% of all US web accessibility lawsuits in the first half of 2025 targeted websites that had accessibility overlay widgets installed. According to UsableNet data, 1 in 4 ADA lawsuits in 2024 cited overlay widgets as barriers rather than solutions. An overlay on your site is not a shield. In some courtrooms, it has been treated as evidence that your business knew about its accessibility obligations and chose a workaround instead of genuine remediation.
Over 800 businesses with accessiBe installed were still sued for ADA website accessibility violations. The overlay did not prevent the lawsuits. Plaintiffs’ attorneys test websites with real screen readers. When those screen readers find barriers, the legal claim holds.
The DOJ Has Codified WCAG 2.1 AA as the Federal Standard
In April 2024, the US Department of Justice finalized a rule under ADA Title II requiring state and local government websites and mobile applications to conform to WCAG 2.1 Level AA. The rule does not say “installing a widget counts as conformance.” It says the underlying site must meet the technical standard.
The Overlay Sales Pitch vs. What Actually Happens
| What overlay vendors claim | What actually happens |
|---|---|
| “AI automatically fixes your site” | Scripts inject changes after DOM load; screen readers read before the changes apply |
| “Instant WCAG 2.1 or 2.2 compliance” | The FTC found this claim to be “false, misleading, or unsubstantiated” |
| “Protection from ADA lawsuits” | 22.6% of 2025’s first-half ADA lawsuits targeted sites with overlays installed |
| “Meets Section 508 requirements” | Section 508 requires actual ICT conformance; overlays do not achieve it |
| “Works for all disabilities” | Over 70% of screen reader users say overlays make websites harder to use |
What 600+ Accessibility Experts Have Officially Stated
The Overlay Fact Sheet is a public statement signed by over 600 accessibility professionals, including contributors and editors for the WCAG, ARIA, and HTML specifications, and internal accessibility experts from Google, Microsoft, Apple, Shopify, eBay, and Target. It states:
“No overlay product on the market can cause a website to become fully compliant with any existing accessibility standard and therefore cannot eliminate legal risk.”
The National Federation of the Blind, the American Council of the Blind, and hundreds of disability rights organisations have also signed statements opposing overlay products, citing that they often impede screen readers rather than helping them.
This is not a fringe opinion. It is the consensus of the people who wrote the standards overlays claim to satisfy.
The Overlay Widget Is Often Inaccessible Itself
This is the detail that is hardest to believe until you test it firsthand.
I have tested overlay control panels with VoiceOver on iOS and NVDA on Windows. Here is what I find regularly:
The trigger button has no accessible name. A screen reader user hears “button” with no description of what it does.
The control panel opens after activation, but keyboard focus does not move into the panel. A keyboard user who just opened the accessibility settings cannot actually use those settings.
Options within the panel like “increase text size” or “high contrast mode” are built as div elements with click handlers rather than native button elements. They are not in the tab order. A keyboard user cannot reach them.
Closing the panel returns focus to the top of the page instead of back to the trigger button where the user was before opening it.
An accessibility solution that is itself inaccessible to the people it claims to serve is not a compliance product. It is a product designed to look like one.
What WCAG 2.2 Level AA Actually Requires
WCAG 2.2 is the technical standard courts and federal regulators treat as the benchmark for ADA website compliance. It is published by the World Wide Web Consortium (W3C) and is the standard our team tests against on every engagement.
Meeting WCAG 2.2 Level AA requires that your website actually work for users with disabilities. Not that it appear to try. The key requirements include:
Text alternatives (Success Criterion 1.1.1): Every meaningful image, icon, and non-text element has a text alternative that conveys the same information.
Keyboard accessibility (Success Criteria 2.1.1 and 2.1.2): Every function available by mouse is available by keyboard. No keyboard traps exist anywhere on the site.
Focus visible (Success Criterion 2.4.7, strengthened in 2.4.11 under WCAG 2.2): Keyboard focus is always visible on screen with a minimum target area and contrast.
Labels and instructions (Success Criteria 1.3.1 and 3.3.2): Form inputs have programmatically associated labels. Instructions appear before the fields they describe.
Error identification (Success Criteria 3.3.1 and 3.3.3): Error messages identify which field failed and describe how to fix it, and they are announced to screen reader users without requiring a focus change.
Name, Role, Value (Success Criterion 4.1.2): Every user interface component has an accessible name, the correct ARIA role, and its current state exposed to assistive technology.
None of these requirements are met by injecting a script on top of broken code. They are met by writing correct HTML, using semantic elements, managing focus properly in JavaScript, and verifying everything with real screen reader testing. See our accessibility audit service for how we test against each of these criteria.
How to Actually Achieve ADA Compliance
Step 1: Get a manual accessibility audit
Automated testing tools like axe, Lighthouse, and WAVE catch around 30 to 40 percent of WCAG failures. The failures they catch are real, but the ones they miss are the ones that make a site genuinely unusable. Focus traps. Reading order errors. Dynamic content that is never announced. Broken keyboard patterns in custom components. These require a person using a screen reader to find.
A manual accessibility audit conducted by an IAAP-certified specialist using JAWS, NVDA, and VoiceOver tells you what your site actually looks like to a blind user. Every finding maps to a WCAG 2.2 success criterion, a severity level, and a developer-ready fix.
Step 2: Fix the underlying code
Accessibility remediation means changing the HTML, CSS, and JavaScript that produces the barriers. Not adding a script on top. Not sprinkling ARIA attributes randomly hoping they help. (Incorrect ARIA use is worse than no ARIA. It gives screen reader users wrong information about the page.)
Every fix is tied to the audit finding that surfaced it and re-tested after implementation to confirm it is actually closed.
Step 3: Document your conformance
An accessibility statement on your website documents your current conformance level, the standard you tested against, any known remaining issues, and how users can report new barriers. This is required under WCAG itself, the European Accessibility Act (EAA), and IS 17802 in India.
For software products sold to enterprise or government buyers, a VPAT (Voluntary Product Accessibility Template) is the required conformance document in procurement. It must be based on real testing, not self-certification.
Step 4: Build accessibility into your release process
Accessibility conformance is not a one-time state. New features introduce new components. Code changes introduce regressions. An accessibility review before launch and a post-release check after deployment prevents the accumulation of issues that becomes a lawsuit.
What to Do If You Already Have an Overlay Installed
Stop treating it as your compliance posture.
If you installed an overlay after receiving an ADA demand letter, the overlay does not address the legal claim. A genuine audit with documented findings, a prioritised remediation plan, and evidence of good-faith remediation effort is what your attorney needs, not a SaaS subscription receipt.
Read our full guide on what to do after receiving an ADA demand letter for the exact steps to take, including how a certified audit protects your legal position.
We can audit your site with the overlay present or removed. We will tell you honestly what barriers remain, what the overlay modifies if anything, and what genuine remediation would require.
The Bottom Line
The evidence is clear. The FTC found overlay compliance claims to be false. Courts have not accepted overlays as a legal defence. Nearly 1 in 4 ADA lawsuits in 2024 targeted sites with overlays installed. Over 600 accessibility professionals who wrote the standards overlays claim to satisfy have signed a public statement saying they do not work.
The only path to genuine ADA compliance, and to a website that works for the estimated 26 percent of US adults living with some form of disability, is fixing the code.
That work is not as expensive or slow as overlay vendors want you to believe. A focused audit of a typical marketing site takes 2 to 3 weeks. Remediation of the critical barriers can often follow within a month. The result is a website that genuinely works, with documentation your attorney can use if it ever comes to that.
Get an Honest Assessment of Your Site
If you want to know what your site actually looks like to a screen reader user, with or without an overlay installed, we can tell you.
Request a Free Preliminary Assessment
We audit against WCAG 2.2 Level AA using JAWS, NVDA, and VoiceOver on real browsers and devices. Every finding has a criterion reference, a severity rating, and a fix. No upselling, no overlay widgets, no monthly fees for a script that does not work.
See our Accessibility Audit service, our Remediation service, or our ADA compliance guidance if you have already received a demand letter.
HalfAccessible Private Limited is an IAAP-certified digital accessibility consultancy registered in India, serving clients in the US, EU, and globally. Our specialists hold CPACC, WAS, CPWA, and DHS Trusted Tester certifications.