Accessibility Overlays vs Real Fixes: Why Widgets Don't Work
The overlay promise
Accessibility overlay companies make a compelling pitch: add one line of JavaScript to your site, and you’re WCAG compliant. No code changes, no redesign, no developer time required.
Companies like AccessiBe, UserWay, and AudioEye have raised hundreds of millions of dollars on this promise. But the promise is false.
Why overlays don’t work
1. They can’t fix what they can’t see
Overlays operate by injecting JavaScript that runs in the visitor’s browser. They can detect some issues — like missing alt text or low contrast — but they cannot reliably fix them.
An overlay might generate alt text using AI, but that text is only available when the overlay script loads. If the script fails, times out, or is blocked by a content security policy, the accessibility improvements vanish.
2. Screen readers already have these features
Most overlays advertise features like “increase font size,” “change contrast,” and “read page aloud.” Screen readers and operating systems already provide all of these features, and they do it better.
Adding a redundant interface on top of existing assistive technology often creates confusion. Users have reported overlay widgets interfering with their screen readers, breaking keyboard navigation, and trapping focus.
3. The legal record is clear
- The FTC fined accessiBe and required the company to stop making false claims about WCAG compliance.
- About 25% of 2024 accessibility lawsuits targeted sites already running an overlay or widget (UsableNet).
- The National Federation of the Blind issued a statement opposing overlays, calling them “not a path to compliance.”
- Multiple law firms now specifically target overlay users, arguing that the presence of an overlay demonstrates awareness of accessibility issues without adequate remediation.
4. They cover a fraction of WCAG
Even in the best case, overlays can address approximately 20-30% of WCAG 2.1 success criteria. The remaining criteria require structural HTML changes, semantic markup, and content decisions that no client-side script can make.
What real remediation looks like
Real accessibility fixes modify your source code:
- Missing alt text → Alt text is written into the
<img>tag in your HTML - Heading hierarchy → The actual heading elements (h1, h2, h3) are corrected
- Form labels →
<label>elements are associated with their inputs - Skip links → A “Skip to content” link is added to your HTML structure
- Focus styles → CSS focus indicators are made visible
These changes persist regardless of JavaScript availability. They work with every screen reader. They survive caching, CDN distribution, and script blockers.
The WP Comply approach
WP Comply Pro fixes the HTML your WordPress site renders:
- Scans every page for WCAG violations
- Fixes issues in the rendered HTML using server-side processing
- Documents every fix in exportable reports
The result: your HTML is clean and accessible before it reaches the browser. No overlay widget, no JavaScript dependency, no performance penalty.
The free version scans unlimited pages and shows the violations it detects. Pro auto-fixes them.
Cost comparison
| Factor | Overlay | WP Comply |
|---|---|---|
| Annual cost | $490-$1,800/year | $0 (free) or $99/year (Pro) |
| WCAG coverage | ~25% of criteria | All scanned criteria |
| Legal protection | Lawsuits have increased | Remediation documentation |
| Performance impact | 200-500KB JavaScript | Zero frontend overhead |
| Screen reader compatibility | Often breaks navigation | Clean HTML, fully compatible |
| Dependency | Requires active subscription | No third-party SaaS dependency |
The bottom line
If someone offers you a quick fix for accessibility, ask yourself: does this change my actual code, or does it paint over the problems?
Overlays mask problems. WP Comply solves them.
Read more: What Is WCAG 2.1? · EAA Compliance Guide