What a script can change, and what it cannot
Accessibility overlays: what they fix, what they hide, what they cost you.
An overlay is one line of JavaScript that promises compliance. It is worth understanding exactly what that line can do to a page, what it cannot reach, why the people it claims to serve tend to switch it off, and what a regulator does when it finds one on a site that is the subject of a complaint. This page is not a campaign against a product category; it is a description of where the boundary of the technology sits.
We do not sell a widget. We test, document and sign.
How an overlay actually works
Two things happen when the script loads. First, a toolbar appears, usually as a floating button, offering the user a set of adjustments: larger text, higher contrast, underlined links, a reading mask, sometimes a text-to-speech reader. Second, the script scans the page and injects attributes it believes are missing: alternative text guessed from file names or from an image classifier, ARIA roles applied to elements that look like buttons, labels attached to inputs by proximity.
The first part is a preferences panel. It is a genuine convenience for some users with low vision, and there is nothing wrong with it except that browsers and operating systems already provide most of it, better configured and available on every site rather than one.
The second part is the problem. Guessing at meaning from markup is unreliable by nature: the script cannot know that the icon leads to the cart rather than to a wishlist, that the red border means the postcode was rejected, or that the third heading is really a caption. When the guess is wrong, the user is told something false with the full confidence of the accessibility layer, which is worse than silence because silence at least invites exploration.
Where the boundary sits, criterion by criterion
| Need | Can a script address it? | Why |
|---|---|---|
| Text size and spacing | Partly | Already available in the browser, and a site that reflows correctly needs no help |
| Colour contrast | Partly | Inverting colours can break brand and readability elsewhere on the same page |
| Alternative text | Unreliably | A classifier describes what is in the image, not what it means in context |
| Names and roles of controls | No | Requires knowing the intent of the component, which only the developer has |
| Keyboard operability | No | Focus order and trapping come from the DOM and the event handlers |
| Form error handling | No | The association between message and field has to be built in |
| Reading order | No | Determined by the source order, not by visual position |
| Media captions | No | Requires a transcript produced and checked by a person |
Four of these eight are where real complaints come from. That is the practical answer to whether a widget discharges the obligation.
What the people it claims to help report
The strongest evidence is not from standards bodies but from the users themselves. Successive surveys of screen reader users have found low willingness to enable these tools and frequent reports of interference: a toolbar that takes focus on load, announcements duplicated by the injected layer, keyboard shortcuts that collide with the ones the screen reader already uses.
The pattern is consistent, and it has a simple explanation. Someone who uses assistive technology daily has spent years configuring it: voice, rate, verbosity, shortcuts, a braille display. A script that redefines the page underneath that configuration is not an improvement; it is an unpredictable variable on one site out of a thousand.
How this looks to a regulator
Under the European Accessibility Act the assessment is of the service. The question asked is whether a consumer can perceive, operate and understand it, and whether the statement describes the reality. A script is part of the service being assessed, not a defence against the assessment. If the checkout cannot be completed with a keyboard, the presence of a toolbar changes nothing about the finding.
In Ontario the same logic applies through O. Reg. 191/11, which references WCAG directly. In the United Kingdom the question in a dispute is what reasonable adjustments were made, and a subscription to a third-party script is unlikely to be the answer a tribunal is looking for.
Worse, when the overlay vendor's marketing has been repeated in your own accessibility statement, the statement now contains a claim that the testing will contradict. That is the situation described on the statement example page: a credibility problem created on top of a technical one.
What to do instead, in order
- Find out what your users actually meet. Run the free scan, then a manual audit. Until then every discussion about overlays is theoretical.
- Fix the blocking issues. There are usually between two and six, they are specific, and they are the ones that stop a purchase.
- Decide about the widget with data. If it interferes, remove it. If it does not, it is a preferences panel and it is your call.
- Publish an honest statement. Partial conformance with named exceptions, dated, signed, verifiable.
- Keep testing. Monthly, because the site changes and the statement has to keep up.
The EAA checklist sets out the evidence file this produces, and the audit page explains what the five days of testing cover.
The budget argument, honestly
Overlays sell on price and speed: a few hundred a year, live this afternoon. Against that, an audit plus development time looks expensive, and for a small brochure site the arithmetic can genuinely favour doing nothing and fixing complaints as they arrive.
For anything transactional the arithmetic changes. A checkout that cannot be completed with a keyboard is not a compliance abstraction: it is a customer who leaves, every day, silently. Nobody writes to tell you. The cost of the audit is fixed and known; the cost of the barrier is unknown and recurring, which is precisely why it survives so long in so many companies.
Our plan bundles the testing, the statement, the feedback channel, the monthly re-test and five years of records into one annual price, so the comparison is like for like: 690 € a year for the European Union, 890 CAD for Canada, 1,290 € for three domains and six languages, 1,990 € for all three regions together.
Three conversations this usually starts inside a company
Marketing bought it, engineering never heard about it
This is the most common origin story. A compliance email arrives, a deadline is mentioned, somebody searches, and a subscription is signed the same week without a single developer in the thread. Nothing is malicious about it: the promise on the vendor page is written exactly for the person under that pressure. The damage is that the organisation now believes the problem is solved, so the real work never gets scheduled, and the discovery happens a year later when a customer or an authority writes.
The agency says it is enough
Agencies are not lying either, in most cases. They are answering the question they were asked, which was how to get an accessibility badge onto the site before launch. Ask a different question — what would a keyboard-only user find in our checkout — and the answer changes immediately, because a good agency knows perfectly well what a script can and cannot reach.
The board wants a number
Boards ask what the exposure is, and there is no honest single figure: penalties are national, complaints are unpredictable, and lost sales are invisible. What can be given honestly is a state of affairs: how many blocking barriers exist today, what each of them prevents, what it costs to remove them, and what the documentation looks like if a letter arrives tomorrow. That is the report an audit produces, and it is a better board paper than any risk score.
One more thing worth putting in front of a board: the obligation cannot be transferred. Whatever the vendor contract says, the operator of the service remains the party an authority writes to and the party a consumer complains about. A supplier can be liable to you in contract, which is a separate and slower matter, but the letter still arrives at your address and the answer still has to describe your website.
If you keep the widget, say so in the statement
There is a legitimate way to run an overlay alongside a compliant site, and it takes one sentence. The statement describes the site as tested, lists the open barriers, and then notes that a preferences toolbar is available, describing what it offers. What it must not do is present the toolbar as the reason the site is accessible. Written that way, the widget is what it actually is, a convenience feature, and nobody reading the document is misled about where the conformance comes from.
Overlay questions, answered without marketing
What is an accessibility overlay?
A third-party script added to a website that changes appearance and behaviour at run time and offers a toolbar of adjustments such as larger text, higher contrast or a reading guide.
Do overlays make a site compliant?
No. They do not change the underlying structure that assistive technology reads, and compliance is assessed on the service, not on the script sitting on top of it.
Why do vendors claim otherwise?
Because the claim sells. Read the contract rather than the landing page: most disclaim legal outcomes in the terms while promising them in the marketing.
Do screen reader users like them?
Surveys of screen reader users have repeatedly found low satisfaction and frequent interference with the configuration people already rely on.
Can an overlay make things worse?
Yes. Injected ARIA that contradicts the visible state, focus stolen by the toolbar, and duplicated announcements are all common.
Is a widget useful for anything?
A preferences panel can help some users with low vision or dyslexia. That is a feature, not a compliance measure, and it should be built into the site.
What do authorities say?
Enforcement bodies assess the service against the standard. No regulator accepts a script as evidence of conformance.
Have overlays been litigated?
Sites using overlays have been sued in the United States, which is the jurisdiction with the most private accessibility litigation.
If I already have one, should I remove it?
Test first. Our audit tells you whether the overlay is actively breaking something. Many sites keep it and fix the structure underneath.
Does an overlay affect your audit?
We test what your users get. If the overlay interferes, that is a finding like any other.
Is automated remediation ever enough?
For a narrow set of defects it helps. For structure, names, roles, focus order and error handling it cannot substitute for code changes.
What about the cost comparison?
An overlay is an annual subscription with no fix behind it. The same budget spent on testing plus targeted development leaves you with a better site.
Will removing it break anything?
Rarely. It is a script tag. The barriers it was hiding were already there.
What should I tell my board?
That the obligation is on the service, that a script cannot discharge it, and that evidence of testing is what answers a complaint.
Do you sell an overlay?
No. We test and sign. If we sold a script we would have an incentive to tell you the structure does not matter.
What replaces the overlay?
Testing, a prioritised fix list, real changes in the code, and a statement that describes the result honestly.
How long does that take?
Five business days for the audit and the statement. The development work depends on the findings; blocking issues are usually few and quick.
What does it cost?
690 € a year for the EU, 890 CAD for Canada, 1,290 € for three domains and six languages, 1,990 € for all three regions.