Scroll to the corner of a lot of websites right now and you’ll find a small circular icon, usually blue, usually captioned some variant of “accessibility.” Click it and a menu opens: larger text, higher contrast, dyslexia-friendly font, screen reader mode. The vendors selling these widgets call them accessibility overlays. The users they’re built for call them the first thing to turn off.
On April 20, 2026, the DOJ extended ADA Title II’s web accessibility compliance deadlines by one year. The extra year is real. It isn’t a reprieve from the underlying requirements, and it doesn’t make an overlay widget any more effective than it was last week. Overlays don’t fail because of timing. They fail because of how they work.
Overlays sit on top of existing HTML and try to patch accessibility problems at runtime. For a few hundred dollars a month, the pitch goes, you can make your site WCAG-compliant without fixing the code. It doesn’t work. Not because the technology is imperfect, but because the approach is structurally unable to deliver what WCAG requires.
What an accessibility overlay actually does
An overlay is a third-party script you drop on a page. It scans the DOM after load, tries to identify accessibility issues (missing alt text, unlabeled form fields, low contrast), and either patches them inline or exposes a menu where users can toggle settings like larger text, higher contrast, or a built-in screen reader.
The pitch is compelling: add one line of JavaScript, get a compliance badge, be done. The reality: the overlay sits on top of inaccessible code. It doesn’t fix the source. It tries to translate between broken HTML and assistive technology at runtime, and almost everything about that approach breaks down under real use.
Why accessibility overlays fail WCAG compliance
Overlays guess at context they can’t see
The hard part of accessibility isn’t detection. It’s interpretation. An <img> with no alt attribute is easy to detect. What that image means in context is not.
Is it a logo, a product photo, a decorative flourish, or an infographic carrying information the body copy doesn’t? The overlay has no idea. It generates a label like “image” or feeds the file to a vision model that guesses “a person smiling.” Neither is useful to a screen reader user trying to understand the page.
Automated tools flag roughly 30% of WCAG issues: the ones that can be detected programmatically. In the audits we run, the remaining 70% only surface through manual testing, keyboard walkthroughs, and review with real assistive technology. That’s the exact work an automated runtime fix can’t do.
Users with disabilities disable them
The users overlays claim to help are the ones most likely to turn them off. In WebAIM’s Survey of Web Accessibility Practitioners, 72% of respondents with disabilities rated overlays as not at all or not very effective. Only 2.4% rated them as very effective. The consistent feedback is that overlays interfere with assistive technology rather than enhance it.
The reason is mechanical. A screen reader user has spent years configuring NVDA, JAWS, or VoiceOver to read the web the way they prefer. Voice speed, verbosity, shortcut keys, focus behavior. An overlay ships its own virtual screen reader and injects its own focus management. Two systems trying to steer the same page end up fighting each other. The user turns off the thing they can turn off, which is the overlay.
Most WCAG failures aren’t alt-text failures
Overlays focus on the issues that are easy to patch from JavaScript: alt text, labels, contrast adjustments. Those are real failures, but they’re a small slice of what WCAG covers.
The failures overlays can’t fix:
- Keyboard traps. A modal that grabs focus and won’t release it.
- Focus order. Elements that tab in the wrong sequence because the DOM order doesn’t match the visual layout.
- Semantic structure. Heading hierarchy, landmarks, and ARIA roles that only make sense when built into the source.
- Form error association. Errors that appear visually but aren’t linked to the field that caused them.
- Motion and animation. Auto-playing video, parallax scroll, flashing content that triggers vestibular or seizure disorders.
- Time limits. Sessions that expire without warning.
- Touch target size. Buttons too small or too close together for motor impairments.
None of these are text alternatives. All of them show up in audits. An overlay that patches a handful of detectable issues still leaves most WCAG criteria in place.
Overlays break when JavaScript fails
The legal standard for accessibility is the page as delivered, not the page after a third-party script finishes loading. If your overlay fails (a content security policy blocks it, the CDN drops, an ad blocker strips it, the user’s network cuts mid-load), the underlying HTML is what remains. That HTML is what an auditor or a court evaluates.
Overlays move your compliance onto a dependency you don’t control. That’s the wrong direction for legal risk. It’s also the wrong direction for how AI assistants read your site: agents parse the same DOM screen readers do, and a layer of JavaScript injecting accessibility at runtime is invisible to them.
Courts have rejected overlay defenses
Sites with overlay widgets installed have been named in ADA lawsuits, and “we use an accessibility widget” has not held up as a defense. Some overlay vendors have themselves faced enforcement action. In April 2025, the FTC finalized a $1 million settlement with accessiBe after finding the company had deceptively claimed its AI-powered widget could make any website WCAG-compliant, and had formatted paid endorsements to look like independent reviews.
Over a thousand accessibility professionals have signed a public statement rejecting overlays as a compliance strategy. WebAIM and Deque Systems, two of the largest independent accessibility research groups, have reached the same conclusion: overlays do not provide WCAG conformance.
”But couldn’t a span for screen readers fix the image?”
A reasonable question, and worth separating from the overlay problem. The sr-only class (or visually-hidden, depending on your framework) is a real, correct pattern. A span of text hidden visually but exposed to assistive technology is good practice when it’s written into the source by a developer who understands the context:
<button>
<svg aria-hidden="true">...</svg>
<span class="sr-only">Close menu</span>
</button>That works because a human chose the right label for the right element. The developer knew the button closed the menu. The overlay approach is different: a script injecting hundreds of those spans across a live page based on runtime guesses, with no knowledge of what any given element is for. The pattern is right. The automation on top of broken source is the problem.
What WCAG compliance actually requires
Real conformance happens in the source, not in a widget:
- Semantic HTML used for its actual purpose.
<button>for buttons,<a>for links,<label>for labels,<h1>through<h6>in order. - Alt text written by someone who knows what the image communicates in context.
- Keyboard paths tested by actually using the keyboard.
- Color contrast built into the design system, not toggled on at runtime.
- Screen reader testing with the tools real users use (NVDA, JAWS, VoiceOver), not a simulation shipped by the overlay vendor.
That’s the work. It’s specific, it’s auditable, and it holds up in court.
We covered what to check first and how to run a basic audit yourself here. If the issues go deeper than you want to fix internally, that’s where a professional accessibility review pays for itself: fewer surprises, a defensible record, and fixes that stay fixed.
The extension isn’t a reprieve
If your compliance plan is an overlay widget, the extra year doesn’t save you. ADA-based lawsuits against private businesses aren’t governed by the Title II deadline and haven’t slowed down. The European Accessibility Act, in effect since June 2025, applies to any business selling to EU customers regardless of where you’re based. And an overlay installed next year leaves the same gaps in the same places as an overlay installed this week.
What the extension does give you is runway. A year to do this properly. Fix what you can in source. Scope what you can’t. Cancel the subscription on a compliance story that doesn’t hold up in audit, and use the time to build accessibility into the codebase the way it should be built.