The Badge in the Corner
A business owner is told about a one-line script. Paste it into the site's header, and within minutes a small icon appears in the bottom corner of every page — a widget that lets visitors adjust contrast, resize text, and, according to the marketing around it, brings the whole site into ADA compliance automatically.
It feels like closing a loop that had been nagging for months. No developer hours. No line-by-line code review. Just a script tag and a badge, and the accessibility problem is, as far as anyone can tell, solved.
Six months later, a demand letter arrives anyway.
It names specific pages. It describes a screen reader user who couldn't complete checkout, or couldn't find store hours, or got stuck in a navigation menu with no way to tab back out. The letter doesn't mention the widget at all — because the widget never touched any of the things it's describing.
This is not a rare story. It's common enough that it's worth understanding exactly why it keeps happening, because the answer says a lot about what accessibility compliance actually requires.
What an Overlay Widget Actually Does
To understand why overlays fail to prevent lawsuits, it helps to understand what they technically are.
An accessibility overlay is a third-party script, usually added to a site with a single line of JavaScript. Once it loads, it does two things: it injects a visible interface panel — the corner widget — that lets visitors adjust things like contrast, font size, and spacing, and it attempts to scan and modify the page's existing HTML at runtime to patch accessibility issues it detects.
That second part is the important one, and it's also the part that runs into a hard technical limit. An overlay operates on the DOM — the rendered page — layered on top of code that already exists. It's reading and rewriting what's there. It is not, and cannot be, rewriting how the site was actually built.
That distinction matters more than it sounds like it should, because most of the barriers that actually get disabled users blocked — and actually get cited in demand letters — live in exactly the layer an overlay can't reach.
The Barriers Overlays Can't Touch
A few concrete examples make this less abstract:
Alt text on product images. A screen reader needs meaningful alt text to describe what an image shows. Some overlays attempt to generate this automatically using AI image recognition. In practice, that AI can usually manage generic labels — "person," "shoe," "outdoor scene" — but it can't know that the shoe in the photo is a men's size 11 trail runner in a specific colorway that the customer is trying to decide whether to buy. Writing alt text that actually serves a shopping decision requires a human who understands the product and the page, not a runtime script guessing at pixels.
Broken tab order. If a page was built in a way that makes keyboard focus jump around unpredictably — skipping the search bar, landing on a hidden element, looping back to the top of the page instead of moving forward — that's a structural problem in the markup itself. An overlay can add styling around focus, but it cannot rewrite the underlying DOM order and component structure that determines where focus actually goes. The tab order is broken in the code. The overlay sits on top of the code.
Custom widget keyboard behavior. If a business built its own dropdown menu, date picker, or modal, and that component's keyboard behavior was never coded correctly — no escape key to close it, no arrow-key navigation, no way to reach it by tabbing at all — an overlay cannot retroactively make that component behave correctly. Correct keyboard behavior has to be built into the component itself, not bolted onto it after the fact.
These aren't edge cases. They're among the most commonly cited barriers in actual accessibility complaints, precisely because they're the barriers that block someone from completing a task — finding a product, filling out a form, checking out — rather than barriers that are merely cosmetic.
When the Fix Makes Things Worse
There's a second problem, and it's a more uncomfortable one: some overlays don't just fail to fix things — they actively interfere with tools that were already working.
A widely known industry initiative, the Overlay Fact Sheet, is a public statement signed by a large number of disabled users, accessibility professionals, and organizations. It documents firsthand reports from actual screen reader users describing exactly this problem: an overlay makes its own ARIA modifications to a page — inserting or altering the attributes that tell assistive technology what an element is and how to interact with it — and those modifications conflict with a screen reader's own handling of a page that was already working correctly for that user.
In other words, a screen reader user who could navigate a site just fine before the overlay was installed can find the site less usable after it, because the overlay's automated changes clash with the assistive technology already running in the browser. That's not a minor caveat. It's a signal that the fix, applied blindly and at runtime, can be actively counterproductive for the exact population it claims to serve.
Why the Badge Isn't a Legal Shield
Here's the part that catches business owners off guard: a visible "we're compliant" badge is not, on its own, a defense.
A plaintiff's attorney — or a real screen reader user testing the site for their own reasons — isn't evaluating whether a badge is present. They're testing the actual experience: can I complete this purchase, can I read this content, can I fill out this form, using the assistive technology I actually use. If the answer is no, the barrier is documented exactly the same way it would be documented on a site with no widget at all.
Some businesses that relied solely on an overlay widget have still received ADA demand letters and faced lawsuits for exactly this reason. The overlay changed what the corner of the page looks like. It didn't change whether the site actually works.
What's Actually Worth Keeping
None of this means every assistive display feature is worthless. That's an important distinction, not a footnote.
Genuine user-facing features — adjustable text sizing, a well-implemented high-contrast mode, a natural-voice read-aloud tool that's actually built well — can be a legitimate value-add for visitors who want them. The problem isn't the feature. The problem is the pitch: marketing those features as a substitute for a genuinely accessible underlying site, instead of what they should be, which is a supplement to one.
A read-aloud button is a nice-to-have on a site where the underlying markup, keyboard behavior, and alt text are already correct. It's a liability when it's positioned as the thing that makes an otherwise-broken site compliant.
What Real Remediation Looks Like
Durable compliance work looks meaningfully different from a script tag. It includes:
- A WCAG 2.1/2.2 AA conformance audit run against the actual codebase — not a surface scan of the rendered page, but a review of the markup, ARIA usage, and component behavior underneath it.
- Developer-level fixes to markup, ARIA attributes, and keyboard interaction patterns — the same layer an overlay can't reach, addressed directly.
- Ongoing testing, including manual testing with real screen readers, as the site changes over time. Accessibility isn't a one-time state; a site that passes today can regress with the next redesign or feature launch.
- A published accessibility statement that describes the real, ongoing effort — not a compliance claim, but a documented commitment that shows good faith and gives visitors a way to report problems directly.
The reason the "install one script, get a badge, be done" pitch is so appealing is exactly the reason it doesn't hold up: real remediation takes real engineering work. That's not a knock against overlays as a category of tool — it's the actual explanation for why the fast version and the durable version produce such different outcomes.
The Bottom Line
An overlay widget can be part of a genuinely accessible site. It cannot be the whole of one. The barriers that get businesses sued — missing alt text with real meaning, broken tab order, incorrectly coded custom components — live in the code itself, and no runtime script layered on top changes that.
If your site is currently leaning on a widget as its entire accessibility strategy, the honest next step is finding out what that widget isn't catching, before someone else finds it first. WCAG.World runs full WCAG 2.1/2.2 AA conformance audits against your actual codebase, prioritizes the fixes that matter most, and builds the kind of documented, ongoing remediation effort that holds up under real scrutiny — not just a badge.
Start with a conversation and find out what's actually underneath your site's widget.