An accessibility overlay is a widget you add to a website with a single line of JavaScript, typically appearing as a small icon that opens a panel of display adjustments: bigger text, higher contrast, a dyslexia-friendly font, keyboard navigation helpers, and in more advanced versions, some automated attempts to add missing alt text or ARIA labels. It can meaningfully help with some issues, but it is not a substitute for accessible underlying code, and no credible vendor claims it closes every WCAG gap on its own.
How overlays actually work
Once installed, an overlay runs as a script layer on top of your existing site rather than changing your underlying HTML, CSS, or application code. When a visitor opens the widget panel, it applies display adjustments dynamically: enlarging text, boosting contrast ratios, changing fonts, pausing animations, or exposing a keyboard-navigation mode. More sophisticated overlays, including ones from vendors like accessiBe and UserWay, also run automated scans that attempt to inject missing accessibility attributes into the page in real time, such as generating alt text for images that lack it or adding ARIA labels to unlabeled interactive elements.
Because none of this touches your actual source code, an overlay’s effect disappears the moment the script fails to load, is blocked by an ad blocker or content filter, or a user’s browser doesn’t run it for any reason. That’s a meaningful architectural difference from a code-level fix: a properly labeled form field is labeled correctly no matter what script does or doesn’t load on top of it, while an overlay-applied label only exists while the overlay itself is actively running.
What overlays can genuinely help with
For a site with real budget or timeline constraints, an overlay isn’t nothing. It can quickly give users control over text size, contrast, and motion, which matters for people with low vision, light sensitivity, or vestibular conditions. Keyboard navigation enhancements can help users who don’t use a mouse. And for site owners with no in-house development resource, it’s a starting point that ships fast, often the same day, rather than waiting on a code-level remediation project.
There’s also a visibility benefit that’s easy to underrate: an overlay’s on-page icon is a visible signal to visitors that a business has thought about accessibility at all, and for some users, simply having a quick way to increase text size or reduce motion is a genuine improvement over a site with no adjustment options whatsoever, even if it isn’t a complete fix.
What overlays typically cannot fix
The limits show up around anything that depends on how content was actually built rather than how it’s displayed. A form field with no programmatic label, a custom dropdown menu missing the correct ARIA role and keyboard behavior, a video without captions, or a document structure that doesn’t expose a logical reading order to a screen reader: these are structural issues that a script layered on top of the page has limited ability to reliably fix for every case, especially on complex or frequently changing sites. Automated alt-text generation is a good example of the gap: an AI-generated description can be reasonably accurate for a simple product photo and clearly wrong for a complex chart or a culturally specific image, with no human checking the output.
PDF documents linked from a page are another common blind spot: a widget running on the HTML page it’s installed on generally has no ability to reach into a linked PDF and fix its internal structure, so a site can have a fully adjusted webpage sitting right next to an inaccessible PDF the widget never touches. The same is often true of embedded third-party content, like an iframe-embedded booking widget or payment form from a separate vendor, since an overlay typically can’t reach across that boundary either.
Why the category draws real criticism
This same architectural pattern is also why overlays tend to work inconsistently across browsers and devices in ways structural fixes don’t. A script-based adjustment can behave slightly differently depending on browser version, other extensions running on the page, or a site’s own JavaScript, whereas a genuinely accessible piece of markup behaves the same way for every visitor regardless of what else is happening in their browser.
Accessibility practitioners have been vocal critics of overlay-only approaches for years, and the data backs up that this isn’t a fringe view. A WebAIM survey covered by the Overlay Fact Sheet found that 67% of accessibility practitioners rated overlays as “not at all” or “not very” effective, and that number rose to 72% among practitioners who themselves have disabilities. Only 2.4% rated overlays as very effective. Part of the criticism is about marketing rather than the technology itself: when a widget is sold as a complete, one-line fix for legal compliance, it sets an expectation the underlying tool usually can’t meet, and in accessiBe’s case that gap between marketing claims and actual capability led the FTC to order a $1,000,000 settlement in 2025 over misleading claims about accessWidget’s automated remediation.
There’s also a more technical criticism: some overlay behaviors can interfere with assistive technology a user has already configured on their own device or browser, effectively overriding preferences the user set up deliberately, which is a frustrating experience for the people the tool is supposed to serve. WebYes, a WordPress-focused testing tool, is one vendor that positions itself explicitly against overlay-only remediation for this reason, arguing for code-level fixes instead.
Overlay, plugin, toolbar: the same thing under different names
Vendors use a few different terms for essentially the same category of product. “Accessibility widget,” “accessibility overlay,” “accessibility plugin,” and “accessibility toolbar” are all generally describing the same architecture: a script layer that adds display controls and, in more advanced products, some automated remediation attempts on top of an existing site. The variation in naming is mostly marketing, not a meaningful technical distinction, so it’s worth evaluating any of these products on the same criteria regardless of what the vendor happens to call it.
Where overlays fit into a realistic strategy
The overlay-versus-nothing framing misses the more useful question, which is what an overlay is paired with. Vendors like Wawsome and EqualWeb sell the widget alongside manual remediation, human-reviewed audits, or continuous monitoring rather than as a standalone product, which meaningfully changes what the combined offering can actually accomplish compared to a widget shipped alone. A widget paired with genuine human review closes more of the gap than automation running unsupervised, even though both technically fall under the same “overlay” label.
Before adopting one, it’s worth asking a vendor directly: does anything in this product involve human review at any stage, or is it fully automated end to end? Is there a clear, written statement of what the tool doesn’t cover? And is pricing and functionality transparent, or does the marketing imply broader coverage than the product documentation actually supports? Those questions do more to separate a genuinely useful tool from an overhyped one than the overlay-versus-no-overlay framing usually allows for.
If you’re evaluating whether an overlay is the right fit for your site, our guide comparing widgets to manual audits and our piece on whether overlays actually work both go deeper into the tradeoffs.