Overlays Got Fined $1M. Here Is What Actually Works.

In January 2025, the Federal Trade Commission ordered accessiBe to pay $1 million for deceptive marketing of its accessibility overlay widget. The final order came in April 2025.

The core issue: accessiBe claimed its widget, accessWidget, could make any website WCAG-compliant. It can't. The FTC found the product failed to make basic components — menus, headings, tables, images, media — actually accessible. On top of the false compliance claims, the FTC cited accessiBe for deceptive endorsements: paying $1,900 for reviews, approving them before publication, and presenting them as independent third-party opinions.

The order bars accessiBe from claiming any automated product achieves WCAG compliance without substantiation. That's the FTC saying, on the record: you cannot automate your way to compliance.

This wasn't a surprise to anyone in the accessibility community. The National Federation of the Blind had already called accessiBe “harmful to the advancement of blind people in society” and revoked the company's convention sponsorship. Over 1,000 accessibility professionals signed the Overlay Fact Sheet documenting overlay failures — signatories include W3C spec contributors, internal accessibility leads at Google, Microsoft, Apple, Shopify, and disabled end users who deal with these widgets daily.

The fine was $1 million. The real cost is larger.

What overlays promise vs. what they deliver

Overlay vendors sell a JavaScript widget you drop onto your site. One line of code, instant WCAG compliance, lawsuit protection. accessiBe charged $490–$950/year for it. UserWay charges $49–$149/month. The pitch sounds reasonable if you don't understand how screen readers work.

Here's the problem.

Screen readers don't wait for JavaScript

When a screen reader loads a page, it parses the HTML and builds an accessibility tree— a parallel structure that maps elements to their roles, names, states, and relationships. This happens as the page loads. The overlay widget is a JavaScript file loaded asynchronously, which means it executes after the screen reader has already built its tree.

Some screen readers update the tree when the DOM changes. Some don't, or do so unreliably. JAWS, NVDA, and VoiceOver each handle dynamic updates differently. An overlay that “fixes” an ARIA attribute after page load may or may not actually reach the user. The fix is non-deterministic across the assistive technology landscape. That's not a foundation for compliance.

Injected ARIA attributes create conflicts

Here's something most people outside the accessibility community don't know: bad ARIA is worse than no ARIA. The first rule of ARIA, per the W3C, is literally “don't use ARIA” if you can use a native HTML element instead.

When an overlay injects role, aria-label, or aria-liveonto elements that already have semantic meaning, it doesn't add clarity. It adds noise. A <button> already has an implicit role="button". Adding an explicit one is redundant. Adding the wrong one — like role="link"on a button — actively breaks the user's mental model.

Screen reader users hear the role announced. If the role says “link” but the element behaves like a button (responds to Space, not Enter), the user has been lied to by the interface. Overlays don't have enough context about the developer's intent to inject ARIA correctly. They guess. And they guess wrong often enough to make things worse.

Reading order and keyboard navigation need source code fixes

WCAG 1.3.2 requires that reading order be meaningful. Screen readers follow DOM order, not visual order. If your CSS Grid layout puts the sidebar before the main content in the DOM, no amount of JavaScript injection fixes that. The DOM needs to be restructured.

WCAG 2.1.2 says no keyboard traps. If your custom dropdown doesn't respond to Escape or traps Tab focus inside it, the fix is rewriting the component's keyboard handler. An overlay can't intercept keyboard events inside components it didn't build without breaking their functionality.

These aren't edge cases. They're among the most common accessibility barriers, and they all require modifying the source code.

Alt text generation is theater

Some overlays use image recognition to auto-generate alt text. The results are what you'd expect from generic image classification applied to specific UI contexts. A hero image promoting a spring sale gets alt="woman smiling outdoors". A product photo gets alt="white object on table".

WCAG 1.1.1 doesn't require alt text that describes what an image looks like. It requires a text alternative that serves the equivalent purpose. The purpose of a product photo is to show the product. The purpose of an infographic is to convey data. No generic ML model knows the purpose of your specific image in your specific context. That takes a human who understands the content.

The lawsuit data: overlays make you a bigger target

This is the part that should concern anyone paying for an overlay.

According to UsableNet's mid-year 2025 report, 22.6% of ADA digital accessibility lawsuitsin the first half of 2025 targeted websites with overlay widgets installed. That's 456 lawsuits out of 2,019 total.

Think about that proportion. Overlays are installed on a small fraction of all websites, but they account for nearly a quarter of all accessibility lawsuits. The reason is straightforward: plaintiffs' attorneys know overlays don't fix the underlying issues. A site with an overlay is easy to prove non-compliant because it is non-compliant. The overlay is just a JavaScript file that loads on top of broken HTML.

For the full year of 2025, there were 8,667 ADA Title III federal lawsuits filed. That's up 27% year-over-year. The litigation trend is accelerating, and overlays offer no protection.

Adrian Roselli, one of the most respected voices in web accessibility, published detailed analyses showing that UserWay, AudioEye, and accessiBe all fail to deliver on their promises. AudioEye responded by suing him. They dropped the suit in January 2024, paid $10,000 to the NFB as part of the settlement, and agreed that Roselli's statements were protected opinion. When your response to criticism is litigation instead of fixing the product, that tells you everything.

What actually works

There is no one-line-of-code solution to accessibility. If someone tells you there is, they are either uninformed or lying. Here's what actually works, in order of impact.

1. Fix your HTML

Most accessibility violations are HTML problems. Missing <label> elements. <img> tags without alt. <div> elements used as buttons without keyboard handling or ARIA roles. Non-semantic markup that treats the DOM as a visual canvas instead of a document structure.

Fix these at the source. In your components. In your templates. Where the code lives. Not with a widget loaded at runtime.

2. Automate what machines can catch

Automated testing with axe-core catches approximately 57% of WCAG violations. That includes the highest-frequency issues: color contrast (WCAG 1.4.3), missing alt text (1.1.1), unlabeled form controls (4.1.2), invalid ARIA attributes, missing page titles (2.4.2).

Run it in CI/CD. Every pull request, every deploy. When a developer adds an <img> without alt, the build fails before the code reaches production. That's prevention, not remediation.

I built AccessPulse to do exactly this — run axe-core on your pages, report violations by severity, and integrate into GitHub Actions so regressions get caught in the pipeline. It handles the 57% that machines can reliably test.

3. Test manually for the other 43%

Automated tools can't evaluate alt text quality, reading order coherence, keyboard interaction patterns in custom widgets, or cognitive accessibility criteria like consistent navigation (WCAG 3.2.3). For these, you need humans.

That doesn't mean hiring a $50,000 audit firm. Start with:

• Navigate your key user flows (signup, checkout, search) using only a keyboard. Can you complete them? Can you always see where focus is?
• Turn on VoiceOver (macOS: Cmd + F5) or download NVDA (free, Windows) and listen to your pages. Does the announced content make sense? Are form fields labeled? Are images described meaningfully?
• Review your alt text. Not whether it exists — whether it's useful. alt="hero image" passes automated checks. It tells a blind user nothing.

Do this quarterly on critical flows. It takes a few hours, not a few months, and it catches the 43% that no tool — overlay or otherwise — can automate.

4. Integrate testing into development, not deployment

The overlay model is fundamentally backward. It applies a patch at runtime instead of fixing the code at build time. Accessibility testing belongs where the rest of your quality checks live: in the editor, in the pull request, in the CI pipeline.

axe-core integrates with every major testing framework: Jest, Playwright, Cypress, Storybook, and standalone CLI. If you write tests for your application, you can write accessibility tests alongside them. Five lines of config in a GitHub Action gives you automated WCAG checks on every push.

The honest truth about automated testing

I need to be clear about something, because the last thing this industry needs is another vendor overclaiming: automated testing does not make your site WCAG compliant. AccessPulse does not make your site WCAG compliant. axe-core does not make your site WCAG compliant.

Automated testing catches 57% of issues. That 57% includes the most common and most impactful violations — the ones that affect the most users on the most pages. Automating their detection is valuable. But calling it compliance is the exact claim that cost accessiBe $1 million.

The difference between an overlay and a testing tool is the difference between a coat of paint and a structural repair. One hides the problem at the surface. The other identifies it so you can fix it in the foundation.

If your site currently uses an overlay widget, removing it is a net improvement for your users and your legal exposure. Replace it with automated testing that catches real issues in your codebase, paired with periodic manual checks for everything automation misses.

Run a free AccessPulse scanto see what axe-core finds on your site. No overlay. No magic. Just a list of what's broken and how to fix it.

Related reading

• What axe-core actually tests (and misses) — the 57% that automated testing covers, explained by WCAG principle
• I scanned 87 SaaS landing pages — 97% have WCAG violations, none use overlays to fix them
• Add WCAG testing to GitHub Actions in 5 minutes — the CI/CD approach that replaces overlays
• AccessPulse vs AudioEye — testing your code vs overlaying it at runtime

Frequently asked questions

Why was accessiBe fined by the FTC?

The FTC fined accessiBe $1 million in April 2025 for falsely claiming their overlay widget made websites WCAG compliant and for fabricating endorsements from disability organizations. The FTC found that accessiBe's JavaScript overlay cannot make websites fully accessible.

Do accessibility overlays prevent ADA lawsuits?

No. According to UsableNet's 2025 data, 22.6% of ADA accessibility lawsuits targeted websites with overlay widgets installed. Having an overlay may increase legal risk because it demonstrates awareness without actually fixing the code.

What should I use instead of an accessibility overlay?

Fix your source code. Use automated testing tools like axe-core (catches ~57% of WCAG issues) integrated into CI/CD, combined with manual accessibility audits for the remaining 43%. No automated tool — overlay or scanner — can make a site fully WCAG compliant alone.

Sources: FTC v. accessiBe, Overlay Fact Sheet (1,001 signatories), UsableNet 2025 mid-year report, ADA Title III litigation data, Deque automated testing study, Adrian Roselli on FTC v. accessiBe.