Fourteen months later, they get a second letter. Same law firm, different plaintiff, nearly identical complaint. The widget is still there, blinking away in the corner. Nothing about the actual site has changed.

If that sounds unfair, it isn’t really, and once you understand what these tools do and don’t do, it stops being surprising. This is one of the most common and most expensive misunderstandings in web accessibility, and it happens to well-meaning companies on both sides: the ones who bought an overlay thinking it was a fix, and the ones (much less often, but it happens) who assume anyone using one is trying to cut corners. Neither is quite right. We do manual website accessibility audits and remediation for a living, which means we spend a lot of time cleaning up after overlays that didn’t do what people thought they’d do, so let’s walk through exactly what’s going on, without the sales pitch and without the scare tactics.

What Is an Accessibility Overlay, Really?

Strip away the marketing, and an accessibility overlay is a small piece of JavaScript, usually one line of code you paste into your site’s header, that loads a widget on top of your existing page. Click the icon it adds (usually a person-in-a-circle icon parked in a corner), and a little menu pops open with toggles: bigger text, higher contrast, pause animations, a dyslexia-friendly font, sometimes a “screen reader mode” or “keyboard navigation mode.”

That’s genuinely what it does. It sits on top of your site like a sheet of tracing paper laid over a drawing. It can change how things look and, in some cases, add a few keyboard shortcuts. What it cannot do, because of how it works, not because of any lack of effort, is reach underneath itself and rebuild the drawing.

The Coat of Paint vs. the Frame

Here’s the mental picture that makes this click for most people we talk to: imagine your website is a house. The overlay is a fresh coat of paint and some nice curtains. Real remediation is inspecting the wiring, checking the plumbing, and making sure the doors actually open the way they’re supposed to.

A screen reader, the software blind and low-vision users rely on to have a page read aloud to them, doesn’t “see” your website the way sighted visitors do. It reads the underlying code: the HTML. It announces headings, links, form fields, and images based on what’s actually written into that code. If a photo on your site has no description written into it, a screen reader announces “image” or reads the filename, something like “IMG-4471.jpg”, no matter how much CSS or JavaScript is layered on top afterward. If a form field has no label connected to it in the code, a screen reader announces “edit text, blank,” and the visitor has to guess what they’re supposed to type. If your custom dropdown menu was built without keyboard support, a keyboard-only user gets stuck on it, trapped, unable to tab past it, and an overlay parked in the corner of the screen doesn’t reach into that menu and add the missing functionality.

This is the part that trips people up: an overlay operates in the browser, visually, after the page has already loaded. It can’t rewrite your source code. It can’t add an alt attribute that was never written. It can’t attach a label to a form field that was never coded with one. It can, at best, guess, and guessing is where a lot of the real trouble starts.

Why Many Overlays Try to “Guess” and Why That’s Risky

Some overlay tools go a step further than simple visual toggles: they use automated scripts to scan your page and try to guess missing information, writing alt text for images based on pattern recognition, or attempting to auto-label form fields based on nearby text. This sounds helpful, and sometimes it lands close enough. But automated guessing has no idea what a photo is actually for.

Picture a product photo on an online store: a red backpack, hanging from a hook, price tag visible. An automated guess might produce “person, red, indoors”, technically not wrong, but useless to a blind shopper trying to decide whether to buy the backpack. A human writing that alt text would say “Red canvas backpack with brown leather straps, front zip pocket visible”, because a person can look at the photo and understand why it’s on the page. Machines are getting better at description, but they’re still describing pixels, not intent. And intent is exactly what a blind visitor needs from your image descriptions.

The same problem shows up with form fields, buttons, and navigation menus. Software can pattern-match “this text is probably near that input box,” but it can’t know your business logic, your checkout flow, or which button is the important one on a page with twelve buttons. That context lives in your head, not in the pixels.

Why Screen Reader Users Often Turn Overlays Off Entirely

Here’s something that surprises a lot of business owners: many people who rely on screen readers actively avoid or disable overlay widgets when they encounter them. It’s not stubbornness, it’s self-preservation. Screen reader users already have their own assistive technology, configured exactly the way they like it, running on their own device. An overlay widget introduces a second layer of behavior into the page that can conflict with that existing setup: it can move keyboard focus somewhere unexpected, add extra clutter to the page structure the screen reader has to read through, or override settings the user already had configured to work well for them.

Disability advocates and accessibility professionals, many of whom are blind, deaf, or have motor disabilities themselves, have been vocal about this for years. It’s one of the more uncomfortable truths in this industry: a tool marketed as an accessibility solution is, for a meaningful share of the actual disability community, an obstacle they’ve learned to route around.

The Lawsuit Trend Nobody Expected

Here’s the twist that catches a lot of companies off guard: installing an overlay doesn’t just fail to fix the underlying problems, in a real and well-documented pattern, it has become one of the things plaintiffs’ attorneys specifically look for. Not because overlays are illegal (they aren’t), but because an overlay widget is a visible, public signal that a company was aware of accessibility as an issue and chose a fast fix over a real one. That’s a useful detail in a legal complaint. It’s much easier to argue “the company knew about accessibility barriers and did the minimum” when there’s a widget icon sitting in the corner of every page as evidence of that awareness.

We’re not going to hand you statistics we can’t verify, trends like this move, and the specific numbers your legal counsel would want are worth confirming directly with them or with current published litigation research. But the pattern itself is well known across the accessibility and legal communities: sites relying solely on an overlay have, in a number of documented cases, still been sued, sometimes by the very users the widget was supposed to accommodate, testing the site with their own assistive technology and hitting the same barriers that were there before the widget was installed.

The uncomfortable lesson: an overlay can create a false sense of security that’s worse than having no widget at all, because it can make a business feel finished when the actual barriers, the ones a screen reader user or keyboard-only user will actually run into, are still sitting there untouched.

To Be Fair: Where Overlays Genuinely Help

We don’t think overlays are a scam, and it’s worth saying that plainly, because a lot of accessibility content online swings too hard in the other direction. Used honestly, as an accessory rather than a fix, some overlay features are genuinely useful:

Text size and contrast toggles can help low-vision visitors who don’t use a screen reader at all, someone with mild vision loss who just wants larger, higher-contrast text doesn’t need your HTML rewritten, they need a bigger font, and a toggle can deliver that instantly. Pause-animation controls can genuinely help people with vestibular disorders or certain seizure conditions who are sensitive to motion. And for an organization that has a long roadmap of real remediation work ahead of it, six months of fixes queued up, a well-configured overlay’s surface-level toggles can be a reasonable stopgap for those specific visual preferences while the deeper work is underway, as long as nobody mistakes the stopgap for the destination.

The problem has never really been that overlays exist. The problem is when a business installs one, stops there, and believes the job is done.

What Standards Actually Measure

It’s worth knowing, briefly, what the actual yardstick is here, because it explains why an overlay can’t simply declare a site “compliant.” The core technical standard behind almost every accessibility law and policy, including Section 508 and the ADA, is WCAG, the Web Content Accessibility Guidelines. WCAG doesn’t grade websites on whether a widget is present. It’s a long list of specific, testable success criteria: does every image have appropriate text alternatives, does every interactive control work by keyboard, is contrast sufficient, does the page structure make sense to assistive technology, and dozens more in that vein. Meeting those criteria requires checking the actual page against each one, which is, again, exactly the kind of thing that has to happen at the code and content level, not the widget level. A business can have an overlay installed and still fail the majority of WCAG’s criteria, because the criteria and the widget are answering two different questions entirely.

Where Overlays Fall Down the Concrete List

So let’s get specific about what an overlay genuinely cannot fix, because “the code underneath” is a bit abstract until you see the actual list:

Missing or wrong alt text. As covered above, a script can guess, a human has to actually look and describe.

Unlabeled form fields. Every input on a form, name, email, phone, the little checkbox at checkout, needs to be connected in the code to a label a screen reader can announce. An overlay parked in the corner of the screen doesn’t reach into your checkout form and wire that up.

Keyboard traps and bad focus order. Try tabbing through your own site right now using only the Tab key, no mouse. If your cursor gets stuck inside a menu, jumps somewhere illogical, or disappears entirely, that’s a keyboard trap, and it locks out anyone who can’t use a mouse, whether due to a motor disability or a broken trackpad. This lives in how the menu was coded. No overlay reaches in and rewires it.

Custom widgets built without accessibility in mind. Date pickers, sliders, tabbed content, accordions, custom video players, if the developer who built these didn’t add the right ARIA roles and keyboard behavior, an overlay sitting on top of the page doesn’t retroactively teach that custom widget how to behave.

Captions and audio description on video. An overlay does not watch your videos and write captions for you.

PDFs and downloadable documents. A widget on your webpage does nothing at all for the accessibility of a PDF someone downloads from it. That’s a completely separate document format with its own set of tags and structure, a topic we cover in depth in our guide to manual PDF accessibility remediation.

Confusing structure and reading order. If your headings skip around illogically, or your page reads in a scrambled order to assistive technology even though it looks fine visually, that’s baked into the HTML structure, invisible to a widget that only touches the visual layer.

Color used as the only signal. If your error messages turn a field red with no accompanying text, or your “in stock” versus “sold out” labels are distinguished only by green versus red dots, colorblind visitors and screen reader users both lose that information. Fixing it means adding text or icons alongside the color, a content and code change, not a visual toggle.

Auto-playing or auto-advancing content. Carousels that rotate on their own, videos that autoplay with sound, notifications that vanish after a few seconds, all of these can be genuinely difficult for people with cognitive disabilities, attention-related conditions, or slower reading speeds to keep up with. An overlay’s pause-animation toggle helps only if a visitor happens to find and use it; the more reliable fix is building the pause control into the page itself, on by default or clearly visible.

Why This Confusion Keeps Happening

None of this is really the fault of business owners who’ve bought an overlay in good faith. A lot of the marketing around these tools is written to sound like a finished solution: “accessible in one line of code,” “ADA compliant overnight,” “automated compliance for one flat monthly fee.” Those phrases are appealing precisely because the alternative, a multi-week testing and fixing process, sounds slow and expensive by comparison. If you’re a busy owner who just wants the legal exposure to go away, “one line of code” is a genuinely tempting promise.

The trouble is that accessibility, like a lot of things worth doing properly, doesn’t compress down to one line of code, for the same reason “make the building safe” doesn’t compress down to one coat of fireproof paint. There’s real work underneath any real fix. That’s not a knock against the companies selling overlays, plenty of them are upfront in their own documentation about what the tool does and doesn’t cover. It’s more a case of marketing language moving faster than the fine print, and business owners reasonably assuming the simplest available option must be the complete one.

What Manual Remediation Actually Looks Like, Day to Day

So what’s the alternative, concretely? When we say “manual,” we mean a person sits down with your actual site or app and tests it the way a real visitor with a disability would experience it, not a scanner glancing at the code and flagging patterns.

A full keyboard-only pass. Mouse unplugged, or at least ignored. Tab, Shift+Tab, Enter, Space, arrow keys. Can you reach every link, button, and form field? Can you always see where the focus currently is, a visible outline or highlight? Can you get out of every menu and popup you get into? This single test alone surfaces an enormous share of real-world barriers, and it takes minutes to do by hand, yet it’s exactly the kind of thing an automated scan reliably misses or gets wrong.

A screen reader pass. A specialist navigates the page using screen reader software the way a blind visitor actually would, listening to how headings, links, images, and forms get announced, checking whether the reading order makes sense, and confirming that interactive elements say what they do (“submit button,” not “button”).

Zoom and reflow testing. Pages get zoomed to 200% and beyond to make sure text doesn’t get cut off, overlap, or force horizontal scrolling, a common problem for low-vision users who rely on browser zoom rather than a screen reader.

Real color contrast checks against real content, not just theme defaults, every text-and-background color pairing that actually appears on the page, including states like hover, focus, and error messages, checked against the WCAG contrast thresholds.

A cognitive and plain-language review. Is the instruction actually clear? Is there a wall of text where a short list would do? Confusing language and cluttered layout are accessibility barriers too, just less talked about than the technical ones.

PDF and document checks, where relevant, tag structure, reading order, and whether a screen reader can actually navigate the document sensibly rather than reading it as one unbroken block of text.

None of that can happen from a widget bolted onto the front end after the fact. It has to happen where the actual barriers live, in the code, in the content, and in the document structure.

The Honest Trade-off: Speed and Cost vs. Depth

We think it’s worth being straightforward about the trade-off here, because pretending there isn’t one wouldn’t be honest either. An overlay installs in minutes and costs a fraction of what manual remediation costs, because it’s changing almost nothing, it’s a script tag, not a rebuild. Manual remediation takes real specialist time, because a person is genuinely testing and then genuinely fixing dozens or hundreds of individual issues across your site.

That’s not a reason to skip the real work, it’s a reason to budget for it accurately and plan it in stages rather than expecting an overnight fix. Most of our clients don’t remediate an entire large site in one pass; they prioritize the pages and flows that matter most (checkout, account creation, core navigation) and work outward from there. It’s slower than a script tag. It’s also the only version of “fixed” that holds up when a real user with a real disability actually tries to use your site, or when a lawyer’s own tester does the same thing.

Can You Use Both Together?

Yes, and this is probably the most useful takeaway in this entire article: an overlay is not the enemy of accessibility work, it’s just not a substitute for it. The two can coexist perfectly well once the order is right. Fix the foundation first, the actual HTML, the labels, the keyboard behavior, the structure, through manual testing and remediation. Then, if your organization wants the extra convenience toggles (bigger text, higher contrast, reduced motion) for visitors who’d appreciate quick visual adjustments, layering a well-configured overlay on top of a genuinely accessible site is a reasonable, additive choice. It’s an accessory sitting on a solid foundation, not a coat of paint hiding a cracked one.

What doesn’t work, what we’d gently steer any client away from, is treating the overlay as the whole plan. If your accessibility strategy consists of one script tag and nothing else, the foundation was never addressed at all, and the accessory is doing all the talking.

A Few Things You Can Check on Your Own Site Right Now

You don’t need to be technical to spot some of the more obvious gaps yourself, and doing this costs nothing but a few minutes:

Unplug your mouse (or just set it aside) and press Tab. Work your way through your homepage using only Tab, Shift+Tab, and Enter. Does the cursor ever vanish, or get stuck somewhere you can’t escape? That’s worth flagging.

Zoom your browser to 200% (Ctrl/Cmd and the + key a few times) and look at your key pages. Does anything overlap, get cut off, or force you to scroll sideways to read a sentence?

Right-click a few important images and check for a description, or view your page’s source and search for “alt=” near an image tag. An empty alt=”” is fine for purely decorative images, but a product photo, a headshot, or an infographic with nothing there is a gap.

Try filling out your own contact or checkout form using only the keyboard, and notice whether you can tell, without looking too hard, what each field is asking for.

None of this replaces a full professional audit, there’s a lot a non-specialist eye won’t catch, especially around screen reader announcements and code-level structure, but it’s a genuinely useful five minutes, and it’ll usually tell you within the first sixty seconds whether your site’s accessibility work has actually happened or just been painted over.

Where This Fits Into a Real Accessibility Plan

If that quick check turned up problems, or if you already suspect your current setup is doing more decorating than fixing, a full manual accessibility audit and remediation project starts by testing your actual site the way we described above, then fixing what’s found, prioritized by impact rather than by whatever’s easiest. We’re not going to tell you an overlay is worthless, we’ve just told you exactly what it can and can’t do, and where it fits (as an accessory, after the real work, not instead of it). What we do all day is the “before it” part: the testing, the labeling, the keyboard fixes, the structure work that actually holds up when a real person with a real disability shows up to use your site.

Frequently Asked Questions

Is having an overlay on my site illegal?

No, there’s nothing illegal about using an overlay widget itself. The legal risk comes from relying on it as your only accessibility measure while the underlying barriers remain. An overlay is a tool, not a compliance certificate.

Should I remove my overlay?

Not necessarily. If it’s providing genuine value, text size or contrast toggles some of your visitors use, there’s often no reason to rip it out. The more important question is what’s happening underneath it: has your site actually been tested and fixed, or has the overlay been standing in for that work? Answer that question first.

How do I know if my site is relying only on an overlay?

A quick way to check: try the keyboard-only and zoom tests above with the overlay’s own toggles turned off, using the site exactly as it would look to a first-time visitor who’s never touched the widget menu. If you find keyboard traps, unlabeled forms, or images with no description once the overlay is out of the picture, that’s the underlying site talking, and that’s what a screen reader user or keyboard-only visitor actually experiences most of the time anyway, since not everyone even discovers or opens the widget menu.

What’s actually different about manual remediation versus what an overlay does?

An overlay changes how your page looks or behaves for a visitor with the widget open, without touching your site’s code. Manual remediation changes the code itself, the alt text, the labels, the keyboard behavior, the structure, so the site works correctly for every visitor, every time, whether or not any widget is present.

Isn’t manual testing a lot more expensive than an overlay subscription?

Usually yes, at least on the sticker price, an overlay’s monthly fee is small next to a remediation project, because the overlay changes almost nothing while remediation genuinely fixes dozens or hundreds of issues by hand. But it helps to compare like with like: an overlay subscription is an ongoing cost that never resolves the underlying barriers, while remediation work is typically a project that meaningfully reduces legal exposure and, more importantly, actually lets people with disabilities use your site. Many organizations tackle it in prioritized phases, starting with checkout, account creation, or whichever flows matter most, rather than all at once, which keeps the real work manageable.

Curious What’s Actually Going on Under Your Own Site?

Whether you already have an overlay installed and want an honest read on what it’s covering up, or you’re starting from scratch and trying to figure out where to focus first, our team can tell you, in plain language, with specifics, not a generic scan report. Start with a free accessibility audit to see exactly where your site stands, take a look at our pricing for full remediation projects, or explore our manual website audit and remediation service to see how the process works from the ground up.