Skip to content
wcagc
Create account
←Back to blog
overlayhonestyscreen readersuser research

Do accessibility overlays help users? The evidence

Do accessibility overlays help users? What blind and low-vision users report, where widgets clash with screen readers, and what helps instead.

P

Pavel Charkasau

Do accessibility overlays help users? For most of the people they are sold to help, the evidence says no, and sometimes they make things worse. In a 2024 study of blind and low-vision web users presented at ASSETS, the main academic accessibility conference, as many as 42% of survey respondents said they had stopped using websites that had an overlay, most often because the site was less accessible than before the overlay went in (CREATE, University of Washington). In WebAIM's 2021 survey of accessibility practitioners, 72% of respondents with disabilities rated overlays "not at all or not very effective", and 2.4% rated them very effective (WebAIM). There is a small upside: some users do like the font-size and contrast toggles. But those are settings people already have in their browser and operating system, and the core promise, that a script can repair a page for a screen reader user, is the part users report failing. This post looks at what disabled users actually say, where the friction comes from, and what helps them instead.

What do disabled users say about accessibility overlays?

The most direct evidence comes from asking them. The ASSETS 2024 paper "The Promise and Pitfalls of Web Accessibility Overlays for Blind and Low Vision Users", by Tlamelo Makati (Technological University Dublin) with Garreth W. Tigwell and Kristen Shinohara (Rochester Institute of Technology), combined a survey with follow-up interviews (ACM DOI). According to the University of Washington's CREATE summary of the paper:

  • As many as 42% of survey respondents stopped using websites with overlays.
  • On effectiveness, 16 respondents chose "not at all effective" and 8 chose "not very effective", against 7 "somewhat effective" and 3 "very effective".
  • Respondents visited overlay sites less often than they had before.
  • The biggest problems were layout and page navigation, including being unable to use a screen reader to search the page.

That last point deserves a moment. Searching the page is how many screen reader users get around: jump to the "Checkout" heading, find the word "Delivery", move on. If a widget breaks that, the visitor loses one of their main ways of moving through a page.

A second, smaller study points the same way. Daniela Kubesch's 2024 thesis combined a WCAG 2.1 technical assessment with a user study of 21 visually impaired participants. It found "current overlays offer only marginal benefits", that in some cases they "even hinder usability", and that participants preferred their own assistive technology over the web-based overlays (AccessibleEU).

These are not huge samples, and I would not stretch them into a percentage for "all disabled people". But they line up with the practitioner survey, and none of the studies I found pointed the other way.

Why do overlays clash with screen readers?

Because the visitor already brought their own tool, and the overlay adds a second one on top of it. CREATE's summary reports that overlays with a screen reader mode "clashed with users' screen reader" (CREATE). The American Foundation for the Blind made a similar point in 2022: overlays "often override the settings of users' existing assistive technology software", which "often poses a serious barrier" (AFB).

Picture the mechanics. A blind user arrives with NVDA or JAWS configured the way they like it, down to speech rate and how much it says about each heading. The overlay detects assistive technology, rewrites attributes in the DOM after load, and may pop up a prompt asking them to enable its own mode. Now there are two systems with opinions about the same <button>. The Overlay Fact Sheet notes that these runtime repairs "can either slow down page load times or cause unexpected page changes for assistive technology users." In the ASSETS study, slow or buggy pages and disruptive prompts were among the reasons people left.

There is also a privacy angle the Fact Sheet raises. To switch modes automatically, some overlays detect "when an assistive technology is running on the device", and the Fact Sheet points out that disability is sensitive personal information. That is a separate topic, but it is part of why some users would rather not meet a widget at all.

Do overlay toolbars help anyone?

A little, for some people. The same CREATE summary notes that some participants did benefit from "minor accessibility adjustments" such as font size or color contrast. That is worth saying plainly, because overlay critics sometimes skip it.

The catch is that these adjustments duplicate what users already have. The Overlay Fact Sheet puts it directly: "the end users that these features claim to serve will already have the necessary features on their computer." Browser zoom, OS text scaling, high-contrast and forced-colors modes, reader view, and user stylesheets all work on every site, not just the ones that paid for a widget. A low-vision user who has Windows contrast themes switched on does not need a per-site toolbar. What they need is a page that does not break when contrast themes are on. That part is your CSS.

So the toolbar is the part of the overlay that does the least harm and also the least work. It cannot tell what an unlabeled icon button is for, and it cannot make a custom date picker work from the keyboard. Those barriers live in your markup, and they are the ones that actually stop people.

Why do the vendors' claims sound so different?

Partly because the evidence behind some of those claims was not what it looked like. In April 2025 the US Federal Trade Commission approved a final order requiring accessiBe to pay $1 million (FTC). The order bars the company from claiming its automated product can make any website WCAG-compliant without evidence. It also bars it from presenting reviews and articles about its product as "independent opinions by impartial users". The FTC's complaint alleged that accessiBe formatted third-party articles and reviews to look independent without disclosing its ties to the reviewers.

That matters for this question specifically. If you searched "do accessibility overlays help" a few years ago, some of the glowing user testimonials you found may have been exactly the kind the FTC took issue with. The independent research, by contrast, comes from university labs and the people who use assistive technology every day.

Public bodies have drawn the same conclusion. The State of Illinois Department of Innovation and Technology "currently advises against including overlays on State websites", noting that overlays "sometimes make accessibility issues worse" (Illinois DoIT). The American Council of the Blind passed Resolution 2021-9, "Website Overlays", unanimously at its 2021 convention (ACB).

What actually helps disabled users instead?

Fixing the page itself. My view, and the reason wcagc.com is built the way it is: an overlay is aimed at the site owner's worry, not at the visitor's problem. The visitor's problem is a checkout button that is really a <div>, or a modal you cannot leave with Escape. A script guessing at those after the page loads is a worse fix than a developer changing one line in a component.

In practice that looks like this:

  1. Find the machine-detectable issues. An automated scan maps each failure to a WCAG success criterion with the element and selector. Be clear-eyed about its reach: automated testing catches roughly 30 to 57% of issues depending on how you count, per Deque's analysis of more than 2,000 audits (Deque). Our scanner is in that range too; it will not tell you whether your alt text makes sense or whether a screen reader user can finish your checkout.
  2. Fix them in source. A labeled input in your design system fixes every form that uses it, for every visitor, with JavaScript on or off.
  3. Test the rest by hand. Keyboard through your main journeys, then do the same with a screen reader. The WCAG checklist lists the criteria that need a person.
  4. Respect user settings. Check your pages at 200% zoom and in forced-colors mode, and run your palette through the contrast checker. If the page works with the user's own tools, you do not need to ship a second set.
  5. If you already run an overlay, our guide to removing an accessibility overlay walks through doing it without a gap.

The legal frameworks point at the same target. Under the EAA, conformity is presumed through EN 301 549, which applies WCAG to the web; in the US, courts and the DOJ look to WCAG when applying the ADA. All of them are about whether the content is accessible, and none of them gives credit for a widget on top of it.

Frequently asked questions

Do accessibility overlays help blind users?

Mostly not, according to the research available. In the ASSETS 2024 study of blind and low-vision users, as many as 42% of survey respondents stopped using sites with overlays, most often because the site became less accessible (CREATE). Users also reported overlay screen reader modes clashing with their own screen reader.

Are overlay toolbars useful for low-vision users?

Some low-vision users find the font-size and contrast toggles mildly useful. Browsers and operating systems already offer zoom, text scaling and high-contrast modes that work on every site, so the toolbar mostly duplicates tools people already have. It does not fix structural barriers in the markup.

Why do disabled users dislike overlays?

The main complaints are broken navigation, conflicts with their own assistive technology, slow or buggy pages, and disruptive prompts. Those were the reasons for abandonment reported in the ASSETS 2024 study. In WebAIM's 2021 survey, 72% of practitioners with disabilities rated overlays not at all or not very effective (WebAIM).

Can an overlay make my website accessible?

No overlay makes a site fully conform to an accessibility standard, as the Overlay Fact Sheet states. The FTC's 2025 order bars accessiBe from claiming its automated product can make any website WCAG-compliant without evidence (FTC). Fixing your code and testing by hand is what changes the experience for users.

Should I remove my accessibility overlay?

If it is your main accessibility measure, plan to replace it with source fixes, then remove it. Scan your pages without the widget so you see the real baseline, fix what the scan finds in your code, test the key journeys by hand, and then turn the script off.

See what your visitors actually hit

Want to know what a screen reader user meets on your site, without a widget in the way? Run a free scan. You get each WCAG issue with its element and selector, so your developers can fix it in the source. Then put the remaining criteria in front of a person with a keyboard and a screen reader.

Written by Pavel Charkasau, founder of wcagc.com. Last updated 24 October 2026.

Sources