Why Accessibility Overlays Don’t Work

A few months ago, I went to a local event full of people who work in the disability space. Occupational therapists. Disability rights attorneys. Nonprofit leaders. People whose entire professional lives revolve around helping disabled people live better, fuller lives.

Over the course of the evening, as I shared my work in website accessibility, each person was anxious to tell me how they had done work to ensure their own sites were accessible. Every single one told me, with some pride, that they had installed an accessibility overlay.

They thought they were doing the right thing.

They weren’t.

If the overlay pitch can fool the people who work with disabled clients every day, it’s not surprising that it keeps fooling web agencies, small business owners, and in-house teams too. This is a marketing problem. Overlay vendors have built one of the most effective (and most misleading) marketing machines in the accessibility space, and a lot of well-intentioned people have bought what they’re selling.

So let me explain, as clearly as I can, why overlays don’t work, and what to do instead.

Why the overlay pitch feels convincing

The sales pitch for overlays is genuinely compelling. Install one line of JavaScript and AI handles the rest. Your site is “accessible” instantly, often for less than the cost of a single hour of a consultant’s time. And if you’re worried about a lawsuit, the widget comes with compliance language baked right in.

I completely understand why people say yes. Accessibility can feel overwhelming. WCAG (Web Content Accessibility Guidelines) is long. The legal landscape is scary. Most people don’t know where to start, and a one-click solution sounds a lot more appealing than “hire someone, audit your site, remediate every page, train your team, and maintain it forever.”

If a one-click fix existed, I’d be recommending it too. But it doesn’t.

What overlays actually do

…the overlay becomes a second interface layered on top of the first, and now you have two inaccessible interfaces

An overlay is a JavaScript widget that loads on your site every time someone visits. It runs its own automated scan of the page and then tries to “patch” problems on the fly, usually by injecting new attributes or hiding elements it thinks are broken.

It also adds a floating button that opens a menu of settings: high contrast, larger text, stop animations, read aloud, and so on.

That menu is where a lot of the confusion starts. It looks accessible. It feels accessible. If you’re a non-disabled person who clicks around inside it, you might think those features look helpful and conclude it’s making your website more accessible.

But the menu isn’t what most disabled users interact with. Screen reader users use a screen reader. Keyboard users use the keyboard. People with cognitive disabilities need content and structure they can actually understand, not the cognitive overload of seventeen toggles. In most cases, the overlay becomes a second interface layered on top of the first, and now you have two inaccessible interfaces.

Why overlays can’t fix accessibility

You can’t bolt semantic meaning onto a page that doesn’t have it.

Accessibility is about the page itself. It’s about whether your headings are nested correctly, whether your form fields have labels, whether your buttons announce what they do, whether your focus order makes sense, whether the color contrast lets someone actually read the text.

You can’t bolt semantic meaning onto a page that doesn’t have it. An overlay can’t know that the <div> you styled to look like a button is supposed to be a button. It can’t know which of your three unlabeled inputs is the search field. It can guess. It does guess. And when it guesses wrong, which is often, it makes the experience worse.

Overlay vendors publish impressive-sounding claims about how many issues their widget “fixes.” The actual user research tells a different story. Disability advocacy organizations and web accessibility professionals have been warning about overlays for years. Screen reader users have repeatedly reported that overlays break sites that were otherwise navigable. When assistive technologies and overlays collide, the overlay almost always loses.

“But what about lawsuits?”

This is the most common reason people give me for installing an overlay. Just last week I was speaking with a company that builds sites for clients, and they said something I’ve heard dozens of times: “We put overlays on our clients’ sites because we don’t want them to get sued.”

If you’re hoping for legal protection, you’re paying for the opposite.

Here’s what I had to tell them.

An overlay won’t prevent you from being sued. Not even close. Plaintiffs’ firms know exactly what overlays are, and they often specifically target sites that use them. A widget that claims your site is compliant while the underlying page still fails basic WCAG criteria is, legally, a problem on its own. In some cases, overlay marketing language has been used as evidence of deceptive claims.

The number of lawsuits against sites using overlays isn’t zero. It isn’t even small. If you’re hoping for legal protection, you’re paying for the opposite.

In March 2026, there were 444 web accessibility lawsuits filed in the U.S. Of those, 114 were filed against sites using an overlay. (Link goes to a perpetually updated lawsuit tracker.)

What to do instead

Slower and less exciting than a widget, but unlike the widget, it actually works.

The honest answer is that there’s no one-click fix. But there is a straightforward path.

1. Run an automated scan. An automated accessibility scanner can catch the most common issues. Fix the easiest ones first: low contrast text, missing alt text, missing form labels, empty links, empty buttons, and missing page language. These six issues account for over 96% of automatically-detectable errors on the web.
2. Test with a keyboard. Turn off, disconnect, or set aside your mouse. Try to use your site. You’ll find real problems in minutes.
3. Fix issues at the source. A missing label goes in your HTML. A broken focus order gets addressed in your code. It’s work, but it’s the only work that actually makes your site more usable.
4. Keep going. Accessibility isn’t a one-time project. Build the habit, train your team, and make small improvements part of your normal workflow.

That’s the whole approach. Slower and less exciting than a widget, but unlike the widget, it actually works. When you truly fix accessibility issues at their source, you remove barriers that are preventing people from accessing your website.

If you or your client already installed one

Don’t beat yourself up. You had good intentions and you bought something that was sold to you as a solution. Most of the people I talk to about overlays got there in exactly the same way.

But please, remove it. Then start doing the real work. If you’re an agency with clients on overlays, have an honest conversation with them. Explain the risk, propose a real plan, and help them move forward. That conversation will be harder than the sales pitch they originally bought, but it’s the one that actually protects them.

The real work is slower. It’s less glamorous. And a website that disabled users can actually use is a far better outcome than one that claims to be accessible while locking them out. The clients who understand that difference are the ones who stay with you for the long haul.