5 ms·

This kind of fancy terminal manipulation is usually an accessibility nightmare. Real GUI frameworks usually provide semantic information to the OS, which allow

This kind of fancy terminal manipulation is usually an accessibility nightmare. Real GUI frameworks usually provide semantic information to the OS, which allows screen readers to determine that a given control is a progress bar that is 50% filled, and then render that information by playing an appropriately-pitched tone. In a TUI, all they get is a line of fancy symbols changing quickly, with no context as to what those symbols mean. Same for i.e. ncurses based menus. When programs use colors to signify which menu option is selected, screen readers usually get lost. Screen readers specifically designed for text-based systems (such as DOS) usually had ways to work around this issue, but modern, GUI-focused ones don't really offer those options any more.

darkwater 5y ago
In apt at least the fancy UI can be disabled completely, see 'Dpkg::Progress-Fancy "0";'
d_watt 5y ago
Out of curiosity, when you have a large amount of text flying by like with package installs, what is the expected accessibility behavior? I imagine a screenreader trying to keep up with the install logs in any way would be... chaotic.
- miki123211 5y ago
  It tries to read everything, but you can flush it with control. If you notice it stopped speaking, you usually use some review commands to look at the last few lines. If you're looking for something specific, you'd usually use something like grep, even in situations where a sighted person could just glance at the screen.
  - newswasboring 5y ago
    might sound a bit insensitive. But is there a video I can see of this? I cant even imagine how this would look in the hands of an expert.
    - miki123211 5y ago
      No, not to my knowledge. I could probably find a podcast or two, there are quite a few of those aimed at a blind audience, but that's about it.
    - bhaak 5y ago
      Not exactly what you asked for but the "Designing for the Visually Impaired" episode of the Roguelike Radio podcast has a blind player play a roguelike. The intro has a bit of screenreading but the gameplay is starting at around 1:15. While listening, you should put on headphones and concentrate very hard. It's quite fast and other sensory input might be disturbing so also close your eyes. http://www.roguelikeradio.com/2012/10/episode-48-designing-for-visually.html http://www.roguelikeradio.com/2012/10/episode-48-designing-f...
    - lzybkr 5y ago
      Saqib Shaikh, a blind developer at Microsoft, gave this short talk on using Visual Studio: https://www.youtube.com/watch?v=94swlF55tVc https://www.youtube.com/watch?v=94swlF55tVc I realize this isn't a console, but I think it is a good demonstration of an expert doing typical developer activities.
lelandfe 5y ago
A good point and one I hadn’t considered before (shame on me). Does anyone have a good reference on making accessible terminal programs? As a web developer I’m intimately aware that there are many gotchas and nuances to be aware of - I have to figure the same is true of the terminal.
- miki123211 5y ago
  If it works correctly on an old-school TTY with a printer and a roll of paper, you're pretty much done. That's how you should view a terminal screen reader, except it talks instead of printing. Using it with a non-monospaced font would probably be a good test too. Monospace makes some implicit assumptions (i.e. being able to see how things are aligned) which screen readers don't follow. Also avoid preceding important messages with long strings of text, in particular containing numbers, i.e. overly detailed timestamps in logs. A screen reader reads text line by line, so those usually make using the app less efficient. If you want an actual user interface, not merely a command prompt, avoid the terminal like the plague. Exposing a simple web frontend might be a good idea here.
Cthulhu_ 5y ago
All terminal applications should have a 'basic' (or to use Git terminology, 'porcelain') output mode by default, and an alternative renderer for more visually inclined people as an option. Most recently, Yarn 3 went way overboard with their installer, to the point where it's... visually overwhelming? Tree views, colors, dotted underlines, multiple scrolling segments, etc. It's a bit better if running in CI mode (no coloring), but still not ideal.
- deleted 5y ago
  [deleted]
- TeMPOraL 5y ago
  On 'porcelain', the way Git uses that term is a pet peeve of mine. On the one hand, the intended meaning of it is that "porcelain" commands are meant for humans, not for other programs - scripts should use the "plumbing" commands (apparently, it's a toilet analogy). On the other hand, the flag that makes "porcelain" commands write machine-readable output is called... "--porcelain". Implying it does the opposite of what it does.
  - yissp 5y ago
    Gah, I'm beginning to think the git CLI is trying to be confusing on purpose.
    - willismichael 5y ago
      https://stevelosh.com/blog/2013/04/git-koans/ https://stevelosh.com/blog/2013/04/git-koans/
      - blacktriangle 5y ago
        Is the zen of git to stop using git? Somewhat inspired by OpenBSD I spun up my most recent side project with cvs. I'm amazed how much less stressful code management has become. Makes me want to go further back in time and learn how to properly use rcs.
csmpltn 5y ago
The terminal is a visual tool. That makes it inaccessible, almost by definition. Terminals are text-based, but they can still be used to convey non-textual information (ie. progress bars, graphs, etc). There's no sense in expecting a visual application (such as the terminal) to be somehow accessible out-of-the-box. Trying to automatically translate a visual interface to an accessible interface is bound to be error prone and not work in all cases. What's accessible for a blind person, may not be accessible to a deaf person. Applications should share the core business logic, but have entirely seperate "frontends" for every situation. A graphical frontend, and an accessible frontend. We need an open cross-platform standard for this, and enforcement.
- taeric 5y ago
  This feels very short sighted, oddly. Your visual terminal interface is visual, sure. But there is nothing that says that has to be how you interface with a terminal. It is just a character/symbol stream connection. With interrogation commands that can go back and forth, there is nothing that says it can't be as accessible as you want it to be.
  - csmpltn 5y ago
    > "there is nothing that says it can't be as accessible as you want it to be." And there is nothing that says that it should be accessible. Which is exactly why a terminal, going by the very definition you yourself provide, is very difficult to work with from an accessibility perspective. There are simply too many degrees of freedom, allowing you to represent data in too many different ways, making it very difficult for something like a screen reader to "parse" the buffer (which can contain anything, not just text) and convert it to something meaningful. Using a terminal, one can implement a progress bar in hundreds of different ways - and it would be impossible for a screen reader to handle all such use-cases.
- ClumsyPilot 5y ago
  "Applications should share the core business logic, but have entirely seperate "frontends" for every situation." I think its clear from your post that you have never dealt with the visually impaired or even explored accessebility options of iOS/MacOS/Windows. We have working accessebility for all applications throughfully designed with native OS controls. Having separate front ends will never happen, most businesse sproduce a single bloated JS app that crashes equally on all platforms.
oefrha 5y ago
Accessibility isn't the only problem, terminal logs are also screwed up. Try scrolling up when apt is showing its fancy progress bar, you'll realize logs beyond a screenful is simply "eaten". Overall not a fan of the unnecessary TUIzation.
- mkesper 5y ago
  No problem with tmux...
bayindirh 5y ago
apt is explicitly flagged as "shall not be scripted", and older tools (apt-*) shall be used instead. I'm guessing that they're also more accessible all-over. Considering Debian installer has braille support, I don't think Debian could overlook something like this.
AkBKukU 5y ago
For apt the easy way around this is to just use apt-get since that has a traditional output. But you make an interesting point. I've lamented the current practice of hard coding escape sequences in the past for novelty reasons: https://news.ycombinator.com/item?id=26013556 https://news.ycombinator.com/item?id=26013556 But a screen reader could theoretically implement a terminfo entry that could be checked by an application to see if cursor control is supported. If not then it could fall back to a plain output method which I believe should make following along audibly easier.

darkwater 5y ago

In apt at least the fancy UI can be disabled completely, see 'Dpkg::Progress-Fancy "0";'

d_watt 5y ago

Out of curiosity, when you have a large amount of text flying by like with package installs, what is the expected accessibility behavior? I imagine a screenreader trying to keep up with the install logs in any way would be... chaotic.

miki123211 5y ago
It tries to read everything, but you can flush it with control. If you notice it stopped speaking, you usually use some review commands to look at the last few lines. If you're looking for something specific, you'd usually use something like grep, even in situations where a sighted person could just glance at the screen.
- newswasboring 5y ago
  might sound a bit insensitive. But is there a video I can see of this? I cant even imagine how this would look in the hands of an expert.
  - miki123211 5y ago
    No, not to my knowledge. I could probably find a podcast or two, there are quite a few of those aimed at a blind audience, but that's about it.
  - bhaak 5y ago
    Not exactly what you asked for but the "Designing for the Visually Impaired" episode of the Roguelike Radio podcast has a blind player play a roguelike. The intro has a bit of screenreading but the gameplay is starting at around 1:15. While listening, you should put on headphones and concentrate very hard. It's quite fast and other sensory input might be disturbing so also close your eyes. http://www.roguelikeradio.com/2012/10/episode-48-designing-for-visually.html http://www.roguelikeradio.com/2012/10/episode-48-designing-f...
  - lzybkr 5y ago
    Saqib Shaikh, a blind developer at Microsoft, gave this short talk on using Visual Studio: https://www.youtube.com/watch?v=94swlF55tVc https://www.youtube.com/watch?v=94swlF55tVc I realize this isn't a console, but I think it is a good demonstration of an expert doing typical developer activities.

lelandfe 5y ago

A good point and one I hadn’t considered before (shame on me). Does anyone have a good reference on making accessible terminal programs? As a web developer I’m intimately aware that there are many gotchas and nuances to be aware of - I have to figure the same is true of the terminal.

miki123211 5y ago
If it works correctly on an old-school TTY with a printer and a roll of paper, you're pretty much done. That's how you should view a terminal screen reader, except it talks instead of printing. Using it with a non-monospaced font would probably be a good test too. Monospace makes some implicit assumptions (i.e. being able to see how things are aligned) which screen readers don't follow. Also avoid preceding important messages with long strings of text, in particular containing numbers, i.e. overly detailed timestamps in logs. A screen reader reads text line by line, so those usually make using the app less efficient. If you want an actual user interface, not merely a command prompt, avoid the terminal like the plague. Exposing a simple web frontend might be a good idea here.

Cthulhu_ 5y ago

All terminal applications should have a 'basic' (or to use Git terminology, 'porcelain') output mode by default, and an alternative renderer for more visually inclined people as an option. Most recently, Yarn 3 went way overboard with their installer, to the point where it's... visually overwhelming? Tree views, colors, dotted underlines, multiple scrolling segments, etc. It's a bit better if running in CI mode (no coloring), but still not ideal.

deleted 5y ago
[deleted]
TeMPOraL 5y ago
On 'porcelain', the way Git uses that term is a pet peeve of mine. On the one hand, the intended meaning of it is that "porcelain" commands are meant for humans, not for other programs - scripts should use the "plumbing" commands (apparently, it's a toilet analogy). On the other hand, the flag that makes "porcelain" commands write machine-readable output is called... "--porcelain". Implying it does the opposite of what it does.
- yissp 5y ago
  Gah, I'm beginning to think the git CLI is trying to be confusing on purpose.
  - willismichael 5y ago
    https://stevelosh.com/blog/2013/04/git-koans/ https://stevelosh.com/blog/2013/04/git-koans/
    - blacktriangle 5y ago
      Is the zen of git to stop using git? Somewhat inspired by OpenBSD I spun up my most recent side project with cvs. I'm amazed how much less stressful code management has become. Makes me want to go further back in time and learn how to properly use rcs.

csmpltn 5y ago

The terminal is a visual tool. That makes it inaccessible, almost by definition. Terminals are text-based, but they can still be used to convey non-textual information (ie. progress bars, graphs, etc). There's no sense in expecting a visual application (such as the terminal) to be somehow accessible out-of-the-box. Trying to automatically translate a visual interface to an accessible interface is bound to be error prone and not work in all cases. What's accessible for a blind person, may not be accessible to a deaf person. Applications should share the core business logic, but have entirely seperate "frontends" for every situation. A graphical frontend, and an accessible frontend. We need an open cross-platform standard for this, and enforcement.

taeric 5y ago
This feels very short sighted, oddly. Your visual terminal interface is visual, sure. But there is nothing that says that has to be how you interface with a terminal. It is just a character/symbol stream connection. With interrogation commands that can go back and forth, there is nothing that says it can't be as accessible as you want it to be.
- csmpltn 5y ago
  > "there is nothing that says it can't be as accessible as you want it to be." And there is nothing that says that it should be accessible. Which is exactly why a terminal, going by the very definition you yourself provide, is very difficult to work with from an accessibility perspective. There are simply too many degrees of freedom, allowing you to represent data in too many different ways, making it very difficult for something like a screen reader to "parse" the buffer (which can contain anything, not just text) and convert it to something meaningful. Using a terminal, one can implement a progress bar in hundreds of different ways - and it would be impossible for a screen reader to handle all such use-cases.
ClumsyPilot 5y ago
"Applications should share the core business logic, but have entirely seperate "frontends" for every situation." I think its clear from your post that you have never dealt with the visually impaired or even explored accessebility options of iOS/MacOS/Windows. We have working accessebility for all applications throughfully designed with native OS controls. Having separate front ends will never happen, most businesse sproduce a single bloated JS app that crashes equally on all platforms.

oefrha 5y ago

Accessibility isn't the only problem, terminal logs are also screwed up. Try scrolling up when apt is showing its fancy progress bar, you'll realize logs beyond a screenful is simply "eaten". Overall not a fan of the unnecessary TUIzation.

mkesper 5y ago
No problem with tmux...

bayindirh 5y ago

apt is explicitly flagged as "shall not be scripted", and older tools (apt-*) shall be used instead. I'm guessing that they're also more accessible all-over. Considering Debian installer has braille support, I don't think Debian could overlook something like this.

AkBKukU 5y ago

For apt the easy way around this is to just use apt-get since that has a traditional output. But you make an interesting point. I've lamented the current practice of hard coding escape sequences in the past for novelty reasons: https://news.ycombinator.com/item?id=26013556 https://news.ycombinator.com/item?id=26013556 But a screen reader could theoretically implement a terminfo entry that could be checked by an application to see if cursor control is supported. If not then it could fall back to a plain output method which I believe should make following along audibly easier.