The Trouble with Accessibility Overlays

Somewhere on the internet right now, a small organisation is reading a message that promises to make their website fully compliant with accessibility law in minutes. No developers, no audit, no rework — just paste one line of JavaScript and a tidy floating icon appears in the corner of every page. The pitch is seductive precisely because the alternative sounds expensive and slow. If a single script can guarantee compliance and ward off lawsuits, who would not take that deal?

The trouble is that the deal does not hold. Accessibility is not a coat of paint you can apply to a finished building; it is closer to the plumbing and the load-bearing walls. The most common accessibility overlays problems stem from a simple architectural mismatch: the barriers people with disabilities encounter live in the structure, content and behaviour of a page, and an overlay runs after all of that has already been decided. It can poke at the surface, but it cannot reach the foundations.

This article explains what overlays actually do, why they fall short of their headline promise, what the legal landscape really looks like, and — most importantly — what genuine web accessibility remediation involves. The reassuring conclusion at the end is that the real work is more ordinary, more durable and more within reach than the widgets would have you believe. The capability is almost certainly already inside your team.

What accessibility overlays promise

The marketing for overlay products tends to make three big claims. First, instant compliance: install the script and your site meets the Web Content Accessibility Guidelines (WCAG) without any other changes. Second, automation: artificial intelligence scans your pages and fixes whatever is broken, continuously, with no human involvement. Third, legal protection: with the widget in place, you are shielded from the wave of accessibility lawsuits and demand letters that have become common in recent years.

Each claim is appealing, and each is, at best, a serious oversimplification. The question of whether accessibility overlays are WCAG compliant is not a matter of opinion — it is testable, and the answer is consistently that an overlay alone does not produce a conformant page. The phrase "AI fixes everything" papers over the fact that many accessibility problems require human judgement about meaning and context that no scanner can supply. And the legal-shield claim, as we will see, has not survived contact with actual courtrooms.

It is worth being fair to the people who buy these tools. They are usually acting in good faith, often after a frightening demand letter, and they have been told by a vendor they trust that the problem is solved. The failure here is not the customer's; it is the gap between what is promised and what software running in the browser can physically do. That gap is wide, and the rest of this piece is about why.

How overlays actually work

To understand the limits, you have to understand the mechanism. An overlay is a piece of JavaScript hosted by a third party and loaded into your page. When a visitor's browser renders your site, the overlay script runs and does two broad things. It adds a toolbar — usually a floating button that opens a panel of toggles for larger text, higher contrast, a "dyslexia-friendly" font, a reading guide and so on. And it attempts automated remediation: scanning the rendered document and modifying it on the fly, injecting ARIA roles and patterns onto elements, guessing at labels for unlabelled buttons, or rewriting attributes it judges to be wrong.

Two features of that design matter enormously. The first is that everything happens at runtime, in the visitor's browser, after the page has loaded. The overlay never touches your source code; it manipulates a copy of the page in memory each time someone visits. The second is that the remediation is inferential. The script does not know what your image depicts or what your unlabelled icon does; it makes a statistical guess. When the guess is right, the result can be a small improvement. When it is wrong — and it is wrong often enough to matter — it confidently announces incorrect information to people who have no way to know it is incorrect.

Why one line of JavaScript cannot fix accessibility

Here is the heart of why accessibility overlays do not work as advertised. Accessibility, as codified in WCAG, is a set of dozens of testable success criteria. Independent analysis of automated tooling has long suggested that machines can reliably detect only a minority of those criteria, and they can confidently fix even fewer. The rest require understanding what content means — and that is exactly what an after-the-fact script cannot do.

Consider alternative text for images. The criterion is not "every image has an alt attribute"; it is "the alternative text conveys the same information or function as the image." An overlay can detect a missing alt and may slap on a machine-generated caption, but it cannot know that the photo on your landing page is decorative and should be silent, or that the chart is the entire point of the paragraph and needs a careful description. Meaning is human. The same is true of reading order, error messages that actually explain how to fix the problem, link text that makes sense out of context, and heading structures that mirror the logic of the content.

New barriers, not just missed ones

If overlays merely failed to fix things, they would be a waste of money but mostly harmless. The deeper concern is that they can actively interfere. Many assistive technologies are sophisticated, finely tuned tools, and their users have configured them carefully. When an overlay injects its own keyboard handlers, focus traps or ARIA, it can fight the screen reader the visitor already relies on — double-announcing content, stealing focus, breaking shortcuts, or overriding the operating system's own accessibility settings.

There is also a practical performance cost. An overlay is render-blocking third-party code that loads on every page, and it works against the kind of fast, stable experience captured by Core Web Vitals. Accessibility and performance are allies, not rivals; a page that is quick, predictable and built from clean semantic HTML tends to be more accessible by default. Bolting on a heavy script that rewrites the DOM on every visit pushes in the wrong direction on both fronts. If you want a grounding in how clean structure underpins everything else, our explainer on web development fundamentals, clearly explained is a useful companion to this piece.

The legal picture: overlays and lawsuits

The legal-protection claim deserves its own scrutiny, because it is the one that pushes the most people to buy. In the United States, the relevant law for most public-facing sites is the Americans with Disabilities Act. As the guidance on ADA.gov makes clear, the standard a court cares about is whether people with disabilities can actually access and use your services — not whether you have installed any particular tool.

That distinction is fatal to the shield argument. A widget that does not make the underlying experience usable does not satisfy the law simply by existing. In practice, the opposite has frequently happened: large numbers of demand letters and lawsuits have named sites that were already running overlays at the time of the complaint. In some cases plaintiffs have specifically argued that the overlay itself created or worsened barriers. A floating accessibility icon is, if anything, a flag that advertises your site as a target while doing little to remove the substance of the complaint.

None of this is legal advice, and the details vary by jurisdiction and by the kind of organisation you are. But the strategic point is durable across all of them: the safest position is a site that genuinely works for disabled users, evidenced by testing, not a site that merely looks compliant to a non-disabled buyer. The same caution applies to any "AI solves it" promise — a theme we return to in our look at AI in 2026: what every developer should actually know.

What real accessibility looks like (POUR and WCAG)

If overlays are the wrong answer, what is the right one? It starts with the framework that WCAG is built on, summarised by four principles known by the acronym POUR. The W3C Web Accessibility Initiative maintains these guidelines, and they are less intimidating than their reputation once you see the shape of them.

Perceivable means people can perceive the content through whatever sense they are using — text alternatives for images, captions for video, sufficient colour contrast, and content that does not rely on colour alone to convey meaning. Operable means everyone can drive the interface — full keyboard operability, no traps, a visible focus indicator, enough time to complete tasks, and no content that flashes in ways that can trigger seizures. Understandable means the content and behaviour are predictable — clear language, consistent navigation, labelled form fields, and error messages that say what went wrong and how to fix it. Robust means the markup is clean enough that current and future assistive technologies can interpret it reliably — which is mostly a matter of valid, semantic HTML and ARIA used correctly, or not at all.

Notice what is common to all four: they describe properties of the page's own structure and content, decided by the people who build and write it. This is why accessibility belongs in the same conversation as the rest of your craft — the kind of end-to-end thinking covered in our complete guide to modern web development and design. It also explains why a content system matters: the way authors enter headings, alt text and links every day determines accessibility at scale, a theme we explore in six real benefits of a modern CMS.

Overlay versus real remediation, side by side

The contrast is clearest in a table. The left column is the promise; the right column is what the work actually requires.

Dimension	Accessibility overlay	Real remediation
Where the change happens	At runtime, in each visitor's browser	In the source HTML, CSS, content and templates
Coverage of WCAG criteria	A small, surface-level subset	The full set, including human-judgement criteria
Permanence	Temporary; gone if the script fails to load	Permanent; baked into the codebase
Effect on assistive tech	Can conflict with the user's own tools	Works with every assistive technology by design
Performance impact	Extra render-blocking third-party script	Often improves speed and stability
Legal standing	Frequently named in lawsuits anyway	Evidence of genuine, testable conformance
Who benefits	Mainly the buyer's sense of having "done something"	The disabled users the law is actually about

Read down the right column and a reassuring truth emerges: none of it is exotic. It is disciplined, ordinary engineering and editorial care, applied consistently. That is harder to package as a one-line script, but it is the only thing that delivers.

A practical remediation roadmap

So how do you make a website accessible for real? Here is the roadmap I walk teams through, ordered roughly by sequence and by impact.

1. Audit honestly

Start by finding out where you actually stand. Run an automated checker to catch the easy, machine-detectable issues — missing labels, contrast failures, empty links — but treat that as the floor, not the ceiling. Then do manual testing: navigate the whole site with only the keyboard, and listen to your key pages with a screen reader. The gap between what the automated tool reports and what you experience by hand is, in effect, the gap an overlay can never close.

2. Fix the structure first

Most issues trace back to markup. Use real headings in logical order, not styled div elements. Use buttons for actions and links for navigation. Label every form field and associate every error with its input. Give every meaningful image accurate alternative text and let decorative images be silent. Ensure a visible focus indicator and a sensible focus order. These structural fixes resolve a large share of findings at once and make everything downstream easier.

3. Use ARIA sparingly and correctly

ARIA is powerful and dangerous in equal measure; the first rule is to prefer native HTML elements that already carry the right semantics. When you do need ARIA — for a custom widget, say — follow the established patterns in the ARIA Authoring Practices Guide rather than improvising. Incorrect ARIA is worse than none, because it actively lies to assistive technology, which is precisely the failure mode overlays fall into at scale.

4. Test with real people and real tools

Automated and manual testing by your own team is essential but incomplete. Nothing substitutes for watching people who actually use assistive technology attempt real tasks on your site. Their feedback surfaces issues no checklist anticipates and reorders your priorities around what matters. AI tooling can assist your checks here, but it does not replace lived experience — a boundary we examine in our practitioner take on putting AI at the core of your stack, carefully.

5. Make it continuous

Accessibility decays the moment you stop paying attention; the next deploy or the next article can reintroduce barriers. Bake checks into your build pipeline, add accessibility to code review and your definition of done, and train content authors on the few habits that matter most — headings, alt text, link text and tables. Choosing the right platform and tooling to support that habit is itself a decision worth making deliberately, as we discuss in how to choose the right software solution. Publish an accessibility statement so users know your standard and have a way to report problems.

When, if ever, overlays make sense

It would be dishonest to claim every feature in every overlay product is worthless. Some of the user-facing preference controls — a contrast toggle, a text-resize control, a reading guide — can be mildly useful conveniences for some visitors. The important caveat is that these are not fixes for an inaccessible site, and most of them duplicate capabilities the browser and operating system already provide more reliably. A genuinely accessible page lets a user bring their own tools and settings without needing a vendor's panel at all.

If you have inherited an overlay, the pragmatic path is not necessarily to rip it out in a panic, but to stop treating it as your accessibility strategy. Begin the real remediation work behind it, test whether the widget is helping or actively interfering with assistive technology, and plan to retire it once the underlying site can stand on its own. The destination is a page that needs no overlay because the structure underneath is sound.

The larger lesson is one that recurs across technology: there is rarely a single line of code that absolves you of doing the actual work. Accessibility is a quality of how you build and write, sustained over time, not a product you install. That is genuinely good news. It means the capability is already inside your team — in your developers' command of semantic markup and your authors' care with content — rather than locked behind a subscription to a script. If you want to keep going, browse the full library of articles or read more about who writes this journal on the about page; for a step back to first principles, our look at what exactly a software solution is frames why "buy a widget" so often misreads the problem.

Build it in. Test it with the people it is for. Keep it honest. That is the whole of the method, and no overlay can shortcut it.