5 ms·

> If your software outputs color by default, please consider not doing so. Quite opinionated for not giving additional 𝘃𝗮𝗹𝗶𝗱 arguments. Also the argument

• 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.
  • 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]
• tgv 3y ago
  I'll give you an argument: it's difficult to read colored output, at least for me. Perhaps it is because I'm colorblind, idk, but the output of e.g. "ls" makes it hard to find certain files. The directory names get all fuzzy, and 'tgz' files scream. It takes much more effort to parse than uncolored output. And terminal colors are just garish, but that's a matter of taste. > accessibility best practices suggest to convey semantically relevant markup and content in multiple sensory means Yeah, we might not agree on that. That practice might be a tad overrated or overused. In some contexts it might make sense, but that doesn't mean any semantic difference should be expressed. E.g., why should "ls" assign different file types different colors? Did I ask for it? Are they not all file names? Why not color by file size? Or by age? How am I going to remember those colors? Plus, it's unusable in a script, because then "ls" suppresses the color. But why argue (pretty harshly) against a proposal that won't affect the way you see the output? And why give such a weird, unfriendly option to remove color?
  • Kwpolska 3y ago
    > And terminal colors are just garish, but that's a matter of taste. You can change the specific colors used by your terminal emulator, at least for the basic 16 colors. > E.g., why should "ls" assign different file types different colors? Did I ask for it? Are they not all file names? I agree that coloring .tgz is useless. But it is useful to be able to tell directories, executables, symlinks apart (I also use the -F flag to have a textual indicator). > Did I ask for it? Why should `ls` show files in alphabetical order? Wouldn’t the last-use order be more helpful? Why is the default wallpaper of Windows 11 a blue flower-ish thing? Did I ask for it? Software has defaults, and then Linux distros may add their customizations on top. Are those defaults the universal best way to do things? No. But usually, you can just customize them to your liking.
    • tgv 3y ago
      > You can change the specific colors used by your terminal emulator, at least for the basic 16 colors. Doesn't that contradict the "semantic marking" argument? Now you can't predict what the output will look like, and someone might like the color of grep output, but not ls. I simply alias most commands that output color, BTW. The GNU utils all seem to support --no-color, and that's reasonable too, and flexible, except aliasing can be a bit tricky, and you have to add it for multiple commands, and scripts often don't recognize it. The only disadvantage of NO_COLOR is that you can't unset it at the start of the command line. At least, I wouldn't know how. NO_COLOR=true/false could be switched per command. > Why should `ls` show files in alphabetical order? Wouldn’t the last-use order be more helpful? Apart from the fact that looking for a name becomes harder (and you clearly don't know what you're looking for if you only use ls), that ls -1tr is your friend, and that there always is some order, last-use order doesn't make sense for other cmd line utilities. There's no point in a global "SORT_ORDER=last-use" environment variable.
• quicksilver03 3y ago
  > Also the arguments regarding colorblind crowd being unable to distinguish colors are weak, as accessibility best practices suggest to convey semantically relevant markup and content in multiple sensory means, so that everybody has their chance to understand it (e.g. setting links in a distinguished color and underlined). It's not color blindness, it's lack of basic testing in real-world conditions where not everyone can use dark-themed terminals. The default colors in Debian's 'ls' output, or 'ncdu', blend perfectly with a light background theme, so the net result is a loss of information for the user.
  • citrin_ru 3y ago
    I'm using terminals with dark background and often suffer from programs using dark blue which is hard to distinguish from the background (even with changes in terminal settings to make it less dark). So at least some by default expect light background. Vim being one of them (I have to keep COLORFGBG='default;default;0' in environment for it).
    • anthk 3y ago
      Use the Tango color scheme.
    • kps 3y ago
      vim predates the fashion for dark backgrounds, so it gets it wrong for a different subset of people. Try `set background=dark` in your .vimrc. (I believe neovim uses the DCS 11 inquiry to determine the actual background colour on xterm-compatibles. I believe vim currently does not, relying on environment variables only. I may be stale or otherwise mistaken on both.)
      • Jorengarenar 3y ago
        > vim predates the fashion for dark backgrounds, If anything, the correct version of this statement would be "Vim was created when light backgrounds were a fad". The "natural" background of the terminal is dark, including ADM-3A (terminal "responsible" of vi's HJKL).
• josteink 3y ago
  > as accessibility best practices suggest to convey semantically relevant markup You may have missed that this is about CLI applications, not web-pages.
  • yreg 3y ago
    Accessibility is important for everyone, CLI users included. If you live long enough, you will depend on accessibility features yourself.
    • josteink 3y ago
      Sure. But CLI apps don’t have markup, much less semantic markup. That was my point.
• cumshitpiss 3y ago
  [dead]
• Simplicitas 3y ago
  I stopped reading right after that silly comment - the world is full of colors!
• brookst 3y ago
  Very colorblind here. I would much rather have accessible use of color than black and white. The whole thing is like saying that the best way to accommodate wheelchairs is to bulldoze the world to completely level everywhere. No. Accessibility is about awareness. We use ramps, rails, elevators, and other tools to make a 3D world accessible to people who rely on wheels. Similarly, here is the one thing you need to know to use color accessibly: think in HSB (or HSL or HSV), and always vary at least two of those dimensions. I am fine if you want to use red/green for status as long as it is light red and dark green (or vice versa). Encoding information redundantly in two dimensions makes the result accessible to those who can’t see some/all difference in one of those dimensions. There. Now you can enjoy your damn purple skies and green fire trucks without worrying about me.