> Screen readers get the real words. A screen reader reading down the page is never handed scrambled text, and our NVDA test asserts exactly that. Screen review and touch exploration are untested. ShieldFont hides shielded passages from accessibility tools by default with aria-hidden="true", because a decoy read aloud is fluent, grammatical, wrong English, and that is worse than silence.
> The real words remain sealed in the same page, and a visible notice above the block carries the control that uncovers them. It is on by default and reachable by mouse, keyboard and screen reader alike. Pressing it sets the reader’s browser to solving a compute-heavy puzzle: JavaScript and a few seconds of processing, more than most mass scrapers are willing to spend. That puts the words within reach of a screen reader, a translator and copy/paste.
I'd love to hear your thoughts on that. Also just aside, love this TUI-esque blog design and color palette (maybe a bearblog theme? still worth an upvote)
They also actively block copying the text, telling you to "uncover" the text first. The uncover operation is VERY expensive.
Anyone using assistive technologies or trying to copy "protected" text is SOL.
Search engines will index the decoy. You'll get no traffic. Their solution is basically putting yourself in a black hole.
I take your point that one extra click/interaction required for screen readers only is objectively more friction, but it's only by exploring these technologies instead of dismissing them that we'll arrive at UX solutions truly work for people of all stripes (and ideally, not for bots, scrapers, and the like). I think if you're applying a tool like this you already have very different priorities than fueling Google.
But you seem to appreciate it, and I'm sure others do too. Different strokes for different folks.
"This document contains mitigations against review by automated systems. Recipients should ensure that they have read the contents on screen or in print. Recipients with bona fide vision impairments may be entitled to unmitigated documents upon request."
In testing, obfuscating small portions of text slipped under the radar of most (then-)frontier LLMs.
We used a font that was rendered on the fly and reported faulty or fake Unicode mappings: https://tritium.legal/blog/noroboto but others have proposed and done the same with ligatures.
Accessibility is not accessible if you need to go through extra steps to get it.
Cerebrally, this as a solution makes sense. But if you know anyone with a vision or other impairment, gating it behind a request is not only cruel but gets within dangerous striking distance of an ADA lawsuit, for general applications.
Maybe in the legal field or specific niche cases it's possible. But this would represent a major step backwards in the work we've done lowering barriers for a population whose only difficulty in accessing common resources is because they were born, or got sick, differently than anyone else.
Our internal, hypothetical use-case was between contracting parties who were looking to avoid terms escaping into the wild. This shouldn't show up in standard ToS or similar. There are already really good legal reasons for that.
That seems a bit entitled to me, especially in the story you shared. They had access to the school just like everyone else. Why does it have to be in the exact same spot? Surely they could be dropped off by the loading dock as easily as others could be dropped off out front, and maybe even moreso. Should the wheelchair accessible stall be the first stall in the bathroom so they don't have to go through "extra steps" to get to it? As long as the ramp had the proper gradation to satisfy the ADA, I don't see the problem.
They literally did not. They had access to the school from a different entrance than everybody else. Specifically, one intended for cargo before people.
Otherwise, you are relying on obscurity, and will lose as soon as you become interesting enough to matter.
You will also break non-AI machine processing use cases. That isn't just accessibility, it is things like search.
Their own whitepaper brings up a bigger issue: if it works, it poisons search engines as well.
That's only one half of the equation, though, isn't it? What if it makes it harder for legitimate users as well? It seems there's a balance to be struck.
I’ve heard Tesseract OCR recommended, but even in 2026, no matter how I scan receipts or documents, the OCR output seems far worse than human reading?
That said, what kind of errors are you getting? I think the main practical difference between Tesseract's LSTM-based OCR and newer VLM-based OCR like PaddleOCR [1] is (hopefully) getting to skip making heuristics for the layout of the document, but errors possibly compounding over multiple tokens - are you getting individual illegible words or having the documents smooshed together because the OCR can't parse the layout?
I don't think any anti-AI font design is more than design-as-art statements against AI. If there is evidence of them being used exclusively for business and without accessible fonts aside them, I'm willing to be wrong.
I can't read this bad font, sizing, spacing, etc. The main offender is the color choice, and fonts that are just god aweful to read.
That website no-way is accessible for my 30 year old eyes.