Per the GitHub:
Accessibility layer:
<Shield>hides protected regions from assistive tech and ships ana11yprop that renders a real alternative beside them —mode: “text”puts your words in the page encrypted behind a time-lock puzzle the reader’s browser opens (no link for a scraper to follow, no artifact for you to host), ormode: “audio”points at a recording you make. What remains: NVDA and JAWS verification (VoiceOver is done by hand, Windows is not), the focus indicator a sighted keyboard user loses to an invisible control, and the non-React tiers shipping none of it.
In summary, they have two ways to get around this.
- By default, blind people are fucked as usual. Most everything is unusable via screen reader just due to the way modern websites are designed.
- Audio mode pre-records an audio file of your text, and plays that, bypassing the screen reader. This is extremely horrible UX for screen readers, for anything more complicated than a wall of text, but at least it’s something.
- Text mode will do some sort of computational challenge, using CPU on the blind person’s machine for a few seconds, then revealing the original unmolested text. Assuming this works properly, because screen readers are extremely fragile beasts.