Accessibility Overlays: Why a Toolbar Will Not Stop a Lawsuit

The pitch is genuinely appealing. One line of JavaScript, a monthly fee, and a site that was inaccessible on Monday is compliant by Tuesday — often with a certificate and a promise of legal protection attached.

If that worked, nobody in this field would do anything else. It does not, and it is worth understanding precisely why rather than taking it on authority, because the reasoning also explains what you do have to do instead. Overlays are one answer to a broader question — which website laws actually bind you — and for most private businesses the answer is not the one the pitch assumes.

We reference this argument in passing across a lot of our writing — in RFP red flags, in our accessibility requirements guide, in the WCAG checklists. This is the long version, in one place.

What an overlay actually is

Two different things get sold under the same name, and the distinction matters.

The first is a user-preference toolbar: a floating button that opens a panel offering larger text, higher contrast, a dyslexia-friendly font, a reading guide, sometimes a text-to-speech reader. It changes how the page looks for the person who opts in.

The second is an automated remediation script: JavaScript that inspects the page after it loads and attempts to repair accessibility defects on the fly — adding alternative text to images, inferring form labels, applying ARIA roles to elements that lack semantics, fixing heading structure.

Most commercial products do both. The first is harmless and occasionally useful. The second is where the claims are made, and where they break down.

The core problem: a script cannot know what it was never told

Accessibility is largely about conveying meaning that sighted mouse users get from visual arrangement. An automated tool operating on rendered output has access to the arrangement but not to the meaning.

Take alternative text. An image needs a description of what it conveys in this context. The same photograph of a person at a desk might correctly be described as "Dr Sarah Chen, consultant cardiologist", or as decorative and given an empty alt attribute, or as "our Chicago office", depending on why it is on the page. Image recognition can produce "a person sitting at a desk". That is not wrong, exactly, and it is not useful. It is noise in place of silence, which for a screen reader user is often worse than the original omission.

The same limitation applies down the line. A script can see that a div behaves like a button and add a button role. It cannot know whether the button submits, cancels, or deletes. It can detect a form field with no label and guess from nearby text. It cannot know that the nearby text belongs to the field above. It can add landmark roles by position. It cannot know which region is genuinely the main content.

Where the tool guesses right, you get a small improvement. Where it guesses wrong, you have replaced a detectable defect with a confident and incorrect statement — which is harder for the user to work around and harder for you to find later.

What an overlay cannot touch at all

Even setting aside the accuracy problem, whole categories of requirement are outside what a client-side script can reach.

It cannot fix your PDFs and documents, which for most public sector and healthcare organizations are the largest part of the problem. It cannot caption your videos or write transcripts. It cannot restructure a page whose reading order does not match its visual order. It cannot make a custom component announce state changes it does not understand. It cannot resolve a colour contrast decision without changing your brand. It cannot fix content inside a third-party iframe. And it cannot make your content management system produce accessible output tomorrow, which means every page published after installation reintroduces the same defects.

That last point is the structural one. An overlay treats symptoms at render time, on every page load, forever, without ever addressing the thing generating the defects.

The legal argument does not hold either

Overlay products are frequently marketed with some form of litigation protection: a compliance certificate, a warranty, or an indemnity.

Read what is actually promised. These are commercial guarantees offered by a vendor, not a legal safe harbour, and no regulator or court has designated any product as conferring compliance. The Department of Justice has never certified an accessibility product, and under ADA Title III there is no federal web regulation to be certified against in the first place — a point we cover in which standard actually binds you.

Meanwhile, sites carrying overlays continue to appear as defendants in web accessibility litigation, and in some matters the presence of the overlay has itself been raised as part of the complaint — on the argument that it interfered with the assistive technology the user already had configured. Installing one is not evidence of compliance and is not reliably evidence of good faith.

There is also a plainer commercial risk. Publishing an accessibility statement claiming conformance you have not tested is a statement about your own site that you cannot support. That is a worse position than saying nothing.

Why disabled users object

This is the part that gets least airtime and probably matters most.

Screen reader users generally have their software configured to their preferences and have spent years learning it. An overlay that intercepts keyboard input, overrides ARIA, or activates its own reading mode does not add to that setup — it fights it. Users report having to disable overlays to complete tasks on sites that would otherwise have been merely difficult.

Thousands of accessibility practitioners and disabled users have signed public statements opposing these products. When the people a tool claims to serve organize against it, that is a strong signal, and it is worth weighing more heavily than any vendor's case study.

When a widget is genuinely fine

The honest version of this argument is not that all such tools are worthless.

A preference toolbar on an already accessible site is fine. Some users like a contrast toggle or a text-size control, and offering one costs nothing and harms nobody. The problem is not the toolbar; it is the toolbar sold as a substitute for the work.

Automated scanning is also genuinely useful — as a monitoring tool. Running automated checks continuously to catch regressions is good practice. The distinction is between a tool that reports defects to you and a tool that claims to repair them for your users.

And there is a legitimate role for alternative access. Some rules explicitly permit alternative methods where they deliver equal or greater access — a staffed phone line that genuinely completes the same task on request, without delay or extra cost, can be part of a real answer. A script that rewrites your DOM is not what that provision contemplates.

What to do instead

Audit against WCAG 2.2 Level AA with manual testing, not scanners alone. Fix the templates and components, because that is where defects are generated. Fix your documents, or replace them with accessible HTML. Then make the CMS enforce the basics — required alternative text, controlled heading structure — so that ordinary publishing does not undo the work. Train the editors. Retest periodically.

It is slower and it is not one line of JavaScript. It is also the only approach that produces a site disabled people can actually use, which is both the point and, not coincidentally, the thing that reduces your legal exposure.

If you are procuring a rebuild, put this in the document: our accessibility requirements guide includes the clause stating that an overlay is not an acceptable response, and explains how to score a bidder who proposes one. If you want to know where you currently stand, start with an accessibility audit.