Why Accessibility Overlays Do Not Fix the Problem

The pitch for accessibility overlays is genuinely attractive: add one line of JavaScript, and a widget repairs your site for disabled visitors at runtime. If that worked it would be a remarkable piece of engineering and everyone should use it.

It is worth taking the claim seriously enough to work out exactly where it breaks, because doing so explains what accessibility actually requires better than a list of criteria does. We rejected building one permanently, and the reasoning is technical before it is anything else.

What accessibility overlays can genuinely do

Starting with the honest part, because dismissing accessibility overlays out of hand is not accurate either.

An overlay runs in the page after it loads and can modify the document. That gives it real capabilities: it can raise contrast by overriding colours, enlarge text, adjust spacing, add a visible focus indicator where the design removed one, and in some cases infer alternative text for an image from surrounding context or a filename.

It can also offer a user-facing panel of preferences, which some visitors do find useful. None of that is fraudulent, and a vendor describing those capabilities accurately is describing something real.

Notice what those capabilities have in common. Every one is a change to how existing content is displayed. The overlay is reading a page that already contains everything it needs and presenting it differently, which is a legitimate and sometimes valuable thing to do. The trouble begins when the page does not already contain what is needed.

Where accessibility overlays run out of road

Set the capability against the failures that actually dominate scans, and the mismatch is immediate. Each of the four below is common on practice sites, and none of them is a presentation problem.

An unlabelled form field. A widget can see an input with no associated label. It cannot know whether that field wants a date of birth, a preferred appointment time or a description of a symptom. It can guess from a placeholder if one exists, and guessing wrong on a medical intake form is worse than announcing nothing, because the visitor now confidently enters the wrong thing.

An unnamed frame. A scheduling iframe with no title is announced as "frame". The overlay cannot see inside it, for the same same-origin reasons discussed in the consent gap in embedded forms, so it cannot work out what the frame contains in order to describe it.

A carousel claiming a structure it does not have. When a page-builder widget declares a list role on a container whose children are not list items, the markup is actively lying to assistive technology. An overlay would have to understand the developer's intent to repair it, and repairing it wrongly compounds the problem.

A process that cannot be completed. The failure that matters most is a booking flow a keyboard user cannot finish. That is a property of the whole interaction, not of any single element, and nothing injected at page load addresses it.

The objection from the people it claims to help

The technical argument is enough on its own, and there is a second one that carries more weight: many screen reader users actively dislike these widgets and have said so publicly and at length for years.

The complaints are consistent. An overlay that detects assistive technology and switches to its own interface takes control away from someone who has spent years configuring their own tools. Keyboard shortcuts collide with the shortcuts the screen reader already uses. Injected ARIA fights the page's existing semantics and produces duplicated or contradictory announcements. And the widget itself becomes another thing to navigate past on every visit.

That is the part practices should sit with. The purpose of this work is that a person can book an appointment. If the people who use assistive technology report that a tool makes that harder, that finding outranks any vendor's description of what the tool is supposed to do.

That last property is worth stating plainly, because it is the argument that persuades finance rather than engineering. A remediated template is an improvement to an asset the practice owns. An overlay is a tenancy: it works while the subscription runs and the site reverts to its actual state the day it lapses. Two practices spending identical amounts over three years end that period in materially different positions, and only one of them has anything to show for it.

On the compliance claims made for accessibility overlays

Be careful here in both directions, because this is where the argument is usually overstated.

No product makes a website conform to a standard by being installed, and no honest vendor can promise otherwise. Conformance is a property of what a page delivers to a user, assessed against testable criteria in WCAG 2.1. If the underlying page fails a criterion, an evaluator examines the page.

The narrower and more useful point is this: an overlay does not change what an evaluation would find, so purchasing one to change that outcome is buying something the product cannot deliver. That is true regardless of how any particular vendor markets itself, and it does not require characterising anyone's conduct.

The same reasoning is why we say what we say about our own tooling. Scanning finds and documents. It does not confer a status, and a report from us is evidence of findings on a date rather than a certificate.

There is a practical reason to care about the distinction beyond honesty. If a practice believes a widget has resolved the question, it stops looking, and the pages that a patient cannot actually use stay unusable indefinitely because nobody has a reason to check. The most damaging property of a tool that promises completeness is not that its claim is wrong. It is that believing the claim removes the motivation to run the one test that would have revealed the truth.

That pattern recurs across compliance tooling generally, and it is the same failure mode as a consent banner that displays a notice without blocking anything: the visible artefact creates confidence, the confidence ends the enquiry, and the underlying behaviour is never examined. In both cases the correction is identical, which is to go and look at what the page actually does rather than at what was installed on it.

What to do with the budget instead

Accessibility overlays are typically sold as an annual subscription. Applied to actual remediation, that same figure goes a long way, because the work is more concentrated than people expect.

Start with shared design tokens. Contrast dominates instance counts and is usually a handful of colour values in a header, footer and button style. Then name every iframe, which is a one-line edit each. Then give icon links accessible names. Those three account for most of the volume on a typical practice site, as set out in the WCAG failures we find most.

Then do the thing no tool does: tab through your consultation booking from the top of the page to submission, without a mouse. If you cannot complete it, neither can a patient, and that single test tells you more than any score.

It is worth doing that test yourself rather than delegating it, once, because the experience is more instructive than a report. You will find out how many times you have to press tab before reaching the main content, whether you can tell where focus is at any given moment, and whether a modal traps you. Those are three of the most common reasons a booking is abandoned, and none of them is visible when using a mouse. Fifteen minutes on your own consultation page is the highest-value quarter hour available in this entire subject.

Finally, scan on a schedule rather than once, because pages get added and templates get updated. What matters at a deadline is a dated series showing findings identified and resolved, which is what accessibility monitoring produces, and it is the same reasoning behind keeping an append-only record on the consent side. Evidence of what was true on a date, produced repeatedly, is the artefact worth having. A widget is not.