Why Accessibility Overlays Like AccessiBe and UserWay Don't Make Your Site ADA Compliant

If you have searched for "ADA compliance" or "accessibility widget" in the past year, you have almost certainly seen the pitch: paste one line of JavaScript into your site and become ADA compliant overnight. AccessiBe, UserWay, EqualWeb, audioEye and a dozen other overlay vendors sell variations of the same promise.

It is a compelling story. Accessibility is complex, WCAG has 78 success criteria at Level AA, and a real audit costs thousands of dollars and weeks of remediation work. Against that, "$49/month and you are compliant" is almost irresistible.

There is one problem: it doesn't work. And the gap between what overlays promise and what they actually deliver has now been tested in court, scrutinized by the accessibility community, and — most importantly — experienced directly by screen reader users who have documented how overlays break their ability to use affected websites.

This article explains what overlays actually do, why the accessibility community rejects them, what US courts have ruled, and what a real accessibility strategy looks like.

What Accessibility Overlays Actually Do

Overlays are JavaScript widgets. When a visitor loads a page with the snippet installed, the widget:

1. Injects a floating button or menu (often a blue circle in the corner)
2. Opens a panel with toggles for "high contrast," "readable font," "bigger cursor," "screen reader mode" and similar options
3. Scans the DOM and attempts to add ARIA attributes, adjust contrast ratios, and generate alt text using machine learning
4. Applies CSS overrides when users toggle the visual options

The marketing frames this as "accessibility" but conflates two very different things:

• User preferences — font size, contrast theme, cursor size. These are genuine accessibility features, and overlays implement them reasonably well.
• Structural accessibility — whether a blind user can actually navigate your site with a screen reader, whether a keyboard user can complete your checkout, whether your forms are understandable. This is what WCAG measures, and it is what overlays fundamentally cannot fix.

The Core Problem: You Cannot Fix Accessibility at Runtime

Accessibility is a property of your underlying HTML, your component architecture, your design decisions, your copy, and your interaction patterns. It is decided when you build the page. An overlay that scans the rendered DOM and tries to patch it arrives too late.

Consider a few concrete examples of why runtime patching fails:

Alt text generated by AI

Overlays use computer vision to generate alt text for images that lack it. For a photo of a dog, this might produce "A brown dog standing in grass." Acceptable — until the image is your CEO's headshot on the About page (now captioned "A man with glasses"), your product infographic (captioned "A diagram with arrows"), or an image of text that contains critical information (captioned "Text on a white background"). Meaningful alt text requires understanding what the image is for on this specific page. Machines cannot do that.

ARIA added to the wrong elements

Overlays attempt to fix accessibility by adding ARIA attributes to existing elements. But ARIA without correct roles, states and relationships creates worse accessibility than no ARIA at all. The W3C's First Rule of ARIA is: if you can use a native HTML element, don't use ARIA. Overlays routinely add role="button" to divs that are not keyboard-accessible, or announce states that are not actually tied to the widget's behavior.

Screen reader conflicts

Real screen reader users — NVDA, JAWS, VoiceOver — do not need an overlay's "screen reader mode." They already have a screen reader. When an overlay detects assistive technology and activates its own layer, it often intercepts keyboard events, overrides the screen reader's announcements, or traps focus in the widget panel. The overlay tries to help and instead breaks the site for the users it claims to serve.

Overrides that make things worse

"High contrast mode" in an overlay is a CSS stylesheet that inverts colors or applies black-on-white. It often produces worse contrast than the original design, breaks visual hierarchy, and hides content that depends on color (badges, charts, brand elements). Users who need real high contrast use OS-level settings that the browser respects; overlay contrast modes fight those settings.

What the Accessibility Community Actually Says

In 2021, overlayfactsheet.com was published — an open letter signed by 700+ accessibility professionals, researchers and disabled users, declaring that overlay products "do not make a website compliant with WCAG or any accessibility law." The signers include most of the recognized names in web accessibility: Deque, TPGi, WebAIM, The Paciello Group, Level Access and many independent consultants.

Disabled users have also been vocal. The National Federation of the Blind passed a resolution in 2021 condemning overlay products, citing direct experience of overlays making sites less usable for screen reader users.

Independent research backs this up. WebAIM's annual analysis of the top one million home pages has consistently found that sites with overlays installed have accessibility error rates similar to — and sometimes worse than — sites without them.

What US Courts Have Ruled

The legal reality is now clear: installing an overlay does not shield you from ADA liability. Several representative cases:

• Murphy v. Eyebobs (2021): The court ruled that the defendant's use of an AccessiBe overlay did not moot the plaintiff's ADA claim. The case proceeded on the merits.
• Access Now v. Blue Apron (2022): The court found that an overlay did not cure the underlying accessibility violations alleged in the complaint.
• Numerous default settlements where defendants with overlays installed still paid settlements in the $10,000–$75,000 range, plus remediation costs.

By 2024, plaintiffs' firms specifically sought out overlay-using sites because the pattern was so well documented. The FTC has also taken interest: in 2024, AccessiBe settled with the FTC over $1 million for deceptive marketing claims about its overlay's accessibility benefits.

What Overlays Actually Do Reasonably Well

To be fair: overlays are not worthless. The visual preference features — font size adjustment, cursor size, dyslexia-friendly fonts, pause animations — are genuine accessibility enhancements for some users, and they work. The problem is that these features are:

• Marketed as "compliance" when they are not
• Priced as if they solved accessibility when they solve a tiny slice of it
• Often bundled with the structural "fixes" that do actively harm screen reader users

If you want a preference panel on your site, you can build one in an afternoon with a few CSS custom properties and a toggle. You do not need a $500/year subscription to offer users a bigger font size.

Decision Framework: What To Do Instead

Replace the overlay with a real accessibility strategy sized to your organization:

Your situation	What actually works	Budget range
Small business, static marketing site	DIY audit using our WCAG 2.2 AA checklist + axe DevTools + one round of manual keyboard testing	$0 (internal time)
E-commerce or SaaS preparing for EAA / ADA	Structured accessibility audit with PDF report mapped to WCAG success criteria + remediation sprint	$500–$5,000
Enterprise, high-risk, public sector	Full consultancy engagement (Deque, TPGi, Level Access) with user testing and VPAT	$15,000–$75,000+
Agencies delivering to clients	White-labeled audit as a service — bundle into every launch checklist	Per-client, chargeable

The middle tier is where most businesses sit, and it is exactly the tier the market has under-served. Overlays exist because real audits were too expensive and slow for most teams. The answer is not to skip the real audit — it is to make a real audit faster and more accessible itself.

The Minimum Viable Accessibility Workflow

If you remove your overlay tomorrow, here is the smallest workflow that actually improves accessibility:

1. Automated scan every deploy. Add axe-core to your CI pipeline. Fail the build on new serious or critical issues. This catches 30–40% of WCAG violations at zero marginal cost.
2. Manual keyboard audit quarterly. Unplug the mouse. Tab through every primary user flow. Every interactive element must be reachable, operable and visibly focused.
3. Screen reader smoke test quarterly. Use NVDA + Firefox on Windows or VoiceOver + Safari on Mac. Complete the top three user journeys. Note anywhere the experience is confusing.
4. Formal WCAG 2.2 AA audit annually. Either internal (if you have the expertise) or external. This catches what automation and smoke testing miss.
5. Accessibility acceptance criteria on every ticket. Make it a definition-of-done requirement, not a post-launch cleanup.

If You Have an Overlay Installed Today

You do not need to remove it tomorrow — but you should not trust it to provide legal protection either. A reasonable sequence:

1. Audit what you actually have. Run a real WCAG audit on your site to measure where you stand before the overlay. That is your actual compliance baseline.
2. Remediate the underlying code. Fix issues at the source. Your contrast ratios, semantic structure, keyboard flow, alt text and form labels should all pass without any widget running.
3. Decide whether the preference panel adds value. If you like the font-size, cursor, and theme toggles, build them natively or keep the overlay purely for those features. Stop relying on it for compliance.
4. Publish a real accessibility statement. Document the standard you meet (WCAG 2.2 AA), known gaps, feedback channel, and review cadence. A real statement beats an overlay badge every time.

The Bottom Line

Accessibility is not a compliance checkbox you can install. It is a product quality attribute that shows up in your markup, your components, your design decisions and your process. Overlays are a shortcut around that reality — and the evidence from experts, users and courts is that the shortcut does not reach the destination.

The good news: a real accessibility audit is more accessible than it used to be. Instead of a $20,000 consultancy engagement, most teams can now get a structured WCAG 2.2 AA audit with a stakeholder-ready PDF report in days, not weeks. Heurilens is launching a dedicated Accessibility Audit built for agencies, e-commerce operators and SaaS teams who need real compliance documentation — not an overlay widget. Join the waitlist for early access.