The overlay question security is rarely asked

A different question

Accessibility overlays have been argued about for years, and the argument has one shape. Do they work? Do they actually fix Web Content Accessibility Guidelines (WCAG) failures, or do they paper over them? Disabled users say they get in the way. Vendors say they help. Regulators have started to take a view.

I want to ask a different question, because I think it has been sitting in plain sight and belongs to a different department.

What is an accessibility overlay, structurally?

In the typical commercial pattern, it is a third-party JavaScript file, loaded at runtime from a vendor's content delivery network (CDN), with enough authority to read and rewrite your DOM — including the accessibility tree — on page load, for visitors who receive that script.

Write that sentence without the word "accessibility" and hand it to a security team. Watch what happens.

The vocabulary already exists

Security engineering has spent a decade building an apparatus for exactly this shape of risk, because it is the shape of many of the serious front-end incidents of the last ten years. Payment skimmers injected through compromised third-party scripts. Analytics libraries that quietly changed behaviour after an acquisition. Build-chain compromises where the vendor was fine and the delivery path was not.

The apparatus has names. Third-party script inventory. Subresource Integrity (SRI). Content Security Policy (CSP). Vendor security assessment. Egress monitoring. Incident response paths that assume a dependency, not your own code, is the thing that failed.

That vocabulary shows up far less often in overlay discussions than the efficacy debate does. Overlay products are usually evaluated in accessibility terms, by accessibility people, against accessibility criteria. Which is reasonable — that is who noticed the product category. But it means a script with broad DOM authority is often judged on whether it improves colour contrast, and much less often on what happens if it is compromised or silently changed.

This is adjacent to Magecart-era third-party risk and to ordinary CSP and SRI practice. Those disciplines already know how to talk about runtime scripts with write access to the page. What has been under-centred in overlay discourse is treating the product as that kind of dependency first, and as an accessibility intervention second.

Why the accessibility tree is a difficult surface

Every third-party script is a risk. This category is harder in a specific way, and the specificity is what makes it worth writing about.

A compromised analytics script can exfiltrate data. A compromised payment script can steal card numbers. Those are severe, and they are also often detectable — by monitoring, by users noticing, by fraud systems.

A compromised or altered overlay can change what assistive technology announces. That is a channel few organisations monitor as a security signal, consumed by users who cannot always cross-check the announcement against the visual rendering. A sighted developer looking at the screen may see one interface. A screen reader user may hear another.

Consider a concrete failure mode, offered as illustration rather than as a report of an incident: an injected accessible name on a login control, a changed focus order that skips an error message, or a suppressed status announcement after a form submission. A sighted quality assurance (QA) pass can still see a button labelled "Log in." An automated scan that runs against the raw HTML before the overlay script executes can miss what the user of assistive technology actually gets. A scan that runs in a browser after injection may see a different accessibility tree than your continuous integration (CI) pipeline sees against static markup. Timing and environment matter.

I am not aware of a documented incident of this kind, and I want to be careful not to imply one has happened. The point is narrower and, I think, harder to dismiss: this is an attack surface with a weak detection story relative to many other third-party scripts, and it is often installed specifically on sites whose owners have been told they have a compliance problem.

How it gets past the gate

The procurement path is the interesting part.

An overlay is usually bought under a compliance line item, often urgently, often after a demand letter or an audit finding. It is framed as risk reduction. That framing can route it around the review it would otherwise get: a third-party script with this much authority, procured as an engineering dependency, would normally attract a security assessment, a CSP review, and a question about what happens at renewal.

Bought as compliance, it may attract few or none of them. The buying path treats the purchase as closing a point-in-time accessibility gap. What the organisation actually installs is a continuous runtime dependency — a script that keeps executing, updating, and reshaping the accessibility tree after the invoice is paid. Point-in-time compliance closure and sustained third-party script risk are not the same job, and they often sit in different budgets.

The organisation may reduce one measured risk and take on an unmeasured one, without a single owner whose remit covers both.

What to actually ask

If your organisation runs an overlay, or is being sold one, these are questions with concrete answers. None of them requires taking a position on whether overlays work.

• Is it in the third-party script inventory? If your organisation maintains one and the overlay is not on it, that gap is the finding, whatever you conclude about the product.
• What is the Content Security Policy posture? Overlays typically need broad permissions to function. Document what you granted and why.
• Can you use Subresource Integrity? Often not, because these scripts update dynamically — which is precisely the property that makes SRI difficult or impossible and the risk real. If the answer is no, that is worth writing down rather than glossing.
• What is the vendor's security posture? The same questions you would ask any supplier with code execution rights in your users' browsers.
• What is the exit plan? If the vendor is breached, acquired, or shuts down, what is the removal procedure and who runs it? At 3am?
• Who owns it? If the answer is "compliance," ask who monitors it as software.

A workable baseline is not exotic. The overlay appears in the third-party inventory. An engineering owner is named. CSP exceptions are documented with a review date. There is a removal runbook that does not depend on the vendor's support channel being available. If you cannot point to those four things, the security conversation has not started yet — regardless of what the accessibility conversation concluded.

The wider point

I do not think accessibility teams should have to become security teams. I think the two conversations have run in separate rooms for too long, and this is one place where the separation has a cost that neither room can see on its own.

Accessibility people evaluate overlays on whether they work. Security people may never be asked, because the thing was filed under compliance. The result can be a category of third-party script that escapes a review it would not otherwise escape — not necessarily through anybody's failure, but through a gap between two disciplines' remits.

Asking the security question does not settle the efficacy question. But it is a question your organisation can answer this week, and the answer is useful whichever side of the overlay argument you are on.

Disclosure: For transparency, I used Claude to help structure this piece. The final content, observations, and conclusions are my own.

Sanjay C. builds evidence and small tools for open source accessibility review — including how accessibility contributions are checked, recorded, and maintained. He writes and researches independently from Bengaluru; more at ecogetaway.github.io.