Why Accessibility Overlays Don't Work

Accessibility overlay widgets have become one of the most controversial products in the web accessibility space. Companies like accessiBe, UserWay, and AudioEye promise "one-line of code" compliance with ADA and WCAG standards. Here's why that promise doesn't hold up.

What overlays actually do

Overlays inject a JavaScript widget onto your page that attempts to modify the DOM at runtime. They add ARIA attributes, adjust contrast, resize text, and provide keyboard navigation helpers — all without changing your actual source code.

Why this approach fails

**1. They don't fix the underlying code.** If your images lack alt text, an overlay guesses what the image shows using AI. These guesses are frequently wrong. A product photo described as "person standing near object" provides no useful information to a screen reader user.

**2. They break assistive technology.** Screen readers like JAWS, NVDA, and VoiceOver already have their own mechanisms for adjusting text size, contrast, and navigation. Overlay widgets often conflict with these tools, creating a worse experience than the original site.

**3. They can't address structural issues.** Missing form labels, incorrect heading hierarchy, broken keyboard navigation, inaccessible custom components — these require source code changes. No runtime script can fix a fundamentally inaccessible component architecture.

**4. Legal exposure remains.** The National Federation of the Blind has explicitly stated that overlays are "not made with the needs of blind people in mind" and has actively opposed their use. Over 800 accessibility lawsuits have been filed against companies using overlay products.

The FTC takes action

In 2024, the FTC fined the leading overlay provider $1 million for making deceptive claims about their product's ability to make websites compliant with WCAG standards. The settlement required the company to stop claiming their product could make any website fully accessible.

What actually works

Real accessibility compliance requires:

• •Source-level auditing — Testing your actual HTML, CSS, and JavaScript against WCAG criteria — — Testing your actual HTML, CSS, and JavaScript against WCAG criteria
• •Developer remediation — Fixing violations in your codebase, not papering over them — — Fixing violations in your codebase, not papering over them
• •Manual testing — Verifying keyboard navigation, screen reader compatibility, and visual design with actual assistive technology — — Verifying keyboard navigation, screen reader compatibility, and visual design with actual assistive technology
• •Continuous monitoring — Catching regressions as your site evolves — — Catching regressions as your site evolves
• •Documentation — Maintaining audit trails and VPATs that demonstrate genuine compliance efforts — — Maintaining audit trails and VPATs that demonstrate genuine compliance efforts

This is what Access Audit provides. No overlays, no shortcuts — real compliance for the modern web.