Per the GitHub:
Accessibility layer: <Shield> hides protected regions from assistive tech and ships an a11y prop 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), or mode: "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.