An accessibility overlay and a code-first tool both promise to help you meet WCAG, but they work in opposite places. An overlay is JavaScript you paste into your page. It runs in the visitor's browser, after the page loads, and tries to patch problems at runtime: relabel a button, nudge some contrast, drop a settings toolbar in the corner. A code-first tool never touches the live page. It scans your HTML, reports each issue against a WCAG success criterion with the exact element and selector, and you fix it in your source. That is the real difference. An overlay changes what the browser shows for the length of one visit; a code-first fix changes the code and stays fixed. It matters because barriers live in your markup: a <div onclick> that should be a <button> is unreachable by keyboard whether or not a widget sits on top of it. This guide walks through what each approach is, where they part ways line by line, and why the location of the fix decides almost everything.
What is an accessibility overlay?
An overlay is a single line of script you add to your site. Once loaded, it reads the page in the browser and applies automated adjustments on the fly: it injects some ARIA attributes, guesses a few missing labels, tweaks colours, and usually adds a floating toolbar so visitors can change font size or spacing themselves. accessiBe's accessWidget, UserWay, EqualWeb, and AudioEye all follow this pattern. The selling point is speed. Paste one snippet, and the vendor's dashboard reports a higher score by the next morning.
The catch is where that work happens. The overlay never edits your source. It rewrites a copy of the page after the browser has already parsed your real HTML, and it does that again on every page load, in every visitor's browser. Nothing in your repository changes. Turn the script off and the page is exactly as broken as it was before you paid for it.
What does code-first accessibility mean?
Code-first means the fix lands in your source code, not in a runtime layer on top of it. A code-first scanner crawls your pages, checks the rendered markup against WCAG success criteria, and hands you a list: this image has no alt, this control has no accessible name, this input has no associated <label>, each with the element and a CSS selector so a developer can find it in seconds. Your team makes the change in the component or template. After that, the <button> really is a button, the label really is wired to the input, and every assistive technology reads it as native markup.
The difference in durability is the whole point. A source fix is in your Git history. It survives a redeploy, a cache purge, and a visitor who has JavaScript disabled or blocked. It also travels: the same corrected component renders correctly on every page that uses it, without a script re-running in anyone's browser.
Overlay vs code-first: how do they actually differ?
They diverge at almost every step. Here is the comparison that matters more than one widget versus another.
| Overlay | Code-first | |
|---|---|---|
| Where it runs | The visitor's browser, after the page loads | Your source, before you ship |
| What it changes | The rendered DOM, for one visit | The HTML and ARIA in your repository |
| How long the fix lasts | While the script keeps running | Until someone edits the code |
| Who makes the fix | The script guesses at parse time | Your developers decide |
| What an auditor can inspect | A widget layered on the page | A report mapped to WCAG clauses |
| Effect on the user's own tools | Often conflicts with their screen reader | Their tools read plain, native markup |
One row deserves a note: single-page apps. When a React or Vue route re-renders, the overlay has to detect the change and re-apply its patches, and it frequently misses. A fix committed to the component ships with that component every time it mounts. There is no race to win.
Why does where the fix lives matter?
Because a patch that lives only in the browser is a patch the browser can undo. Screen reader users run their own software, with their own settings, and an overlay that injects ARIA it guessed at can fight the tools people already rely on. That is not a theory. In WebAIM's 2021 survey of accessibility practitioners, 67% rated overlays "not at all" or "not very" effective; among respondents who have disabilities themselves, that figure rose to 72%, and only 2.4% called overlays very effective (WebAIM). The people the tool is meant to serve are the ones least convinced by it.
The Overlay Fact Sheet, now signed by more than 800 accessibility practitioners including editors of the WCAG, ARIA, and HTML specifications, states the technical ceiling plainly: "No overlay product on the market can cause a website to become fully compliant with any existing accessibility standard." A script that runs after the page loads cannot reliably rewrite the page's real semantics, because the structure it is trying to repair is the structure the browser already committed to.
My honest take, and it is the reason we built the product the way we did: an overlay optimizes for the vendor's dashboard, not for the disabled customer trying to finish a checkout. Fix the code and both get better at once. Hide it behind a widget and neither does.
Does either one make you compliant on its own?
Neither does, and any tool that says otherwise is repeating the claim the US Federal Trade Commission just penalized. In April 2025 the FTC approved a final order requiring accessiBe to pay $1 million and barring it from representing that its automated product can make a website WCAG-compliant without competent, reliable evidence (FTC). The order names overlays specifically, but the limit applies to automation in general.
Here is the part a code-first vendor has to be honest about too. Automated testing catches part of the picture, not all of it. Deque's analysis of more than 2,000 audits put automation near 57% of issues by volume, while the older benchmark based on how many success criteria a tool can even evaluate sits closer to 30% (Deque). The W3C says the same in plainer terms: evaluation tools "can not determine accessibility, they can only assist in doing so" (W3C WAI). So a scan finds the machine-detectable issues and points you at the rest; a human with a keyboard and a screen reader still has to check the flows a scanner can't judge. Use the WCAG checklist for those criteria.
Where compliance is concerned, the standards care about the outcome, not the tool. In the EU, EN 301 549 incorporates WCAG 2.1 Level AA for the web and gives the EAA its presumption of conformity; in the US, WCAG 2.1 AA sits behind the ADA and Section 508. A source fix that satisfies the success criterion counts. A runtime patch that an auditor can't inspect, and that a screen reader might override, is a weaker basis for the accessibility statement you are expected to publish.
Frequently asked questions
Is an overlay the same as a code-first scanner?
No. An overlay runs in the visitor's browser and patches the page at runtime; a code-first scanner reports issues so your team fixes them in the source. The overlay's changes last only while its script runs. The source fix is permanent and every assistive technology reads it as native markup.
Do overlays actually fix accessibility?
They apply surface adjustments, but they cannot rewrite your underlying structure, and the people they target rate them poorly. In WebAIM's 2021 practitioner survey, 72% of respondents with disabilities called overlays not at all or not very effective (WebAIM). The Overlay Fact Sheet, signed by 800-plus practitioners, says no overlay makes a site fully conform to any standard.
Is code-first accessibility more work?
Up front, yes, because a person edits the code instead of pasting a script. It costs less over time. The fix is in your repository, so it survives redeploys, works with JavaScript off, and doesn't re-run in every visitor's browser. You fix a labelled input once and every page using that component inherits it.
Will an overlay or a scanner make my site compliant on its own?
No, and the FTC fined accessiBe $1 million for claiming its automated product could (FTC). Automated tools catch roughly 30 to 57% of issues; the rest needs manual testing with a keyboard and a screen reader. Full conformance also needs a published accessibility statement.
Do overlays help or annoy screen reader users?
More often the second. Overlays inject attributes the browser has already committed to interpreting, and that can conflict with the settings a screen reader user has chosen. WebAIM found only 2.4% of respondents with disabilities rated overlays very effective (WebAIM).
See what a code-first scan reports
If you are weighing overlay vs code-first, look at the evidence instead of a score. Run a free scan to get the real list of WCAG issues on your pages, each mapped to the criterion you're held to, with the element and selector your developers need. Fix what it finds in your code, review the rest by hand, and document where you stand. That is the route that holds up when someone actually reads your markup.
Written by Pavel Charkasau, founder of wcagc.com. Last updated 1 August 2026.
Sources
- W3C WAI, "WCAG standards and guidelines": https://www.w3.org/WAI/standards-guidelines/wcag/ — accessed 1 August 2026.
- Overlay Fact Sheet: https://overlayfactsheet.com/en/ — accessed 1 August 2026.
- WebAIM, "Survey of Web Accessibility Practitioners #3 Results" (2021): https://webaim.org/blog/practitioners-survey-3/ — accessed 1 August 2026.
- FTC, "FTC Approves Final Order Requiring accessiBe to pay $1 Million" (April 2025): https://www.ftc.gov/news-events/news/press-releases/2025/04/ftc-approves-final-order-requiring-accessibe-pay-1-million — accessed 1 August 2026.
- Deque, "Automated Testing Study Identifies 57% of Digital Accessibility Issues": https://www.deque.com/blog/automated-testing-study-identifies-57-percent-of-digital-accessibility-issues/ — accessed 1 August 2026.
- W3C WAI, "Selecting Web Accessibility Evaluation Tools": https://www.w3.org/WAI/test-evaluate/tools/selecting/ — accessed 1 August 2026.