←back to thread

Things I've learned building a modern TUI Framework (2022)

(www.textualize.io)
331 points willm | 4 comments | 11 Aug 24 12:22 UTC | HN request time: 0.641s | source
Show context
miki123211 ◴[11 Aug 24 16:27 UTC] No.41217308[source]▶
As a screen reader user, reading this post makes me want to scream.

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.

replies(2): >>41217449 #>>41218608 #
willm ◴[11 Aug 24 16:47 UTC] No.41217449[source]▶
I would love to improve support accessibility for TUIs. Textual internally keeps a browser like DOM structure, which means it could in theory offer browser-like support for screen readers while keeping all the features offered to sighted user. But it would require a protocol to allow the app to send structured information so that the screen reader has more to work with than a matrix of characters. AFAIK this doesn't exist.

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.

replies(2): >>41217749 #>>41218485 #
1. blooalien ◴[11 Aug 24 17:22 UTC] No.41217749[source]▶
> Textual internally keeps a browser like DOM structure, which means it could in theory offer browser-like support for screen readers while keeping all the features offered to sighted user. But it would require a protocol to allow the app to send structured information so that the screen reader has more to work with than a matrix of characters.

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.

replies(1): >>41217933 #
2. willm ◴[11 Aug 24 17:45 UTC] No.41217933[source]▶
De nada!

> 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.

replies(2): >>41219402 #>>41219608 #
3. ericwood ◴[11 Aug 24 21:22 UTC] No.41219402[source]▶
It’s more in the Rust ecosystem but AccessKit looks really promising from this standpoint. I’m not sure if it could work in the context of a TUI but it might be a great starting point! https://github.com/AccessKit/accesskit
4. miki123211 ◴[11 Aug 24 22:03 UTC] No.41219608[source]▶
> Definitely possible from a technical standpoint

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.