Overlays and accessibility widgets
Why an accessibility overlay is not a fix
An overlay is a line of JavaScript you paste into a site. It promises accessibility without touching the code, and it sells well because that is exactly what a worried client wants to hear. This page explains what it actually does, why it cannot do most of what is claimed for it, and where a widget of this kind is genuinely useful.
We describe the category, not any particular vendor. Information for agencies — not legal advice.
What an overlay does
Mechanically, an overlay is a script tag. When a visitor loads the page, that script runs in their browser and does two kinds of thing.
It adds a control panel. A floating button opens a menu of visitor preferences: larger text, more line spacing, a high-contrast theme, a reading guide, an option to stop animations, sometimes a text-to-speech reader.
It rewrites parts of the page. The script inspects the DOM after it loads and tries to patch what it finds — adding ARIA roles it infers from the markup, guessing alternative text for images, adjusting colours whose contrast it can measure, attaching keyboard handlers to elements that have none.
The first half is a legitimate feature. The second half is where the claims come from, and where the trouble starts.
The code is unchanged
This is the whole argument, and it is worth being precise about it. The overlay runs after the page arrives, inside one visitor’s browser. Your server still sends the same HTML. The button with no accessible name is still a button with no accessible name; a script is standing next to it at runtime trying to describe it.
Three consequences follow directly:
- Nothing is fixed for anyone the script does not reach. If it fails to load, is blocked, is slow, or errors on a page it did not expect, the site reverts to what it always was.
- The problem is not shrinking. Every sprint adds more markup on top of the same patterns. Remediation gets more expensive the longer the overlay hides it.
- You have no record. When your client is asked what they did about accessibility, “we bought a widget” is not an answer with any evidence in it.
Why it cannot fix most WCAG failures
A large share of the WCAG success criteria depend on what the content means, and meaning is not recoverable from the DOM. A script can see that an img has no alt; it cannot know that the photo shows the blue variant of the jacket in size M. Automatic descriptions of images produce plausible sentences, and a plausible wrong sentence is worse for a screen reader user than a missing one, because they have no way to tell.
The same limit applies right across the standard:
- Custom widgets. A hand-built date picker, carousel or modal needs correct focus management, state and keyboard behaviour. That is application logic; it cannot be inferred from outside.
- Reading and focus order. If the DOM order does not match the visual order, no runtime patch knows which one was intended.
- Media. Captions, transcripts and audio description are content somebody has to produce.
- Link and error text. Twelve links reading “read more”, or an error saying “invalid input”, are wrong at the source. A script cannot invent the missing meaning.
- Text inside images. Contrast in a rendered image or a background is not something the DOM can restyle.
There is a further problem that only affects the people the overlay is sold for: it can collide with the assistive technology the visitor already uses. Screen reader users have tuned their software over years. A script that injects ARIA, moves focus or intercepts keyboard shortcuts can make a page harder to use than it was, and the user cannot switch it off before it has already interfered.
Why overlays attract complaints
Accessibility overlays are frequently the subject of complaints and litigation. The mechanism is not mysterious: the widget is highly visible, the barrier behind it is still there, and the gap between the marketing claim and the visitor’s experience is the complaint.
A badge saying a site is accessible, on a site where a disabled user could not complete the checkout, does not help the defence. It documents that the operator was told about the obligation and chose a product over a fix.
Side by side
The comparison is not overlay versus Rampsight — it is a runtime patch versus a change in the source. We sell the monitoring that makes the second one manageable, which is the interest we have in the answer.
| Aspect | An overlay widget | Fixing the code |
|---|---|---|
| What it changes | The rendered page in one visitor's browser, after it has loaded. The HTML your server sends is byte-for-byte the same as before. | The templates, components and content themselves. What every visitor, every browser and every testing tool receives is different. |
| Who has to act | Usually the visitor. Many features only apply once somebody notices the widget, opens it, and picks the setting that matches their impairment — before they have been able to read the page. | Nobody. The page works on arrival, with whatever assistive technology the visitor already runs and has already configured to their liking. |
| Evidence for the client | A subscription and a badge in the corner. There is no list of what was wrong, what changed, or what is still broken. | A dated report naming every failure, the pages and elements it was found on, the severity, and the score before and after the fixes. |
| Effect on the codebase | None. The failures stay in the source, and a third-party script now runs on every page — one more dependency, one more thing that can break or slow the site down. | The failures leave the source. A fix in a shared header or form component removes the failure from every page that uses it. |
| What the next release does | Nothing visible, which is the problem: a new inaccessible component is simply overlaid too, and nobody is told. | A release can reintroduce failures — that is exactly why scheduled scans exist. You find out in the same week, not at the next audit. |
| Cost over time | A recurring licence fee with no end and no reduction: the underlying debt is the same in year five as in year one. | Front-loaded remediation that shrinks as the design system improves, plus a small ongoing monitoring cost. The asset that gets better is the client's. |
| If somebody complains | The widget is on the page and the barrier is still there. The vendor is not the party being asked to explain. | You can show what was found, when, what was fixed, and what is still open with a date against it — which is what an accessibility statement is supposed to contain. |
Where a widget genuinely helps
It would be dishonest to say a preference panel is worthless. On a site that is already accessible, a user preference layer is a real convenience: bigger text, wider line spacing, a calmer colour theme, animation switched off, a reading guide. Some visitors — particularly people with dyslexia or low vision who are not screen reader users — genuinely like having those controls on the page rather than buried in browser settings.
A widget of that kind is fine when all of this holds:
- Included: The site already passes WCAG A and AA without it — the widget adds convenience, not conformance.
- Included: It only changes presentation. It does not inject ARIA, rewrite semantics or take over keyboard handling.
- Included: The widget itself is keyboard accessible, announced properly, and can be dismissed.
- Included: It is described as a preferences panel, not as compliance, and no badge claims otherwise.
It stops being fine the moment it is bought instead of the work, or the moment it starts guessing at meaning. The test is simple: turn the script off and scan the site. Whatever the report says with the widget disabled is what your client actually has.
What to do instead
The alternative is not a heroic rebuild. It is an ordinary engineering loop, and most of the wins are in shared components.
1
Measure the site as it is
Crawl up to 100 to 1000 pages with a real browser, depending on your plan, test each against the WCAG 2.2 A and AA rules, and record the score. Now the conversation has a number in it instead of a worry.
2
Fix by severity and reach
Each failure names the pages, the CSS selector and the element. Start with the ones in shared templates and components: one fix, every page. Push them to Jira if that is where your work lives.
3
Re-scan and publish
Watch the score move, then publish an accessibility statement that says what conforms and what does not yet. What a statement must contain.
What this page is, and what it is not
Automated testing finds a real but partial share of the WCAG success criteria. Whole families of requirements — whether alternative text actually describes the image, whether a custom widget can be driven with a keyboard and announced sensibly, whether an error message helps — can only be judged by a person. No automated tool can prove conformance, and Rampsight never certifies, guarantees or ensures it. What a scan gives you is evidence: located failures, tracked over time, that you can hand to a developer.
This page is information for web agencies and their clients, written in plain language. It is not legal advice. For a binding view of your own obligations, ask a lawyer qualified in the country where your client sells.
Questions clients ask about overlays
- Our client already pays for one. Do we rip it out?
Not necessarily on day one. Scan the site with the script disabled so you know the real position, then decide. If it is only a preferences panel and the site is otherwise sound, it can stay. If it is being relied on as the compliance answer, that reliance is the thing to remove first.
- Isn't a widget cheaper than remediation?
In the first year, usually. Over the life of a site it is a fee that never stops and never reduces the underlying debt, while remediation is effort that shrinks each time the design system gets better. The asset that improves belongs to your client.
- Do overlays make the site worse?
They can. A script that injects ARIA, moves focus or captures keyboard shortcuts can interfere with the screen reader a visitor has already configured, and it adds a third-party dependency on every page. That is a risk that lands on exactly the users it was bought for.
- Which overlay vendor do you mean?
None in particular, and we are not going to name one. The argument is about what a runtime script can and cannot do, and it holds regardless of who wrote it.
- So is Rampsight the fix?
No — your developers are. We are the measurement: we find the failures, locate them, track them over time and produce the statement, so the fixing is prioritised and provable. We do not change a single line of your client’s code. What the product actually does.
See what a site looks like without the widget
Add a client site, run a WCAG 2.2 A and AA scan, and get the real list of failures — located, prioritised, and reported under your own brand. 14 days free, no credit card required.