Accessibility

[smythp]

Hi all,

Was looking into the accessibility of this library, and was wondering if there is any documentation or a status update on the current state of accessibility for screen reader users. I noticed issue #280 opened by @protodrew was automatically closed without a response. I feel that accessibility might be particularly important for a library like this, since it's an upstream framework that may affect accessibility for potentially hundreds or thousands of downstream applications.

Thanks, and interested to hear any thoughts.

[github-actions[bot]]

Thank you for your issue. Give us a little time to review it.

PS. You might want to check the FAQ if you haven't done so already.

This is an automated reply, generated by FAQtory

[davep]

This is a consideration that is on our roadmap: https://textual.textualize.io/roadmap/

[willmcgugan]

The terminal has historically poor accessibility, and there isn't a great deal we can do to improve on it. However, when Textual web becomes a reality, we can implement more accessibility features. Given that Textual has a DOM, we're not limited by the unstructured matrix of characters of terminals. In theory we can do a lot more than TUIs running in the terminal.

But yes, accessibility is important to us.

[smythp]

I strongly disagree with the statement that the terminal has historically poor accessibility. It's a text interface, if anything it's one of the most accessible modalities for screen readers. Even TUIs and quasi-GUIs like curses are generally accessible these days with terminal screen readers like speakup. If apps created with the library are not accessible, I would not blame the terminal environment.

I'm not convinced that creating a web version will resolve accessibility issues, unless you plan on making the terminal portion of the framework superfluous in favor of the web entirely. Screen readers users are terminal users to a great extent, and use the terminal in preference to web interfaces just as users who do not use screen readers do. Due to the great accessibility of the terminal environment, in fact, I'd say screen reader users are disproportionately terminal users as well. I do feel like there is some responsibility here, given that any app created with textual would currently be inaccessible in a terminal, and would have been accessible if created with other terminal interface options like click or curses.

It's great to see the various accessibility features at the top of the roadmap, though I think that's an accident of the alphabet, ha. Thank you for your response. I understand that this is often a difficult issue for FOSS libraries, but I also feel that upstream libraries that don't implement accessibility cause serious issues for screen reader users. Potentially every TUI created with textual might have to be something screen reader users have to work around for years to come, in the worst case.

[mrkiko]

Infact, terminal is very very much accessible and apreciated. :)

[glyph]

if created with other terminal interface options like click or curses

I am very curious about this — how would a window-oriented curses application be more accessible than textual? What does curses provide that textual doesn't?

[mrkiko]

On Thu, May 25, 2023 at 06:11:16PM -0700, Glyph wrote:

if created with other terminal interface options like click or curses

I am very curious about this — how would a window-oriented curses application be more accessible than textual? What does curses provide that textual doesn't?

-- Reply to this email directly or view it on GitHub: https://github.com/Textualize/textual/issues/2425#issuecomment-1563685793 You are receiving this because you commented.

Message ID: @.***>

Hi!!

So, in my case, what I did (if my memory serves me well), was to ask a question - that is: does textual support enabling the standard / vt100 hardware cursor? I did that question since in some cases (e.g.: the librespot application, that uses the cursive toolkit), enabling the hardware cursor is not possible without (apparently) non-trivial changes to the cursive code itself.

For some more context - you may have a look at:

• the LYNX text-mode web browser (which I apreciate and use often) has a show_cursor setting, that control this behaviour; if you ever install this package, see your "lynx.cfg" file for more details;

• the NCMPC (ncurses client for the Music Player Daemon) has a setting controlling this behaviour called hide-cursor which lets you hide the playlist cursor after NUM seconds of inactivity (I did set it to 0), see the NCMPC(1) manual page if you ever install this package;

• the Alpine client offer a show-cursor option that get saved in the configuration file, the help system of this nice e-mail client may contain more details;

and so on.

Hoping I was able to clarify things a little bit more.

[mwcampbell]

When talking about the accessibility of terminal-based interfaces, we need to distinguish between line-oriented and screen-oriented interfaces. Line-oriented interfaces are very accessible with a screen reader. Some blind people have learned to use some screen-oriented programs, such as Pine, Lynx, and Mutt, and are apparently even happy with them. But other screen-oriented programs, like Links, have always been more of a problem, because of their complex layouts. (Incidentally, since most blind people use text-to-speech, and Lynx and Links sound alike, it's common to disambiguate them by saying "the cat" and "the chain".) I think TUIs built with Textual are more like Links (the chain) than Lynx (the cat) or Pine.

@willmcgugan do you have any plans yet for implementing screen reader accessibility in Textual web? How much is Textual web still dependent on terminal escape sequences?

[mrkiko]

On Sun, Aug 27, 2023 at 06:37:49AM -0700, Matt Campbell wrote:

When talking about the accessibility of terminal-based interfaces, we need to distinguish between line-oriented and screen-oriented interfaces. Line-oriented interfaces are very accessible with a screen reader. Some blind people have learned to use some screen-oriented programs, such as Pine, Lynx, and Mutt, and are apparently even happy with them. But other screen-oriented programs, like Links, have always been more of a problem, because of their complex layouts. (Incidentally, since most blind people use text-to-speech, and Lynx and Links sound alike, it's common to disambiguate them by saying "the cat" and "the chain".) I think TUIs built with Textual are more like Links (the chain) than Lynx (the cat) or Pine.

Hi!

My experience is little bit different. Links's complex layouts may be little bit more difficult to get used to, but not impossible at all. And, once you enable the Braille terminal option in the settings, things get much easier. And - the standard terminal cursor moves around so the screen reader recognizes it and all is fine. The accessibility problem we are discussing is, in my view, something regarding implementation, not something "problematic" in it's own. Hoping I was able to explain myself.

Enrico

@willmcgugan do you have any plans yet for implementing screen reader accessibility in Textual web? How much is Textual web still dependent on terminal escape sequences?

-- Reply to this email directly or view it on GitHub: https://github.com/Textualize/textual/issues/2425#issuecomment-1694671344 You are receiving this because you commented.

Message ID: @.***>