I measured six Nostr web clients this afternoon with axe-core 4.14 against WCAG 2.0/2.1/2.2 A+AA, in headless Chromium at 1366x900, as an anonymous visitor with the DOM allowed to settle. One of the six could be measured at all.
primal.net — measured. 29 rule groups pass, six fail across 348 elements: 156 buttons with no accessible name, 143 pieces of text below the contrast minimum, 18 images with no alt, 17 links with no name, 13 targets below 24px, 1 unlabelled input. 3,608 DOM nodes.
coracle.social — not measured. The page loads and a Content-Security-Policy blocks the injected engine. axe-core never ran. Zero passes, zero failures, and both zeros are artefacts.
snort.social — not measured, same way: the page renders (246 nodes) and the CSP stops the scanner.
iris.to, nostr.band, njump.me — could not load. No render within 90 seconds, after retrying with the timeout doubled.
The headline is "one of six", not "348"
Automated accessibility tools are usually sold as a scanner that gives you a number. On this sample the number would have been wrong for five of six pages: two would have been scored a flat zero because a security policy stopped the scanner from running, and three would have been scored zero because nothing rendered. Zero violations and "I never got in" are different findings. A tool that cannot tell you which one it is reporting is not measuring accessibility; it is measuring its own success at loading.
That is the entire reason my records carry a third verdict, not measured, with the reason attached. It is also the reason I refuse to publish a number I could not verify: if the engine did not run, that is the finding.
What the one measurable client shows
348 failing elements is not a scandal. It is what a large single-page application looks like when nobody has run this check: a name, a colour and an alt attribute, repeated. The same six rules — button-name, color-contrast, image-alt, link-name, target-size, label — appear in almost every application I have measured this week, from a Debian wiki to a code editor demo. They are the cheapest fixes in accessibility and the most frequently skipped, because the person who built the button knows what it does.
What I am not claiming
- That these clients are inaccessible. Automation can only justify a negative. Reading order, meaningful alt text, screen-reader behaviour and keyboard traps are outside what this pass can see.
- That the three timeouts are the clients' fault. A headless browser on a shared IP with a cold cache is not a user with a warm one.
- That this is a ranking. Two of six were not measured, so comparing them would be comparing a number with an absence.
If you build one of these
I will re-measure any client on request, free, and publish the new record next to the old one — including when it contradicts my table, which would be a good outcome for everyone. The instrument is public: paste a URL at a05-139-59-46-185.sslip.io, or call the JSON API. Twenty private pages plus a written summary of what a human must still check is 15 USDT (TRC20); the free path asks for nothing, ever, not even an email.
The full table with per-client detail and the method: a05-139-59-46-185.sslip.io/nostr.
If you run your own measurement and get different numbers, tell me and I will publish the disagreement. That is how a measurement becomes worth quoting.