The most cited research on this, a WebAIM practitioner survey, found 67% of accessibility professionals rate overlays as “not at all” or “not very” effective, a number that rises to 72% among practitioners who have disabilities themselves. That’s not a marginal opinion split; it’s a fairly strong consensus from the people whose job is testing whether sites are actually usable, and it points squarely at overlay-only automation, not at every form of accessibility tooling.

The “do overlays work” question tends to get asked as though it has a single yes-or-no answer, but the research is more precise than that framing suggests. It’s really answering a narrower question: does a script-based, largely automated widget layer reliably deliver the level of accessibility a real WCAG standard requires, without any human involvement in the process? The practitioner data says, overwhelmingly, no. What it doesn’t say is that every accessibility tool with a widget component is worthless, which is a distinction worth holding onto through the rest of this piece.

The core survey data

The Overlay Fact Sheet, which compiles this WebAIM survey data, reports that only 2.4% of surveyed practitioners rated overlays as very effective. Among practitioners with disabilities, who are arguably the most relevant group to ask given they’re the actual end users these tools are meant to help, the negative rating climbed to 72%. That gap between how overlays are often marketed (as a fast, complete compliance solution) and how the people testing them actually experience them is the central tension in this whole debate.

It’s worth noting who’s being surveyed here, since that’s part of why the finding carries weight. These are accessibility practitioners: people whose day job involves testing sites against WCAG, working with screen readers and other assistive technology, and evaluating whether a page actually works for real users. Their skepticism isn’t a general public opinion poll; it’s a professional assessment from people positioned to see exactly where an overlay’s coverage stops.

Why the gap exists

This is the crux of nearly every criticism in this space, so it’s worth understanding mechanically rather than just accepting the survey numbers at face value. Overlays run as a script on top of an existing page rather than modifying the underlying code. That architecture is genuinely good at some things, like letting a user resize text or increase contrast on demand, and genuinely limited at others, like reliably fixing a form that lacks proper programmatic labels or restructuring a page’s reading order for a screen reader. Automated features like AI-generated alt text add a further wrinkle: a generated description can be reasonably good for a simple product photo and clearly wrong for a complex image, with no human reviewing the output before it ships to real users.

There’s also a more specific technical complaint that comes up repeatedly in practitioner feedback: some overlay behaviors interfere with assistive technology a visitor has already configured on their own device or browser, effectively overriding a setup the user built deliberately. For someone who has already tuned their screen reader or browser extensions to work the way they need, an overlay stepping in and changing behavior can be actively counterproductive rather than neutral.

Broader data on the state of the web reinforces why this gap matters so much in practice. The 2026 WebAIM Million report found 95.9% of home pages had at least one detectable WCAG 2 failure, averaging 56.1 errors per page. If a site is carrying that many underlying issues, a display-layer widget addressing a handful of surface problems is working against a much bigger gap than its marketing usually implies, which is part of why the research consistently shows practitioners rating overlay-only coverage so low.

The regulatory dimension

This isn’t purely a debate among practitioners anymore; it has regulatory teeth now too. In 2025 the U.S. Federal Trade Commission ordered accessiBe to pay $1,000,000 to settle charges that it made misleading claims about how much of a website accessWidget could automatically fix, along with separate allegations about paid customer reviews. That settlement is a meaningful data point precisely because it’s not just advocacy criticism, it’s a federal enforcement action specifically targeting overreach in how automated remediation was marketed.

The significance of that settlement extends beyond the specific company involved. It sets a precedent that regulators are willing to scrutinize the gap between what an automated accessibility tool actually does and how it’s marketed, which raises the bar for every vendor in the category to be precise about what their product covers and what it doesn’t, rather than leaning on vague “compliance made easy” messaging.

Where the “overlays don’t work” framing oversimplifies

It’s worth being precise here rather than treating the whole category as worthless, because that’s not quite what the research shows either. The strongest criticism in the data is aimed at overlay-only solutions marketed as delivering complete, automatic compliance. Vendors that pair a widget with actual manual remediation or human-reviewed testing are making a different and more defensible claim. Wawsome, for example, bundles its widget with a continuous monitor and a human-reviewed accessibility checker rather than shipping automation alone. AudioEye explicitly combines automated scanning with human-in-the-loop manual testing by accessibility specialists. WebYes takes a different tack entirely, building its WordPress-focused tooling around identifying issues for code-level fixes rather than selling overlay remediation at all, an approach that sidesteps the criticism by design.

The practical distinction worth drawing is between “automation as the entire solution” and “automation as one layer in a larger process that includes real human review.” The WebAIM survey data is a response to the first framing, not necessarily to the second, and treating every product with a widget component as equally suspect misses a real and meaningful difference between vendors in how they’ve built their offering.

What this means for choosing a solution

The research doesn’t say “never use a widget,” it says be skeptical of any vendor claiming a script install alone equals full compliance. When evaluating a tool, it’s worth asking specifically whether automated fixes are reviewed or supplemented by a human at any point, and whether the vendor is transparent about what the widget can’t fix rather than implying it handles everything.

A reasonable read of all this evidence together: if a vendor’s entire pitch is that installing their script alone satisfies WCAG or resolves legal risk, that claim doesn’t hold up against either the practitioner survey data or the FTC’s own findings about one prominent vendor in this space. If a vendor is upfront that their widget handles a specific, bounded set of improvements and pairs it with real human testing or remediation for the rest, that’s a materially different and more credible claim, one that’s consistent with how the underlying technology actually works rather than in tension with it.

Our guide on what accessibility overlays can and cannot fix, and our comparison of widgets versus manual audits, both go deeper into how to evaluate a specific vendor’s actual claims against what the underlying technology can realistically deliver.