Accessibility overlays: why we don't use them

If you've searched for accessibility help recently, you've probably seen ads for overlay products — a single JavaScript snippet that promises to make your website accessible, sometimes overnight. The pitch is compelling: no developer time, no redesign, one subscription fee.

We don't use them. We won't recommend them. And if a client has one installed when we start work, we remove it before we do anything else. This article explains why.

What an overlay actually does

An overlay is a third-party script that loads after your page and injects a floating toolbar — typically a small icon in the corner that opens a panel of toggles: "increase font size", "high contrast mode", "pause animations", and so on.

The script also runs automated checks and attempts to patch certain problems on the fly: adding alt text it guesses from surrounding content, injecting aria attributes into elements that are missing them, rewriting colour values in real time.

This sounds useful. The problem is what it doesn't do: touch your code. Your HTML stays exactly as it is. The overlay intercepts the rendered page and tries to fix what it finds, after the fact, in the browser, for each visitor, every time.

Why that approach breaks the people it's supposed to help

Screen readers — software like JAWS, NVDA, and VoiceOver that reads a page aloud — work directly with the browser's accessibility tree: a structured representation of the DOM built from your actual markup. They do not interact with the visual layer the overlay is patching.

When an overlay injects its own toolbar and widgets, those elements appear in the accessibility tree alongside your existing content. The result is often:

• Duplicate announcements (the screen reader reads both the original element and the overlay's version)
• Focus traps (keyboard users can't escape the overlay panel)
• Conflicts with settings the user has already applied in their own assistive technology

A blind user who relies on JAWS all day has spent time configuring it to work the way they need. An overlay that rewrites parts of the page in real time is competing with those settings, not helping.

More than 800 accessibility professionals — researchers, assistive-technology vendors, and disabled users — have signed a public statement opposing overlays on exactly these grounds. The core argument: an overlay cannot reliably fix what it cannot see, which is the assistive-technology experience.

The WCAG 4.1.2 problem

WCAG success criterion 4.1.2 (Name, Role, Value) requires that every user interface component — buttons, inputs, toggles, menus — exposes its name, its role, and its current state in the accessibility tree, so assistive technologies can communicate it accurately.

A common failure is a button built from a <div> instead of a <button> element. It looks like a button. It works like a button with a click handler. But because it has no semantic role, a screen reader announces it as generic text, or skips it entirely.

An overlay can attempt to inject role="button" into that <div> at runtime. But this fix is fragile: it depends on the overlay running before the user's assistive technology reads the element, it may conflict with other aria attributes already present, and it only works in the browsers the overlay vendor has tested. The underlying failure is still in your code.

The only reliable fix for a 4.1.2 failure is to change the markup — to use the right element, or to add the correct aria attributes in the source, not as an afterthought injected by a subscription service.

Overlays haven't stopped lawsuits — they've featured in them

If the technical argument doesn't land, consider the legal track record.

Companies in the United States — where ADA accessibility litigation is well-established — have been sued while running overlays. In some cases, the overlay was cited by plaintiffs as evidence that the company knew about accessibility problems and chose a cheap workaround instead of fixing them. That is not a defence; it is a paper trail.

UK law under the Equality Act 2010 and, for public sector and larger digital services, the European Accessibility Act coming into force for private businesses in 2025, focuses on whether a disabled person can actually use the service — not on whether you've installed a widget that claims to help. An overlay that breaks screen readers doesn't satisfy that test.

What we do instead

We fix the markup. That means:

• Correcting semantic structure: headings in the right order, lists that are actually lists, buttons that are actually <button> elements
• Adding descriptive alt text written by a human who understands the image's purpose in context
• Making keyboard navigation work without a mouse — Tab order, focus indicators, skip links
• Ensuring form labels are programmatically associated with their inputs (another common 4.1.2 failure)
• Writing ARIA attributes where native HTML semantics aren't enough — and only where they're needed

We also tell clients plainly that automated tools — the kind overlays rely on — catch somewhere around 30–40% of WCAG issues. The rest require a human to test, because they involve context, judgment, and actually using the page with a keyboard or screen reader.

The business case for doing it properly

A properly marked-up page works better for everyone, not just assistive-technology users. Search engines read the same accessibility tree screen readers use. A heading structure that makes sense to JAWS makes sense to Google. Descriptive link text that helps a screen reader user navigate a page also helps a search engine understand what the page links to.

Fixing accessibility in the code is a one-time cost that lives in your codebase. An overlay is a recurring subscription that can be turned off by the vendor, conflict with future browser updates, and — as the legal record shows — does not transfer legal risk away from you.

---

If you're not sure where your site stands, our free Accessibility Snapshot gives you an automated scan plus a short human review, delivered as a plain-English report — no jargon, no sales pitch, just an honest picture of what's there. You'll find the link on this page.