The difference
What each one actually changes
The distinction is simple once you see it. An overlay works on the page after it loads. Remediation works on the page before it is built.
An overlay
A third-party script loaded at runtime. It adds a toolbar and tries to guess fixes by rewriting the page in the browser. Your source code is untouched, so if the script fails to load, is blocked, or the vendor goes away, the site returns to exactly what it was.
Remediation
Changes to your own HTML, CSS and JavaScript: real labels, correct roles and states, keyboard operability, managed focus, sufficient contrast, announced updates. The site is accessible whether or not any script runs.
The limits
What an overlay cannot reach
These are not edge cases. They are the failures I find on nearly every site I audit, and none of them can be fixed from outside the code.
It cannot give meaning to your images
An overlay can detect that an image has no alternative text. It cannot know that the photograph shows a navy raincoat with a drawstring hood. Some vendors use image recognition, which produces generic guesses like “person wearing clothing” and occasionally describes the wrong thing entirely with total confidence. Alternative text is an editorial decision about what the image is doing on that page.
It cannot repair custom components
A dropdown built from divs, a date picker with no keyboard support, a modal that does not trap focus, a tab set that does not respond to arrow keys. These need their roles, states and event handling rewritten. An overlay guessing at them from outside tends to make matters worse, because it adds ARIA on top of markup that does not support it.
It cannot fix reading order or structure
If your headings skip levels, if your visual order and DOM order disagree, or if your page is a stack of divs with no landmarks, a screen reader user gets a confusing experience. Structure is decided when the page is built.
It cannot write your error messages
“Invalid input” is a failure of communication, not of code. Telling somebody that the date must be in the future, or that the password needs a number, requires a person who knows what the form is for.
It cannot fix what it never sees
Overlays run in the browser. Content inside iframes, third-party checkouts, embedded booking systems, PDFs and native mobile apps are outside their reach entirely, and those are frequently where the money is.
The evidence
What the people affected actually say
The strongest argument against overlays does not come from consultants. It comes from disabled users and from the courts.
- Screen reader users object. Repeated surveys of screen reader users have found large majorities reporting that overlays make websites harder to use rather than easier, because the widget fights the assistive technology they already know. Many now block overlay scripts outright.
- Lawsuits continue regardless. Website accessibility claims have been filed against businesses running overlays at the time of filing. Installing one has not prevented litigation, and it is not a defence.
- Practitioners signed against them. Thousands of accessibility professionals, including many disabled practitioners, have signed a public statement opposing overlay products as a substitute for accessible design.
- Regulators are unimpressed. The Department of Justice rule for Title II names WCAG as the standard for the content itself. Nothing in it recognises a third-party widget as a route to conformance.
The honest version
When a widget is fine
This is not an argument against user preferences. It is an argument against selling them as compliance.
Preference controls you build yourself
A text size control, a contrast switch, a reduced motion toggle, a reading guide. Built into your own site these are genuinely useful, they respect the user settings already present in the browser and operating system, and they cannot conflict with a screen reader because they are part of your page rather than a layer above it.
An overlay kept as a stopgap, with the work still funded
If you have already paid for a year and remediation is scheduled, leaving it running while the real fixes land is a defensible position. The mistake is treating the subscription as the solution and cancelling the audit.
What to ask any vendor before you sign
Ask three questions in writing. Will you state that your product makes our site WCAG 2.2 AA conformant? Will you indemnify us against an accessibility claim? Can you show us a screen reader user completing our checkout using your product? The answers are usually instructive.
Instead
What remediation looks like
Audit with the overlay switched off
You cannot plan against a page a script is rewriting. Testing with it disabled shows the real state of your code, which is what a court, a procurement team and a screen reader all deal with.
Fix the structure first
Landmarks, heading order, labels, focus management and keyboard operability. These carry the most users and the most risk, and they are the ones an overlay never reached.
Fix the content, and write the rule
Alternative text, link names, error messages, captions. Then write down how new content gets published, so it stays fixed.
Re-test and publish a statement
Verify the fixes, then publish an accessibility statement recording what conforms, what does not yet, and what you are doing about it. That document is worth more than any widget.
FAQ
Overlays and remediation – frequently asked questions
What is an accessibility overlay?
An overlay is a third-party script you add to your site with one line of JavaScript. It layers a toolbar and a set of automatic adjustments on top of your existing code, offering things like contrast switching, text resizing and a screen reader mode. It does not change the underlying HTML your site is built from.
Do overlays make a website ADA compliant?
No, and reputable vendors are careful never to promise it in writing. An overlay cannot repair a custom dropdown built from divs, a form field with no label in the markup, a modal that does not trap focus, or a filter that announces nothing. Those failures live in your code.
Have businesses been sued while using an overlay?
Yes. Website accessibility claims have been filed against businesses that had an overlay installed at the time. Installing one is not a legal defence, and in some matters it has been raised as evidence that the business knew there was a problem.
Why do screen reader users dislike overlays?
Because most overlays try to take over the screen reader experience with their own controls, which conflicts with the software the person already knows. Surveys of screen reader users have repeatedly found large majorities reporting that overlays make sites harder to use, not easier. Many now block them.
Is there anything an overlay is good for?
A few of the user-preference features are genuinely useful: a font size control, a contrast toggle, a reading guide. The honest version of that is to build those preferences into your own site, where they cannot conflict with assistive technology. The problem is not the idea of preferences; it is selling them as compliance.
We already paid for a year of an overlay. What now?
Get an audit of the site with the overlay disabled, so you can see the real state of your code. Then decide whether to keep the overlay as a preference widget or drop it. Either way, the remediation work is the same, and it is the part that actually makes you compliant.
Is remediation really more expensive?
Over one year an overlay subscription often looks cheaper. Over three years, remediation usually wins, because fixes to your code are permanent and a subscription is not. Remediation also improves search performance and conversion, which a widget does not.
Find out where you stand
See what your site looks like without the overlay
Send your website address and I will reply in writing within one working day with the barriers present in your own code, tested with the widget disabled.