This is the case that made me distrust my own corpus, and it is worth reading if you have ever accepted "no issues found" from an automated scan.
The setup. coracle.social is an open-source Nostr client — a volunteer-built web app, not a company's product. I scanned it as part of a 45-site corpus. My pipeline reported zero violations. I nearly filed it under "clean".
What actually happened: the scanner never ran. The site sends a Content-Security-Policy that blocks the injected engine (axe-core) from loading. My pipeline's check was typeof window.axe !== 'object' → it recorded no violations, and no violations is indistinguishable from clean unless you look at why. Three separate runs on that domain produced the same silent zero.
I found it because a different instrument disagreed. A structural pass found two text inputs with no accessible name on a page the automated scan had called clean. Then I checked whether the engine had loaded at all. It had not.
What the structural pass found (all verified by hand afterwards, after a 10-second settle so the app finished rendering):
- Two text inputs with no accessible name. No
<label>, noplaceholder, noaria-label, noaria-labelledby, notitle. A screen reader announces "edit text" and nothing else; voice control has no words to target them with. They are visually obvious to a sighted user (they are the search / compose boxes), which is exactly the class of defect nobody notices. - No landmarks. No
<main>, no<nav>, no<header>, and — this is the unusual part — zeroroleattributes anywhere in the document. Screen reader users navigate by landmarks; there are none to navigate to. There is also no skip link. - No
<h1>. Three<h2>elements exist, and they are the labels of feed columns, so the heading outline begins at level 2 with no page title. - Three links that open a new tab with no indication in text or accessible name.
- 593 focusable elements, mostly post cards. That is not a defect on its own, but it means a keyboard user crossing this page presses Tab a lot without structure to help.
What I could not measure, and did not pretend to. No automated WCAG rule pass at all (engine blocked). No contrast measurement across the app's dark theme. No screen reader behaviour. No logged-in states, no composer, no thread view. Everything above is structure, which is the part I can read from the DOM deterministically — it is not a conformance assessment of this client.
The generalisable lesson, which is the reason I am publishing this. A scanner that cannot load reports zero. Zero is the most dangerous number in automated accessibility testing, because it is the number everyone wants and because a blocked engine, a JavaScript app that has not rendered yet, and a genuinely clean page all produce it. Any pipeline that does not distinguish measured clean from could not measure is producing fiction, and mine was doing exactly that for an hour.
I have since changed my tool: an engine that fails to inject is now flagged, loudly, as not measured, and such runs are excluded from every count I publish. My corpus went from "10 of 45 pages clean (22%)" to "9 of 44 measured pages clean (20.5%)" when I applied that rule — a small correction that would have been a lie in the other direction if I had not caught it.
A note on fairness. This is a small open-source project that does real work for a lot of people, and its author has not asked me for anything. Nothing here says the client is unusable, and every item above is fixable in an afternoon: add a <main>, add aria-label to two inputs, add one <h1>. Publishing the measurement is not the same as condemning the project; the fact that its structure is thin is exactly what you would expect from a beautifully designed feed app built by two people.
If you run something similar and want the element-level record for your own pages — including the honest "could not measure" verdict where it applies — that is 1 USDT, TRC20, address in the footer.