It does work with screen readers but their solution seems far from ideal. Also, that relies on the fact that the scrappers don't typically run JavaScript.

Screen readers (used, for example, by people with visual impairment) work from the source code, where your words are already swapped. The font only fixes things on screen, so a shielded block would be read aloud as fluent, wrong English. Shielded sections in our React tier carry aria-hidden to stop that. In its place, an opt-in beta ships the correct text encrypted in the page. A button only screen readers reach asks the reader’s browser to solve for the key: a chain of steps where each one needs the answer to the last. It also needs JavaScript, which most scrapers never run. The cost currently lands on the reader: up to twenty seconds on a slow device. That is friction, and it is the part we most want help fixing.

Pretty much, yeah. Unless each site owner creates a custom mapping.

The font must be sent to the browser so it can display the original words. Anyone who downloads it can therefore inspect it and work out the substitutions. That is unavoidable. But our goal is not to stop someone who deliberately targets a specific site. Instead, it is designed to disrupt large-scale automated scraping, which processes many sites without examining each one individually (because that costs money). ShieldFont currently ships with three different word mappings and gives publishers the tools to create their own, so decoding one mapping does not automatically reveal the others.