Overlay vs manual remediation is the choice between a third-party script that tries to patch accessibility issues at runtime and a real fix to your site’s code and content. Overlays mask problems for some users; manual remediation removes them for everyone — and only the second approach reliably reaches WCAG 2.1 AA and holds up legally.
The short version
If you have ten minutes, here’s the whole argument: an accessibility overlay is a band-aid that a screen-reader user can often see right through, while manual remediation is the surgery that actually closes the wound. One is a recurring subscription that leaves your barriers in place; the other is a project that resolves them at the source. Courts, the DOJ, and — most importantly — your disabled visitors care only about whether the page works, not whether a widget is installed.
This page lays the two approaches side by side so you can see exactly where they diverge.
What each approach actually does
Accessibility overlays (sometimes called accessibility widgets) are products like accessiBe, UserWay, and AudioEye. You paste one line of JavaScript into your site, and the script attempts to detect issues — missing alt text, low color contrast, unlabeled form fields — and patch them in the browser, plus it offers a toolbar with font and contrast controls. Nothing in your actual code changes.
Manual remediation is the work an accessibility engineer does to fix the underlying HTML, CSS, JavaScript, and content. That means writing meaningful alt text, correcting heading structure and landmarks, adding proper ARIA labels and roles, making every control reachable by keyboard navigation, and verifying the result with real assistive technology — the same screen readers (NVDA, JAWS, VoiceOver) your visitors actually use. The fixes live in your codebase permanently.
The difference is structural: an overlay is a layer on top of a broken page; remediation makes the page not broken.
Head-to-head comparison
| Factor | Accessibility overlay | Manual remediation |
|---|---|---|
| WCAG 2.1 AA conformance | Partial at best; can’t fix most criteria (focus order, meaningful sequence, complex widgets, PDFs) | Full conformance is achievable and verifiable against each success criterion |
| Durability of the fix | Re-applied every page load; breaks when your site or the overlay updates | Permanent — the corrected code ships with your site |
| Screen reader / AT support | Frequently conflicts with NVDA, JAWS, VoiceOver; users disable it | Works with the user’s own tools, the way the POUR principles intend |
| Keyboard & focus management | Often hijacks or duplicates focus, creating new traps | Native focus order and visible focus, fixed in the markup |
| Legal defensibility | Named in hundreds of ADA suits; an overlay alone is weak evidence | A documented audit + remediation record is strong evidence of good faith |
| Coverage of content types | Misses images of text, charts, video captions, accessible PDFs | All content types can be addressed by hand |
| Cost over time | Recurring subscription forever; barriers persist; rework + legal risk stack up | One-time project; lowest total cost over a few years |
| Who it really serves | Marketed to owners worried about lawsuits | Built for the people actually using your site |
Why overlays fall short on compliance
Automated technology — whether it’s an overlay or a scanner — can only reliably catch a minority of WCAG failures. Industry testing consistently finds that automated tools detect roughly a third of issues; the rest require human judgment. An overlay can guess that an image needs alt text, but it cannot know whether your product photo should be described as “blue running shoe, side view” or skipped as decorative. It can’t fix an illogical reading order, an inaccessible custom date picker, or a video with no captions.
This is the same reason scanners alone aren’t enough, which we cover in automated vs manual accessibility testing. Detection is not remediation, and partial detection is not compliance. The W3C’s Web Accessibility Initiative is explicit that conformance is judged on the delivered experience, not on tooling.
Why overlays often make things worse for real users
This is the part the marketing skips. People who rely on assistive technology have already invested years configuring NVDA, JAWS, or VoiceOver to their needs. An overlay that injects its own ARIA, reorders focus, or pops a toolbar over the page can:
- Announce the same control twice, or announce nothing where there should be a label.
- Steal keyboard focus into a widget the user never asked for, creating a new keyboard trap.
- Override contrast or font settings the user set at the operating-system level.
- Break silently when your site updates, with no one watching.
The disability community’s response has been blunt: many users actively avoid overlay sites, and projects exist solely to let them switch overlays off. When the tool meant to help is the thing being disabled, it isn’t accessibility — it’s a liability. WebAIM and other practitioners have documented these conflicts in detail.
The legal angle (not legal advice)
Under ADA Title III, federal courts have repeatedly treated business websites as places of public accommodation that must be accessible. Thousands of ADA web lawsuits and demand letters are filed in the US each year, and a striking number of defendants in that wave already had an overlay installed. An overlay’s presence has not reliably prevented suits — and in several matters, the overlay itself was cited as part of the problem.
What does help is a record: an independent accessibility audit, a remediation plan tied to specific WCAG success criteria, and — where you need to attest conformance to a partner or government buyer under Section 508 — a VPAT / Accessibility Conformance Report. That paper trail demonstrates good-faith, ongoing effort in a way a JavaScript snippet never can. If you’ve already received a demand letter, don’t rely on an overlay — talk to an attorney and start fixing the real issues.
This page is general information, not legal advice; your obligations depend on your specific situation.
Cost over time: the real math
Overlays win the first invoice and lose every one after that. A subscription is cheap monthly, but it renews indefinitely and never reduces your actual barrier count or your legal exposure — so the cost of risk keeps compounding on top of it. Manual remediation is a defined project: you pay to fix the root causes, the fixes stay fixed, and the only recurring spend is light monitoring to catch regressions as you publish new content. Across a typical three-to-five-year horizon, remediation is usually the lower total cost — see the breakdown on our ADA compliance cost page.
When does an overlay ever make sense?
Rarely, and never on its own. A widget’s font-size and contrast toggles can be a minor convenience layered on top of an already-remediated, conformant site. But it is a garnish, not the meal. If your underlying code fails WCAG, no toggle saves you — and you’d be paying a subscription to decorate a problem you still have to fix.
The Curbcut position
We’re an anti-overlay remediation company, and we’ll say it plainly: there is no shortcut to an accessible website. We fix the code by hand, test with the same screen readers your visitors use, and hand you a result that works whether or not any third-party script is running. If you want to see where your site actually stands, start with a free accessibility scan, then let us turn the findings into a real remediation plan.
Switching away from an overlay isn’t a loss — it’s finally fixing the thing the overlay was hiding.