The badge sits in the corner of the page, usually blue or green, usually promising something like "accessibility enabled." For a growing share of the companies that installed one in 2026, it did not do what the sales pitch implied. It sat there, visible in the page source, while a demand letter arrived anyway.
The Number Behind the Purchase Order
Procurement teams and compliance officers bought overlays on a specific theory: install a script, reduce legal exposure, move on to the next line item. The 2026 litigation data does not support that theory.
The Stat: More than 1,000 businesses — over 25% of all tracked digital accessibility lawsuits in 2026 — were sued despite already having an accessibility overlay or widget installed on their site. (Source: 216digital 2026 overlay risk analysis)
Read that chart the way a plaintiff's attorney does. It is not a chart about accessibility. It is a chart about a purchasing decision that failed to reduce risk in the way it was marketed to.
Why an Installed Widget Isn't the Same as a Fixed Site
An overlay is a script that runs on top of your existing markup. It can reposition focus outlines, insert ARIA attributes it did not author, or attempt to rewrite how assistive technology interprets the page — all without touching the underlying HTML, templates, or component library that produced the original barriers. That gap between "script is running" and "barrier is gone" is exactly where the 2026 lawsuits are landing.
What Screen Reader Users Report
Users who navigate with JAWS or NVDA have described a consistent pattern across sites running overlays: the overlay's own script intercepts keyboard commands before the screen reader can act on them, elements get announced twice or out of sequence, and content the screen reader had already parsed correctly gets hidden or restructured by the widget's DOM injection. In each case, the underlying page may have been navigable before the overlay was added. The widget introduced the conflict.
This matters for a simple reason: a plaintiff does not need to prove your entire site is inaccessible to win a claim or force a costly settlement negotiation. They need to prove that a real user, using real assistive technology, hit a real barrier. An overlay that breaks a keyboard command supplies that proof directly, and it does so with the vendor's own script visible in the page source as the mechanism.
For a compliance team, that is a different risk profile than "we haven't gotten to remediation yet." An unremediated site with no overlay is, at least, a consistent story: the underlying HTML is what it is, and a screen reader user's own software handles it the same way every time. Add a third-party script that rewrites focus order or intercepts input, and you introduce a variable that neither your team nor the assistive technology vendor controls. When that variable breaks something that used to work, the resulting complaint is not about a gap in your remediation roadmap — it is about active interference your organization paid to install.
How the Filings Have Changed
Demand letters used to reference broad WCAG failure categories — missing alt text, poor contrast, unlabeled form fields. What's shifted in 2026 filings is specificity. Plaintiffs' counsel is increasingly citing the overlay's own behavior as the evidence: the widget re-announcing content, the widget's focus trap, the widget's failure to actually remediate what it claimed to fix. That framing is harder to defend against than a generic WCAG citation, because it points to a specific script the defendant chose to install, on a specific date, marketed with specific compliance claims.
| Old demand-letter angle | 2026 overlay-era angle |
|---|---|
| General WCAG 2.x failure categories (contrast, alt text, labels) | The overlay's own script cited as the source of the barrier |
| Site described as "inaccessible" | Site described as offering a "separate and unequal" experience via the widget |
| Remedy sought: broad remediation commitment | Remedy sought: evidence the overlay did not deliver what it was purchased to deliver |
| Defense posture: point to the overlay as good-faith effort | Defense posture undermined: the overlay itself is now the exhibit |
That last row is the one compliance leaders should sit with. The overlay was often purchased specifically as evidence of good-faith effort — something to point to if a complaint ever arrived. In more than a quarter of tracked 2026 cases, it became the opposite: evidence that the company knew accessibility was a live issue, spent money on it, and still produced a barrier.
What "Separate and Unequal" Means in Practice
The legal theory driving these filings is not new — it is the same logic behind physical-access cases where a business built a side entrance and ramp instead of making the front door usable by everyone. An overlay that sits on top of unremediated markup creates a comparable structure: disabled users get a different, script-mediated experience layered over the same underlying barriers, while everyone else gets the original page. When that layered experience performs worse than the AT user's own software would have performed on unmodified, well-structured HTML, the "separate and unequal" framing has direct evidence behind it.
This context matters at scale. The CDC estimates roughly one in four U.S. adults has a disability, and the WebAIM Million study continues to find detectable WCAG 2 failures on approximately 95.9% of home pages tested. Overlay vendors have marketed their products as a way to address that gap quickly. The 2026 litigation numbers suggest a meaningful share of buyers treated the purchase as the finish line rather than the starting point — and that assumption is now showing up in court filings, not just in blog posts about best practice.
What This Means for Compliance Programs
None of this means remediation is hopeless or that every accessibility vendor is equivalent to every other. It means the underlying test — does a real user on real assistive technology get a working, equivalent experience — has to be answered with evidence, not with a badge in the corner of the page. For an IT or compliance leader responsible for a government agency site or a large corporate property, that translates into a short list of questions worth answering this quarter:
- Has anyone actually tested your site with JAWS or NVDA since the overlay was installed, or only before?
- Does your current documentation describe remediation of the underlying markup, or does it describe the presence of a script?
- If a demand letter arrived tomorrow citing the overlay's own behavior, what would your response be?
- Who signed off on the overlay as a compliance measure, and what were they told it would do?
- Does your procurement file distinguish between "overlay installed" and "WCAG conformance verified," or do the two get treated as interchangeable line items?
Answering those honestly usually requires an independent look at the actual page structure, not another vendor's dashboard reporting on itself. That is the gap a full audit is built to close: a page-by-page, assistive-technology-tested account of what a disabled user actually encounters on your site today, overlay or no overlay. For a government agency, that documentation also does double duty as the record you would want on file if a Section 508 or ADA complaint ever required you to show your actual due diligence, rather than a marketing claim from a script vendor.
If your organization is relying on a widget and hasn't independently verified what it does under real keyboard and screen reader use, now is the time to check — before a filing does it for you. Get a full accessibility audit from WCAG.World and find out what your current setup actually delivers, in writing, before it becomes someone else's exhibit.