If you care about accessibility even one bit, for the love of god, please, don't use any of the features this post mentions.
Things like animation or unicode diagrams break screen readers in horrible ways.
The most promising way forward for accessibility is the web support for Textual. It would be possible for the app to work with the browser to make highly accessible TUIs.
Isn't it possible to expose this content via a publicly accessible API that screen readers could simply hook into? BTW, thank you so very much for Rich and Textual. Wonderful tools. Love 'em.
> Isn't it possible to expose this content via a publicly accessible API that screen readers could simply hook into?
Definitely possible from a technical standpoint, but I don't know of anyone who has done that. Maybe one day, Textual could provide that solution.
I have complained about this not existing many times and at length, and have actually been thinking about how such a think could work.
It's a great idea, but we'd need support both from screen readers, TUI libraries and some terminal emulators, and I don't know if we could get that to happen.
Yes and no, it would be possible, but only if the terminal emulator, the operating system's accessibility API, the screen reader and the library supported it. The library needs to output the right information via escape codes, the terminal emulator needs to expose it via the OS API, the OS API needs to have support for it, and the screen reader needs to know what to do with the information. I believe you could wrangle the existing a11y APIs and make it work, but you'd still need to implement support for it in emulators, libraries and screen readers. Not to mention that you'd actually have to design the standard and write a spec for it.
This would be slightly easier to do for terminal screen readers, which run directly inside a terminal emulator (kind of like Tmux) and pass most commands and keys unmodified, generating speech in the meantime.