We already told the story of testing five AI-branded overlay tools by hand, screen reader running, keyboard as the only input device allowed. That was the narrative version: the frustration, the loops, the widget congratulating itself on compliance while the page underneath stayed exactly as broken as before.
This time we are skipping the story. Here is the scorecard. Five tools, five named WCAG success criteria, checked one at a time, with no partial credit for a nice-looking accessibility icon in the corner of the screen.
If you want the blow-by-blow account of what it actually felt like to navigate these tools as a real screen reader user, that is a separate piece and we will link to it below. This one is the reference version: the criteria, the method, and the results, laid out so you can check your own vendor's claims against them.
The Stat: The W3C's own Overlay Fact Sheet documents that overlay-only approaches commonly cannot achieve full conformance because they operate on the rendered page rather than the source code and content. (Source: W3C Web Accessibility Initiative)
The Five Criteria We Checked
We did not test "accessibility" in the abstract. Marketing pages love that word precisely because it is unmeasurable. Instead we picked five specific, named WCAG success criteria, the same ones an auditor or a legal complaint would actually cite, and checked each overlay against each one, on the live rendered page, with no exceptions made for effort.
The five were:
- SC 1.4.3 Contrast (Minimum) - text needs enough contrast against its background to be readable by people with low vision.
- SC 2.1.1 Keyboard - every function on the page has to work using a keyboard alone, no mouse required.
- SC 2.1.2 No Keyboard Trap - if you can tab into something, like a menu or a modal, you have to be able to tab back out of it.
- SC 2.4.7 Focus Visible - when something is focused via keyboard, there has to be a visible indicator showing where you are.
- SC 4.1.2 Name, Role, Value - every interactive element needs a programmatically determinable name and role, so assistive technology can announce what it is and what it does.
Two of these, WCAG 4.1.2 Name, Role, Value and Contrast (Minimum), require changes to a page's actual HTML and CSS. An overlay running as an injected script sits on top of the page. It does not, and structurally cannot, rewrite the underlying markup that a screen reader or a browser's own zoom and reflow features actually read. The other two keyboard criteria, including WCAG 2.1.1 Keyboard, require that all functionality, including custom widgets the overlay itself did not build, be fully operable and escapable using a keyboard alone.
How We Scored Each One
The method was deliberately boring. For contrast, we sampled the actual rendered colors of body text and interactive elements after the overlay had finished running, not the colors promised in its marketing copy. For the two keyboard criteria, we unplugged the mouse entirely and tabbed through every interactive element on the page, including anything the overlay itself had added, such as its own accessibility menu. For focus visibility, we watched for a clear, high-contrast outline on every focused element. For name, role, and value, we inspected the accessibility tree the browser actually exposes and listened to what a screen reader announced for each control.
A pass meant the criterion was met on the rendered page, full stop. A tool did not get credit for having a setting that claimed to fix something if the fix did not show up when we actually checked.
The Scorecard
| WCAG Success Criterion | Result Across the 5 Overlays Tested |
|---|---|
| SC 1.4.3 Contrast (Minimum) | Failed on all 5 |
| SC 2.1.1 Keyboard | Failed on all 5 |
| SC 2.1.2 No Keyboard Trap | Failed on all 5 |
| SC 2.4.7 Focus Visible | Partial on all 5 (CSS-only fix, underlying markup unchanged) |
| SC 4.1.2 Name, Role, Value | Failed on all 5 |
Zero of the five tools passed all five criteria. Most failed all five outright. The one bright spot, such as it was, is worth explaining on its own.
The One Criterion That Got a Partial Check
Focus Visible is the odd one out, and the reason why is instructive. Adding a visible focus outline is, structurally, just a CSS change: a border or outline color and width applied to whatever element currently has focus. That is exactly the kind of thing an overlay's injected stylesheet can plausibly touch, because it does not require rewriting the DOM or adding new semantic attributes, only changing how an existing element is painted.
That is also the whole story of what overlays are actually capable of. They can adjust presentation. They cannot rewrite the underlying markup a browser or screen reader depends on to know what an element is, what it is named, or how it behaves. Contrast on text that was never marked up with the right structure, a custom dropdown that was never given the right role, a modal that was never wired to trap and release focus correctly: none of that gets fixed by a script sitting on top of the page after the fact.
Why the Same Failure Shows Up Every Time
This is not a coincidence of which five tools we happened to pick. It is architecture. An overlay operates on the rendered page, after the browser has already parsed the HTML and built the accessibility tree. By the time the overlay's script runs, the fundamental structure of the page, its element roles, its focus order, its keyboard event handlers, is already set. A script can paint over some of the symptoms. It cannot go back in time and write the markup correctly the first time.
That is also precisely what the W3C's own Overlay Fact Sheet says, in plain language: overlay-only approaches commonly cannot achieve full conformance because they operate on the rendered page rather than the source code and content. Our scorecard is just that same conclusion, checked criterion by criterion instead of taken on faith.
If you want the fuller, more human version of this same conclusion, including what it felt like to actually try to use these tools with a screen reader running, read the full hands-on story of testing 5 AI overlay tools. This piece is the reference version; that one is the lived experience behind it.
What To Check On Your Own Site
You do not need five overlay subscriptions to run a version of this test yourself. A short, honest pass on your own site will tell you more than any vendor's compliance badge.
- Run a contrast checker against your rendered text and background colors, not the palette promised in a settings panel
- Unplug the mouse and tab through every custom widget on the page, start to finish
- Open every modal, menu, and dropdown and confirm you can tab or press Escape back out of it
- Confirm a visible focus indicator appears on every interactive element as you tab through
- Check that every button, icon, and custom control has a name and role a screen reader announces correctly
If more than one of those boxes stays unchecked, the fix is in the code, not in a script layered on top of it.
Where This Leaves You
A scorecard is only useful if it changes what you check next. The pattern here is consistent enough to trust: presentation-only fixes can move the needle on things like focus outlines, but keyboard operability, contrast on the actual rendered markup, and correct name, role, and value all require touching the real HTML and CSS.
If you would rather have someone check your own site against these same five criteria instead of guessing, get a free audit of the real underlying code and see exactly where it stands. You can also just email the team directly at experts@wcag.world if you would rather talk through what a scorecard like this would look like for your specific site before committing to anything.