Skip to content
wcagc
Create account
←Back to blog
overlayhonestyARIADOMWCAG

What an accessibility overlay actually does to your page

What accessibility overlays do technically: the script they load, the DOM they rewrite after load, and why your source code stays exactly the same.

P

Pavel Charkasau

What do accessibility overlays do to your page, technically? They add a third-party JavaScript file that runs in each visitor's browser after your HTML has loaded. The script reads the rendered page, guesses at problems, and edits the live DOM to patch them: it adds ARIA attributes, fills in missing labels or alt text, changes tab order, and usually injects a floating toolbar for font size and contrast. The Overlay Fact Sheet describes it this way: overlays run "a script to the page which scans the code and automatically attempts to repair the problem", and "these repairs are applied when the page loads in the user's browser" (Overlay Fact Sheet). Nothing in your repository changes. The server sends the same markup it always did, and the script repeats its guesses on every page load, in every browser. Some overlays also try to detect whether a screen reader is running and switch modes automatically. Below is each layer, and how to see it in DevTools yourself.

How does an overlay get onto the page?

Through one <script> tag, usually placed in the site template or added through a tag manager. It typically looks like this:

<script src="https://cdn.overlay-vendor.example/widget.js" async></script>

That tag loads a bundle from the vendor's servers. Once it runs, it renders its toolbar button and starts the code that scans and edits the page. The Fact Sheet's definition is plain: overlays "apply third-party source code (typically JavaScript) to make improvements to the front-end code of the website" (Overlay Fact Sheet).

Note the phrase "front-end code". The overlay never sees your templates, your components or your design system. It sees the DOM the browser built from them, which is the finished product, after your framework has already decided what a button is.

What does the script change in the DOM?

It edits attributes and elements after the browser has parsed your HTML. The exact changes vary by vendor, and I won't claim to know any one vendor's rule set. The general pattern is easy to see for yourself, though. Open a page that runs an overlay, then compare two views:

  • View source (Ctrl+U) shows what your server sent.
  • The Elements panel in DevTools shows the live DOM after scripts ran.

These are the kinds of differences to look for:

  • aria-label added to icon-only links and buttons, with text the script inferred.
  • alt attributes added to images that had none.
  • role attributes added to <div> and <span> elements, such as role="button" on a clickable <div>.
  • tabindex="0" added so elements can receive keyboard focus.
  • The toolbar itself, often inside its own container appended near the end of <body>.

If you want a precise list rather than eyeballing two views, paste this into the console before the overlay finishes loading (or after, and then trigger some navigation):

new MutationObserver((records) => {
  for (const r of records) {
    if (r.type === "attributes") {
      console.log(r.target, r.attributeName, "→", r.target.getAttribute(r.attributeName));
    }
  }
}).observe(document.documentElement, { attributes: true, subtree: true });

Every line it logs is a change your codebase does not contain. That is the whole product, from a technical point of view: a layer of edits that exists only while the script is running in that browser tab.

Why can't a runtime patch fix the real problem?

Because adding ARIA changes what a screen reader is told, not how the element behaves. The W3C's ARIA Authoring Practices Guide states it directly: "Unlike HTML input elements, ARIA roles do not cause browsers to provide keyboard behaviors or styling" (W3C APG). It calls ARIA "a CSS for assistive technologies", and the comparison is useful. Like CSS, it changes presentation. It doesn't change behavior.

Take the most common case, a clickable <div>:

<div class="buy" onclick="addToCart()">Add to cart</div>

An overlay can add role="button" and tabindex="0". Now a screen reader announces "Add to cart, button", and Tab can reach it. But a native <button> also fires on Enter and Space. The <div> still only listens for click. Unless the script also attaches key handlers that call your function correctly, the user hears "button", presses Enter, and nothing happens. That is arguably worse than before, because the page now promises something it doesn't do.

WCAG 2.2 success criterion 2.1.1 requires that "all functionality of the content is operable through a keyboard interface" (WCAG 2.2), and 4.1.2 Name, Role, Value requires that the role you expose matches what the component does (Understanding 4.1.2). A label added from outside can satisfy the first half of 4.1.2 while breaking the second.

Then there are the guesses. A script that adds alt text to a product photo can say "a person wearing a blue jacket". It can't know the photo exists to show that the jacket comes in navy, or that a chart image needs the numbers it plots. An inferred aria-label on an icon button can read the class name btn-x and guess "close". It can just as easily guess wrong. The guess is the weak point: the script has the markup but not the intent behind it.

Does more ARIA make a page more accessible?

Not on the evidence. The WebAIM Million 2026 report, which tests the home pages of the top one million websites, found that "home pages with ARIA present had significantly more errors (59.1 on average) than pages without ARIA (42 on average)" (WebAIM Million). That is a correlation, and it doesn't single out overlays. But it fits what experienced developers already know. The second rule in the W3C's Using ARIA note is "Do not change native semantics, unless you really have to" (W3C, Using ARIA). (That note was marked a Discontinued Draft in February 2026, but the rule is still standard practice.) An overlay is, by design, a tool for adding ARIA to pages whose authors didn't. That puts it right where the rule says to be careful.

What does the toolbar do, and what happens with screen readers?

The toolbar is the visible part, and the most harmless. The Fact Sheet notes that it gives "user-based control of things like font-sizes and colors to improve readability" (Overlay Fact Sheet). Under the hood, this is mostly CSS: the script adds a class to <html> or injects a stylesheet that overrides sizes, spacing and colors. People who need those adjustments usually already have them in browser zoom, operating system text scaling and forced-colors mode, and those work on every site.

The screen reader handling is the less visible part. According to the Fact Sheet, overlays that switch on settings automatically "do so by detecting when an assistive technology is running on the device", and some "persist users' settings across sites which use the same overlay" by "setting a cookie on the user's computer" (Overlay Fact Sheet). That raises a privacy question: whether someone uses a screen reader is information about their disability. It also means that when detection triggers a mode switch, the person using NVDA or VoiceOver now has two systems shaping the same page.

There is a performance cost too. The Fact Sheet notes the repairs "can either slow down page load times or cause unexpected page changes for assistive technology users" (Overlay Fact Sheet). In practice that means content can shift while someone is already reading it.

Overlay patch vs source fix: what's the difference in practice?

Overlay (runtime patch)Source fix
Where the change livesIn the visitor's browser, per page loadIn your repository
What it can seeThe rendered DOMYour components and their intent
Keyboard behaviorOnly if the script adds working handlersNative, e.g. a real <button>
Survives the script failing to load, or being blockedNoYes
Shows up in code review and Git historyNoYes

The last row matters most to me. If a fix isn't in your code, nobody can review it or stop it regressing.

What should you do with this?

Look at what the overlay changes, then make those changes properly in your source. That's the opinion behind how we built wcagc.com: the scanner reports issues and never touches your live page. I'd rather tell you that div.buy needs to be a <button> than hide it behind a script.

A workable order:

  1. Scan your pages with the overlay script removed or blocked, so you see the baseline the overlay was covering. Our free scan lists each WCAG failure with its element and selector.
  2. Use the MutationObserver log above as a to-do list. Each attribute the overlay adds points at a component that is missing something.
  3. Fix it in the component: native elements first, ARIA only where no native element fits.
  4. Test the parts no script can judge. Automated testing catches roughly 30 to 57% of issues depending on how you count; the top of that range comes from Deque's study of more than 2,000 audits (Deque). Alt text quality, reading order and whether a checkout makes sense with a screen reader need a person. The WCAG checklist separates the criteria that need manual review.
  5. Once the source covers what the overlay was patching, remove it. Our guide to switching from an overlay covers the steps.

The legal side points the same way. In the EU, the EAA presumes conformity through EN 301 549, which applies WCAG to web content. In the US, the ADA is applied with WCAG as the reference point. Each one asks whether the content works for the user, and none of them treats a widget as a fix. The FTC's April 2025 order against accessiBe bars the company from representing that its automated products can make any website WCAG-compliant without supporting evidence (FTC).

Frequently asked questions

What does an accessibility overlay do technically?

It loads a third-party script that edits your page's live DOM in the visitor's browser after the page loads. It adds attributes such as aria-label, alt, role and tabindex, and injects a toolbar that applies CSS overrides. Your source code and server output stay the same.

Does an overlay change my source code?

No. The overlay edits the copy of the page the browser built, on each page load. Compare View source with the DOM in DevTools and you'll see the difference only exists in the browser.

Can an overlay make a clickable div keyboard accessible?

Only partly, and only if its script adds working key handlers. Adding role="button" and tabindex="0" makes the element announced as a button and focusable, but ARIA roles "do not cause browsers to provide keyboard behaviors" (W3C APG). A native <button> handles Enter and Space without extra code.

Do overlays detect screen readers?

Some do. The Overlay Fact Sheet says overlays that enable settings automatically do so "by detecting when an assistive technology is running on the device", and some persist settings across sites with a cookie (Overlay Fact Sheet).

How can I see what an overlay changes on my site?

Use a MutationObserver in the browser console to log attribute changes, or compare View source with the Elements panel. Each change it logs is a fix that belongs in your components.

See your page without the patch

Want to know what your markup looks like to a screen reader with no script in between? Run a free scan. You get each issue with its WCAG criterion, element and selector, so the fix can go into your code. Then have a person test the journeys that matter with a keyboard and a screen reader, because a scanner can't judge those.

Written by Pavel Charkasau, founder of wcagc.com. Last updated 7 November 2026.

Sources