4 ms·

> Also the arguments regarding colorblind crowd being unable to distinguish colors are weak Especially since accessibility in terminal environments simply isn'

by p-e-w 3y ago

> Also the arguments regarding colorblind crowd being unable to distinguish colors are weak Especially since accessibility in terminal environments simply isn't a thing. The terminal is a grid of cells that contain individual characters. Screen readers and other accessibility tools cannot know whether those characters constitute runs of text or separators, they cannot know which texts belong together, what their semantic relation is, etc. etc. If accessibility is something you care about, don't write TUI programs. The two concepts are irreconcilable. Proper accessibility requires semantic labeling of visual output, and the terminal display protocol doesn't provide that capability. Hand-wringing about a specific aspect like color blindness only serves to avoid discussing the elephant in the room, which is that TUI programs are fundamentally not accessible.

Conscat 3y ago
Emacs is fine at screen reading in a terminal environment.
- funklute 3y ago
  Do you mean for simple command line output, or also for actual TUIs, like htop and vim? If the latter, how does that even work? Presumably you'd have to configure it on a per-TUI basis, which is exactly the point of the parent -- it's not accessible out of the box, no matter what you do...right? Or can it be more clever than that?
  - anthk 3y ago
    Emacs has Emacspeak which works on everything.
alpaca128 3y ago
> If accessibility is something you care about, don't write TUI programs. The two concepts are irreconcilable. They're not irreconcilable because accessibility is not binary. Not every user benefitting from accessibility features is blind. Sometimes people without any disability prefer e.g. high-contrast modes, some people just dislike rapidly flashing lights even if they don't get seizures from it, some may just see no benefit in terminal coloring except in some rare cases. Many terminal programs already support various color output options, additionally checking an environment variable isn't a big deal and doesn't affect anyone not using it.
- dumpsterdiver 3y ago
  > They're not irreconcilable because accessibility is not binary. Not every user benefitting from accessibility features is blind. I'm always curious what someone means when they say that something "is not binary". The phrase seems to imply that the situation is more complicated than it appears at a glance, but I've noticed a pattern in which the people who claim things to be "non-binary" habitually dismiss valid prose before actually engaging with them. They don't tend to actually explain themselves, they simply spout unverified information as if it is truth.
  - capableweb 3y ago
    It's programmer's version of "it's not black or white". In this case, a program isn't "accessible" or "not accessible" but rather degrees of accessibility. Not everyone is 100% blind, so small accessibility features makes it easier for them while not being accessible to 100% of the population.
    - dumpsterdiver 3y ago
      > It's programmer's version of "it's not black or white". I am aware. My issue is with people using the phrase as if the folks they are arguing with aren't aware that the world isn't black and white, but actually a complicated place in which nuance and forethought are the norm.
      - capableweb 3y ago
        To be fair, parent poster did write: > If accessibility is something you care about, don't write TUI programs. The two concepts are irreconcilable. Which seems to indicate they see accessibility as something that is black or white, either you're accessible and don't write TUI programs, or you go ahead and write TUI programs and forget any sort of accessibility. While the reality is that even if you write TUI programs, you can make them more accessible by following paradigms like "don't just use colors as visual indicators".
vanous 3y ago
> If accessibility is something you care about, don't write TUI programs. The two concepts are irreconcilable. If I write for myself and package/publish for others, the user has a choice not to use my program.
arp242 3y ago
I've heard from multiple blind people over the years that terminals are actually quite nice to work with, exactly because it's "just text" without too much bruhaha.
- tpoacher 3y ago
  Presumably they're referring to CLI rather than TUI applications though.
  - arp242 3y ago
    Maybe, not sure. I wouldn't quick to assume anything though – I could imagine at least some TUIs could possibly work quite well, perhaps with some minor setup.
hulitu 3y ago
There is more accessability besides screen readers. Not all people are blind. Some people just want bigger fonts and better contrast.
- jnovek 3y ago
  This is a point of frustration for me -- I have reduced vision, but I wouldn't even qualify as legally blind. It impacts me to the degree that I don't drive a car, which is pretty inconvenient living in America. There's a whole world of options between "tiny fonts on a high resolution screen" and "screen reader" but things like large fonts, legibility-focused typefaces, zoomable applications and high contrast don't seem to be a priority (looking at you, MacOS). This is all a big part of why I work primarily in a terminal emulator. I can control all of these things.
mananaysiempre 3y ago
> The terminal is a grid of cells that contain individual characters. Screen readers and other accessibility tools cannot know whether those characters constitute runs of text or separators [...]. In the default state (not on the “alternate screen” and with wrapping enabled; i.e. in ls not vim) terminal emulators do record which runs of text belong together and which don’t, in order to be able to rewrap lines if the user resizes the window. (This is as universal as it is unspecified. Which is a shame, because it’s highly non-obvious how this should interact with e.g. programmatic cursor movement.) I know nothing about the accessibility story, but the “grid of cells” picture is simply untrue.
- JdeBP 3y ago
  This is false. Only GUI terminal emulators do it this way, and only some of them. Programs like BRLTTY can attach to the likes of screen(1) sessions and kernel virtual terminals. KVTs very much do have grids of cells, and that's exactly what BRLTTY opens and reads, as a matter of fact. A vcsa device file is an array of character+attribute pairs.
blueflow 3y ago
Garbage take. The terminal is quite good to work with when you are dependent on a screen reader, because its is already a serial text stream that can be converted into speech quite easily. This is a contrast to regular GUI which needs to be serialized first. And yes, you need to patch your screenreader to ignore CSI color sequences because many programs are not well-behaving and outputting them even when terminfo doesn't specify them as supported. And yes, you cannot use all TUI programs (like vi for example), but you can reliably disable these programs by using a terminfo with the hardcopy flag set.
- JdeBP 3y ago
  BRLTTY, for one, reads vcsa devices, which don't see CSI colour sequences at all, but are straightforward arrays of character+attribute pairs.
- galleywest200 3y ago
  > And yes, you need to patch your screenreader to ignore CSI color sequences because many programs are not well-behaving and outputting them even when terminfo doesn't specify them as supported. Why is this on me and not the developer of the screenreader application?
  - blueflow 3y ago
    I was someone trying to connect a linux pty with the espeak backend.
  - deleted 3y ago
    [deleted]

by p-e-w 3y ago

Conscat 3y ago

Emacs is fine at screen reading in a terminal environment.

funklute 3y ago
Do you mean for simple command line output, or also for actual TUIs, like htop and vim? If the latter, how does that even work? Presumably you'd have to configure it on a per-TUI basis, which is exactly the point of the parent -- it's not accessible out of the box, no matter what you do...right? Or can it be more clever than that?
- anthk 3y ago
  Emacs has Emacspeak which works on everything.

alpaca128 3y ago

> If accessibility is something you care about, don't write TUI programs. The two concepts are irreconcilable. They're not irreconcilable because accessibility is not binary. Not every user benefitting from accessibility features is blind. Sometimes people without any disability prefer e.g. high-contrast modes, some people just dislike rapidly flashing lights even if they don't get seizures from it, some may just see no benefit in terminal coloring except in some rare cases. Many terminal programs already support various color output options, additionally checking an environment variable isn't a big deal and doesn't affect anyone not using it.

dumpsterdiver 3y ago
> They're not irreconcilable because accessibility is not binary. Not every user benefitting from accessibility features is blind. I'm always curious what someone means when they say that something "is not binary". The phrase seems to imply that the situation is more complicated than it appears at a glance, but I've noticed a pattern in which the people who claim things to be "non-binary" habitually dismiss valid prose before actually engaging with them. They don't tend to actually explain themselves, they simply spout unverified information as if it is truth.
- capableweb 3y ago
  It's programmer's version of "it's not black or white". In this case, a program isn't "accessible" or "not accessible" but rather degrees of accessibility. Not everyone is 100% blind, so small accessibility features makes it easier for them while not being accessible to 100% of the population.
  - dumpsterdiver 3y ago
    > It's programmer's version of "it's not black or white". I am aware. My issue is with people using the phrase as if the folks they are arguing with aren't aware that the world isn't black and white, but actually a complicated place in which nuance and forethought are the norm.
    - capableweb 3y ago
      To be fair, parent poster did write: > If accessibility is something you care about, don't write TUI programs. The two concepts are irreconcilable. Which seems to indicate they see accessibility as something that is black or white, either you're accessible and don't write TUI programs, or you go ahead and write TUI programs and forget any sort of accessibility. While the reality is that even if you write TUI programs, you can make them more accessible by following paradigms like "don't just use colors as visual indicators".

vanous 3y ago

> If accessibility is something you care about, don't write TUI programs. The two concepts are irreconcilable. If I write for myself and package/publish for others, the user has a choice not to use my program.

arp242 3y ago

I've heard from multiple blind people over the years that terminals are actually quite nice to work with, exactly because it's "just text" without too much bruhaha.

tpoacher 3y ago
Presumably they're referring to CLI rather than TUI applications though.
- arp242 3y ago
  Maybe, not sure. I wouldn't quick to assume anything though – I could imagine at least some TUIs could possibly work quite well, perhaps with some minor setup.

hulitu 3y ago

There is more accessability besides screen readers. Not all people are blind. Some people just want bigger fonts and better contrast.

jnovek 3y ago
This is a point of frustration for me -- I have reduced vision, but I wouldn't even qualify as legally blind. It impacts me to the degree that I don't drive a car, which is pretty inconvenient living in America. There's a whole world of options between "tiny fonts on a high resolution screen" and "screen reader" but things like large fonts, legibility-focused typefaces, zoomable applications and high contrast don't seem to be a priority (looking at you, MacOS). This is all a big part of why I work primarily in a terminal emulator. I can control all of these things.

mananaysiempre 3y ago

> The terminal is a grid of cells that contain individual characters. Screen readers and other accessibility tools cannot know whether those characters constitute runs of text or separators [...]. In the default state (not on the “alternate screen” and with wrapping enabled; i.e. in ls not vim) terminal emulators do record which runs of text belong together and which don’t, in order to be able to rewrap lines if the user resizes the window. (This is as universal as it is unspecified. Which is a shame, because it’s highly non-obvious how this should interact with e.g. programmatic cursor movement.) I know nothing about the accessibility story, but the “grid of cells” picture is simply untrue.

JdeBP 3y ago
This is false. Only GUI terminal emulators do it this way, and only some of them. Programs like BRLTTY can attach to the likes of screen(1) sessions and kernel virtual terminals. KVTs very much do have grids of cells, and that's exactly what BRLTTY opens and reads, as a matter of fact. A vcsa device file is an array of character+attribute pairs.

blueflow 3y ago

Garbage take. The terminal is quite good to work with when you are dependent on a screen reader, because its is already a serial text stream that can be converted into speech quite easily. This is a contrast to regular GUI which needs to be serialized first. And yes, you need to patch your screenreader to ignore CSI color sequences because many programs are not well-behaving and outputting them even when terminfo doesn't specify them as supported. And yes, you cannot use all TUI programs (like vi for example), but you can reliably disable these programs by using a terminfo with the hardcopy flag set.

JdeBP 3y ago
BRLTTY, for one, reads vcsa devices, which don't see CSI colour sequences at all, but are straightforward arrays of character+attribute pairs.
galleywest200 3y ago
> And yes, you need to patch your screenreader to ignore CSI color sequences because many programs are not well-behaving and outputting them even when terminfo doesn't specify them as supported. Why is this on me and not the developer of the screenreader application?
- blueflow 3y ago
  I was someone trying to connect a linux pty with the espeak backend.
- deleted 3y ago
  [deleted]