Skip to content

Why Accessibility Overlays Keep Losing in Court

Roughly one in four US accessibility lawsuits in 2025 hit a site that had already installed an overlay. The timing model explains why, and the alternative is less exciting and actually works.

Published
Read
8 min

There is a product category built entirely on the hope that accessibility is a script tag. Drop in one line of JavaScript, get a small icon in the corner, and the problem is handled. It is a compelling offer, and the courts have now spent several years explaining why it is not true.

The number that ends the argument: roughly 22.6% of US web accessibility lawsuits in the first half of 2025 targeted sites that already had an overlay installed. In May 2025 alone, 119 defendants running an accessibility widget were sued. Nearly one in four of these cases hit a site that had already paid for protection.

Why the timing model cannot work

The technical problem is not that overlay vendors write bad code. It is when the code runs.

A screen reader builds its picture of a page from the accessibility tree the browser exposes. That happens as the document parses. An overlay is JavaScript that executes afterwards, then reaches back in and rewrites attributes on elements the assistive technology has, in many cases, already read. You are patching a document that has been delivered.

Source-level fixes have no such gap. Accessible markup ships in the first byte. There is no race, no dependency on a third-party script loading, and no divergence between what the browser parsed and what the user is told.

This is also why overlays frequently make things worse rather than neutral. Injecting ARIA onto elements that already carry native semantics produces double announcements, wrong roles, and focus traps. Users of assistive technology report turning overlays off as the first step to using a site at all, which tells you most of what you need to know.

Accessible markup ships in the first byte

What overlays can and cannot detect

Even setting the timing aside, automated detection has a ceiling. Overlays catch somewhere in the region of 20 to 30% of WCAG violations, and the ones they catch are the mechanical ones: a missing alt attribute, a contrast ratio below threshold, an unlabelled input.

The failures that actually block a task are judgement calls. Is this alt text meaningful or is it the filename. Does the focus order follow the visual order. Does the error message say what went wrong and how to fix it. Can a keyboard user escape this modal. Does the custom dropdown announce its expanded state. No script decides those, because they are questions about meaning, and meaning is not in the DOM.

The regulators caught up

In April 2025 the Federal Trade Commission ordered a major overlay vendor to pay one million dollars over claims that its AI tool could make any website WCAG compliant. That is a plain finding that the core marketing claim of the category was not supportable.

No standard or regulation treats an overlay as compliance. Not WCAG, not the ADA, not the European Accessibility Act, not India's GIGW. Every one of them asks whether the underlying content is accessible. An overlay does not change the underlying content in any durable way, so it cannot answer that question in your favour.

Fix it once in the component, fix it everywhere

What actually works

It is less exciting and it is not a subscription.

Get a manual audit against WCAG 2.2 Level AA. Automated scanning is a first pass that finds the cheap stuff. A human tester using a screen reader and a keyboard finds the barriers. Scope the audit to real journeys rather than a sample of pages.

Fix in components. Most sites repeat the same twenty patterns. Fix the button, the input, the modal, the table, the tab set, and the toast once in the component library, and hundreds of instances heal at the same time. This is the single largest return available in accessibility work, and it is why design systems and accessibility are the same conversation.

Test with people who use assistive technology. Nothing else tells you whether the fix worked in practice. An hour of moderated testing with a screen reader user reorders your backlog faster than any report.

Gate it in CI. Axe in the pipeline, keyboard checks in the component tests, and accessibility in the definition of done. It will not catch everything, and it stops regressions, which is most of the value.

Publish an honest statement. Say what conforms, what does not, when the gaps close, and how to report a problem. Honesty is defensible in a way an overclaim is not.

The uncomfortable arithmetic

An overlay costs a few thousand a year and buys the feeling of coverage. A real remediation programme costs more up front and then costs almost nothing, because the fixes live in the components and stay fixed.

Teams choose the overlay because it converts an engineering problem into a purchase order. That trade is exactly what the lawsuits are testing, and so far the answer has been consistent. There is no way to buy your way past the source code.

We remediate at the component level for products that cannot afford to fail an audit. If that is where you are, we should talk.

  • Accessibility
  • WCAG
  • Remediation
  • Compliance
  • Design Systems