Why Accessibility Overlays Don't Protect Your Business

Accessibility overlay products are sold with a compelling pitch: install a single JavaScript snippet, pay a monthly fee, and your website becomes ADA-compliant. No developer required, no code changes needed. Compliance in a day.

The pitch is attractive. The product, by most available evidence, doesn't deliver what it promises. Regulators, courts, and the disability community have said so in increasingly direct terms.

What Overlays Are and How They Work

An accessibility overlay is a third-party JavaScript widget that loads on top of your existing website. When a user visits, the script runs after the page loads and attempts to modify what's displayed or announced to assistive technologies, adding alt text where it's missing, adjusting color contrast on the fly, or injecting ARIA attributes that weren't in the original code.

Some overlays also present a toolbar that lets users customize their experience: increase font size, switch to a high-contrast mode, or enable "screen reader optimization." The vendor's claim is that these modifications bring the site into compliance with WCAG 2.1 AA without touching the underlying code.

That's precisely the problem.

The Technical Case Against Overlays

Accessibility compliance isn't a layer you add on top of a website. It's a property of the website's underlying HTML, CSS, and JavaScript structure. Overlays run after the browser has already parsed and rendered the page, which means they're working against the grain of how browsers and screen readers interact.

Screen readers don't wait for overlay scripts to finish executing. They parse the DOM as it loads and build an accessibility tree: a structured representation of the page's content and interactive elements. By the time an overlay attempts to inject fixes, the screen reader may have already announced the page. Subsequent modifications can cause duplicate announcements, broken focus management, or conflicting ARIA attributes that make navigation harder, not easier.

This isn't a theoretical concern. Disabled users and accessibility professionals have documented overlay-induced regressions across widely-used products. The interference with native browser accessibility APIs (the code pathways that screen readers, voice control software, and switch access devices rely on) is a consistent pattern across overlay products.

Overlays also cannot fix what requires structural change. A form with no labels in the HTML cannot be labeled by a script that runs after render without introducing its own accessibility problems. A navigation structure that doesn't follow logical heading hierarchy cannot be reorganized by an overlay. The fixes that matter most are the fixes that require actual code changes.

The FTC's $1 Million Enforcement Action

In 2025, the Federal Trade Commission moved from the realm of advocacy into enforcement. The FTC ordered an accessibility overlay vendor to pay $1 million and prohibited the company from making deceptive claims about its product's ability to make websites WCAG-compliant. The order runs for 20 years.

The specific claim the FTC found deceptive: that the vendor's AI-powered product could automatically make any website comply with WCAG accessibility standards. According to the FTC, that claim was false, and the company made it while charging businesses a recurring fee for a product that didn't deliver compliance.

For businesses that purchased overlay products based on those representations, the enforcement action creates a secondary problem: they may have paid for something that didn't provide the legal protection they thought they were buying.

What the Litigation Data Shows

Courts have not accepted overlay deployment as a legal defense to ADA website accessibility claims. The legal standard is whether the website is actually accessible to disabled users, not whether the business made a good-faith effort by installing a third-party widget.

The numbers underscore how ineffective overlays are as a litigation shield. In May 2025 alone, 119 businesses were sued for inaccessible websites while actively running third-party accessibility widgets. The plaintiffs' attorneys who brought those cases are using the same automated scanning tools that overlay vendors claim their products address. The scans found violations. The lawsuits followed.

Installing an overlay may not remove violations from automated scan results. In some cases, the overlay itself introduces new detectable accessibility failures. A business that installs an overlay and assumes it's protected may be in a worse position than one that hasn't addressed accessibility at all, because they've incurred a monthly cost without reducing their actual exposure.

The Disability Community's Position

The National Federation of the Blind, one of the largest and most influential disability advocacy organizations in the United States, has publicly opposed accessibility overlay products. More than 600 accessibility professionals signed an open statement, published at overlayfactsheet.com, calling for overlay vendors to stop claiming their products create accessibility compliance.

The statement is notable because it represents a consensus among the people who actually use and evaluate these tools: the people assistive technology is designed to serve, and the professionals whose job is to make the web work for them. Their objection isn't philosophical. Overlays don't work as advertised and in many cases make the user experience worse.

What Actually Works

The alternative to overlays isn't expensive or complicated. It's the same approach used for any software quality problem: find the issues, fix them in the code, and verify the fix.

Step one is identifying what's broken. Automated scanning tools can detect roughly 57% of WCAG violations, the issues that are reliably identifiable through code analysis: missing alt text, contrast failures, unlabeled form fields, missing page structure, keyboard navigation failures. This is where most businesses should start because these issues are fixable and commonly cited in litigation.

Step two is fixing the source code. This means a developer updating the actual HTML, CSS, and ARIA attributes, not a script that attempts to patch things at runtime. A form field gets a <label>. An image gets an alt attribute. A heading hierarchy gets corrected. These fixes are permanent. They don't require a monthly subscription to maintain. They don't break when the overlay vendor changes their script.

Step three is verification. Retest after making changes. Run an automated scan to confirm the detectable issues are resolved. Walk through the manual checklist items (keyboard navigation, logical heading structure, meaningful link text) that scanners can't evaluate automatically.

Overlay vs. Scan-and-Fix: The Practical Comparison

The overlay model is built on the idea that accessibility is a compliance checkbox rather than a property of the site itself. The scan-and-fix model treats it as what it actually is: a code quality issue with a known solution.

CompliScan takes the opposite approach to overlays. We scan your site, tell you exactly what's broken, and give you step-by-step instructions to fix the actual code: the underlying HTML, not a script running on top of it. No monthly subscription required to maintain compliance. Run a free scan to see where your site stands.

Get a free instant scan or order a full PDF report with fix instructions tailored to your site.