Why accessibility overlays don't work: what the data shows

Overlays cannot fix missing content

WCAG 1.1.1 (Non-text Content) requires text alternatives for images. If an `` tag lacks meaningful alt text, an overlay can attempt to generate one using image recognition. But "a photo of a person standing in front of a building" does not communicate "CEO Maria Torres at our new Berlin headquarters" when context matters. Only the content author knows the purpose of each image.

Overlays break screen reader navigation

Screen reader users navigate using headings, landmarks, links, and form controls. When overlays inject additional ARIA roles, landmarks, or live regions, they alter the navigation structure screen reader users depend on. The National Federation of the Blind's 2021 resolution specifically cited cases where overlays made previously navigable sites harder to use.

Adrian Roselli documented this in repeated tests: overlays adding `aria-label` attributes to elements that already had accessible names, creating duplicate announcements. Overlays injecting `role="navigation"` on containers that were not navigation, polluting the landmarks list. Overlays adding visually hidden text that screen readers announce out of context (Roselli, 2020-2023).

Overlays cannot fix keyboard traps

WCAG 2.1.2 (No Keyboard Trap) requires that keyboard focus can move away from any component. Keyboard traps typically occur inside third-party widgets: embedded maps, video players, chat widgets, date pickers, and custom dropdowns. An overlay running on the parent page has no access to the internal DOM of cross-origin iframes or shadow DOM components where traps occur.

Overlays cannot test dynamic content

Modern web applications load content asynchronously, render client-side, and change state without page reloads. Overlays take a snapshot of the DOM, but WCAG compliance requires testing the full interaction lifecycle: opening modals, submitting forms, receiving error messages, navigating pagination. Static analysis misses these entirely.

The lawsuit data contradicts protection claims

Overlay vendors often market their products as lawsuit protection. UsableNet's accessibility litigation data contradicts this.

| Year | Total ADA digital lawsuits (US) | Lawsuits against sites using overlays | Overlay protection effect | |------|------|------|------| | 2021 | 4,011 | 400+ (est.) | None observed | | 2022 | 3,255 | Similar proportion | None observed | | 2023 | 4,605 | Increased | None observed |

Sources: UsableNet Digital Accessibility Lawsuit Reports (2021-2023), Lainey Feingold analysis of overlay-related litigation.

accessiBe itself has been named as a defendant or co-defendant in multiple ADA lawsuits. In Murphy v. Eyebobs (2022), the plaintiff specifically alleged that the accessiBe overlay failed to provide accessible functionality. In multiple cases, plaintiffs' attorneys have cited the presence of an overlay as evidence that the defendant knew about accessibility barriers and chose a superficial fix rather than genuine remediation.

Lainey Feingold, a disability rights attorney, has documented that overlay presence does not constitute a legal defense: courts evaluate whether the end-user experience is accessible, not whether a vendor's widget is installed. The DOJ's renewed guidance on web accessibility under ADA Title III reinforces that technical conformance with WCAG, not widget installation, is the expected standard.

What 800+ accessibility professionals say

The Overlay Fact Sheet is a public statement signed by over 800 accessibility practitioners, disability advocates, and web developers. It states:

> "We will never recommend, nor endorse any of these products... they are not created by disabled people, not informed by disabled users, and do not center the needs of disabled users."

Signatories include employees of Microsoft, Google, Adobe, Deque Systems, WebAIM, and Level Access. The fact sheet outlines specific technical concerns and documents known failures.

The National Federation of the Blind, the largest organization of blind people in the United States, passed Resolution 2021-01: "Regarding Accessibility Overlay Products." The resolution opposes the deployment of overlays and calls on organizations to invest in genuine accessibility instead.

Where overlays do provide some value

To be fair, overlays can address a narrow set of user preferences:

• Font size adjustment: Users can increase text size (though browsers already provide this via Ctrl/Cmd +)
• Color contrast toggles: Switching to high-contrast mode (though OS-level settings do this more reliably)
• Animation pausing: Stopping motion for users with vestibular disorders (though CSS `prefers-reduced-motion` handles this natively)
• Reading guides and cursor enhancements: Visual aids that some users find helpful

These features overlap significantly with browser and operating system accessibility settings that already exist. The user preference panel an overlay provides is not worthless, but it does not constitute WCAG compliance. WCAG measures whether content is perceivable, operable, understandable, and robust for assistive technology users, not whether a settings panel exists.

What actually works: testing the real user experience

WCAG compliance requires testing how people actually use your product. That means:

1. Automated scanning for the 30-40% it catches well

Tools like axe, WAVE, Lighthouse, and pa11y detect markup-level violations: missing alt text, insufficient color contrast, missing form labels, duplicate IDs. Run these in CI/CD pipelines for every build.

2. Manual testing with assistive technologies

Screen reader testing with NVDA, JAWS, and VoiceOver. Keyboard-only navigation testing. Voice control testing with Dragon NaturallySpeaking. Magnification testing with ZoomText. This covers the 60-70% of WCAG that automated tools miss.

3. Journey-based testing across user flows

Accessibility issues often appear only during multi-step interactions: checkout flows, form sequences, modal dialogs, dynamic filtering. Testing individual pages in isolation misses state-dependent failures.

Auditi was built specifically for this third category. Rather than scanning pages in isolation, Auditi lets you define complete user journeys (registration, checkout, search, account management) and test accessibility across each step. Issues that only appear when navigating between states, handling errors, or interacting with dynamic content surface in journey-based testing but remain invisible to page-level tools and overlays alike.

4. Continuous monitoring across releases

Accessibility is not a one-time fix. Every new feature, every UI update, every third-party widget integration can introduce regressions. Automated monitoring catches regressions before they reach production.

BetterQA, a software testing company with ISO 9001 and ISO 27001 certifications, built Auditi to replace the manual audit spreadsheets their QA engineers used on accessibility projects. The tool supports WCAG 2.1, WCAG 2.2, WCAG 3.0, FDA 21 CFR Part 11, and EU Annex 11 testing, generates VPAT reports from actual test results, and tracks remediation progress across version releases.

Cost comparison: overlays vs genuine remediation

| Factor | Overlay widget | Proper WCAG remediation | |--------|---------------|------------------------| | Annual cost | $500 - $5,000/year | $5,000 - $30,000 (first year), less ongoing | | WCAG criteria addressed | ~20-25% (presentation layer only) | 100% (when done thoroughly) | | Lawsuit risk reduction | None documented | Significant (demonstrable compliance effort) | | Screen reader experience | Often degraded | Improved | | Legal defensibility | Weak (may show awareness without action) | Strong (documented testing and remediation) | | Maintenance burden | Vendor dependency; breaks with site updates | Internal knowledge; sustainable long-term | | Time to initial improvement | Hours (but surface-level) | Weeks to months (but genuine) |

The overlay is cheaper upfront but provides no legal protection and may actively harm users. Genuine remediation costs more initially but creates sustainable compliance that reduces legal risk and improves actual usability.

Frequently asked questions

Do accessibility overlays actually make sites WCAG compliant? No. Independent testing consistently shows overlays address approximately 20-25% of WCAG 2.1 Level AA success criteria. They operate on the presentation layer and cannot modify semantic HTML structure, fix missing content alternatives authored by humans, resolve keyboard traps in third-party components, or test dynamic multi-step interactions. WCAG compliance requires addressing all applicable success criteria, not just those an overlay can reach.

Are accessibility overlays illegal? Overlays themselves are not illegal, but they do not provide legal protection against accessibility lawsuits. US courts evaluate whether the user experience is accessible, not whether a widget is installed. UsableNet's litigation data shows no reduction in lawsuits for sites using overlays. In some cases, plaintiff attorneys have cited overlay presence as evidence the defendant was aware of barriers and chose a superficial response.

Why did the National Federation of the Blind oppose overlays? The NFB passed Resolution 2021-01 after receiving complaints from blind members that overlay widgets interfered with screen reader navigation. The resolution states that overlays "do not adequately address the needs of blind consumers" and calls on organizations to "refrain from using overlay products." The NFB specifically cited cases where previously navigable sites became harder to use after overlay installation.

What should I use instead of an accessibility overlay? A combination of automated scanning (axe, WAVE, Lighthouse), manual testing with assistive technologies (screen readers, keyboard navigation), and journey-based testing across complete user flows. Auditi handles the journey-based testing component, tracking accessibility across multi-step workflows that page-level tools and overlays cannot assess. Start with your 5-10 most critical user flows.

Can overlays help with any accessibility issues at all? Overlays can provide user preference controls like font size adjustment, high-contrast modes, and animation pausing. However, these features duplicate functionality already available in browsers and operating systems. They are convenience features, not compliance measures. The core issue is that overlays cannot substitute for fixing the underlying code, and their marketing claims overstate what they deliver.

How much does real WCAG remediation cost compared to an overlay? Overlays typically cost $500-$5,000 per year but address only surface-level issues and provide no documented lawsuit risk reduction. Genuine WCAG remediation costs $5,000-$30,000 in the first year (depending on site complexity) but decreases in subsequent years as accessibility becomes embedded in development processes. The investment in real remediation creates a defensible compliance position and genuinely improves the experience for disabled users.

Conclusion

The accessibility overlay market exists because WCAG compliance is genuinely hard. Organizations want a simple solution, and overlay vendors offer one. The problem is that the solution does not work as advertised.

The evidence is consistent across sources: independent researchers, disability advocacy organizations, litigation data, and the signed statement of 800+ accessibility professionals all point to the same conclusion. Overlays address a small subset of accessibility issues, often introduce new barriers for assistive technology users, and provide no demonstrated legal protection.

Real accessibility requires understanding how disabled people use your product, testing those interactions with real assistive technologies, and fixing the actual code. It takes more time and costs more than adding a script tag. But it is the only approach that actually works.

For organizations ready to move beyond overlays, Auditi provides journey-based accessibility testing that evaluates the real user experience across complete workflows, not just isolated page snapshots.