Most mass scrapers, on the other hand, simply grab the raw HTML underneath. ShieldFont exploits this difference through an automated process called OpenType glyph substitution.
That said, because the whole defense rests on scrapers reading code rather than screens, taking a screenshot of a shielded page and running OCR on the image can still recover the real words.
Screen readers used by blind readers also work from the code, so they read the decoys aloud. ShieldFont ships with a beta feature that provides those readers with the real text instead.
does this also block blind people who depend on an e-reader?
screen reader, SEO, indexation, in page search, etc.
Basically, it breaks everything except people… unless they block/substitute fonts for accessibility reasons, in which case fuck people too.
This is a terrible idea, and it won’t even achieve it’s original “purpose” as it is trivially detectable. Only negatives in this.
Per the article, yes:
But:
AI scrappers will just pretend to be screen readers then.
And if the approach becomes popular they will just OCR the text instead.
Per the GitHub:
In summary, they have two ways to get around this.
Sounds like an overly convoluted way to do exactly what Anubis does…
Yeah, if you care about screen reader users, functionally it’s just “Anubis but worse”. Unfortunately, most people don’t care, so for them and all visual users, it has the benefit of no additional “load time” computational check — the page appears instantly without the Anubis step. Though I’m not sure how long it takes the page to do the de-scrambling.
The primary purpose of this project is to mutilate your HTML so bots can’t scrape it, rather than preventing bot traffic in the first place. The screen reader stuff is a bolt-on.
There are laws about accessibility, at least for public websites, and probably for larger websites as they have such a large audience that disability can’t be ignored (as much).
In my experience, those laws aren’t followed much in reality. The biggest sites, sure, but most smaller sites are a mess under the hood. As long as something is “technically usable”, even if very awkward and annoying, it’s often hard to sue or anything like that. Maybe it’s different in other countries though, I live in Australia.
Next time you use a website, try only using your keyboard to navigate it and accomplish your task, and you’ll see what I mean. It’s a rough test of how much they value accessibility. For example, many websites disable the border around what you’re highlighting, so you have no idea what the tab button is about to click. Or popup windows don’t actually change your tab selection, so you have to tab through literally the entire page in the background to get to the popup window. Stuff like that; technically usable but annoying as hell.
In the US, the Americans with Disabilities Act (ADA) facilitates tons of lawsuits against websites that are not accessible: https://www.rjo.com/publications/website-accessibility-lawsuits-continue-to-inundate-california-courts-despite-covid-19/
Edit: here’s another good link showing a graph of the number of ADA website accessibility lawsuits from 2016 to 2025: https://www.ecomback.com/annual-2025-ada-website-accessibility-lawsuit-report
There’s a fair chance they’re already doing that. It provides better insight on the content, less formatting to handle, and even visual stuff gets text alternatives.
It is also very easy to detect surprising text by looking at the perplexity levels by feeding it to a very small model. If there’s a problem, OCR/‘screen read’ it instead…
it does, unless the reader has an OCR mode of sorts
Presumably the AI scraper would also have OCR, and would sidestep things like this?
A scraper has many more ways around something like sheildfont than just OCR. The question will be if it was actually programmed to check for such measures.
Yes, the decoy text is marked aria-hidden, so it won’t be read out loud. The real text is sent to the browser encrypted, and the decryption process takes ~20 seconds, roughly the same as running ocr.