Hacker News Reader

Comment by Eduard | Hacker News Reader

> If your software outputs color by default, please consider not doing so.

Quite opinionated for not giving additional 𝘃𝗮𝗹𝗶𝗱 arguments.

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

Using colors (e.g. rkhunter malware report with its hundreds of checks uses green for success and red for warnings/errors) is not only enjoyed by many, but a relieve for ADDeez.

Whoever doesn't want to have color, just pipe anything through ansi2txt; https://askubuntu.com/questions/984357/how-do-i-pipe-each-co...

View on HN

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

Emacs is fine at screen reading in a terminal environment.

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?

Emacs has Emacspeak which works on everything.

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

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

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.

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

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

To be clear, my issue is with the phrasing "non-binary". Imo, such phrasing attempts to squelch discourse by attempting to claim authority. If you claim that something is "non-binary"... can you use your words to explain how? A "binary" situation means that one of two things will happen. How is your example excused from binary representation?

In this case, it seems a perfectly valid choice of words.

"irreconcilable" basically implies that there is a binary choice -- either use a TUI or aim for accessibility, but you can't have both. The responder was saying that actually it's not a binary choice -- there are degrees of accessibility, and some accessibility can be attained within a TUI.

Disagreeing with someone, using valid arguments, is not the same as squelching discourse.

> Disagreeing with someone, using valid arguments, is not the same as squelching discourse.

I can relate with your position; I understand what you're saying. I guess my point is that some words that humans speak can strike a nerve in others. For instance, apparently I'm a huge Temple Grandin fan. I didn't know that until I mentioned the name Temple Grandin to my girlfriend of nearly five years recently and she basically snapped and told me that she never wanted me to say that name again. Apparently when I first met her I had a lot of good things to say about Temple Grandin, and I guess throughout the following five years I've mentioned Temple Grandin enough that it just raises her hackles when she hears it now. She's a good person, and absolutely does not have anything against Temple Grandin. She just doesn't like hearing that name when it's my voice speaking it.

hehe yes I can relate to that!

I'm not sure if you had this in mind when you said "non-binary", but I also think along the same lines you just noted, that there is a difference between "not binary", and "non-binary". The latter could evoke connotations to the culture wars and gender identity -- though that of course has nothing to do with accessibility (of TUIs, bathrooms might be another matter).

Then again, I'm neither American nor a native English speaker, so I hardly have much authority on this point.

I'm sorry that people downvoted you (they did it to me too, so I can commiserate). Imo, your question is totally valid. It's likely that you are correct in this case, and that I am in fact subconsciously relating the aforementioned phrase that annoys me with the painful period of social upheaval that we experienced here in the US.

It's important to remember that during that time, many words were misappropriated (edit) by both sides in order to fit an agenda. Before that period of upheaval, the phrases that were misappropriated were not generally offensive, even to the people who found them confusing. Up until that point I truly believe that most people regarded such unrelatable concepts (i.e. a person identifying as something other than their physical makeup would suggest) as being simply unrelatable, but tolerable. I don't think most people had strong feelings one way or the other before the upheaval. I think when I hear those "dirty" words now though, that I experience some form of PTSD. The people with the megaphone (again, on all sides) did a damn fine job dividing all of us, imo.

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

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.

Presumably they're referring to CLI rather than TUI applications though.

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.

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

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.

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

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.

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.

BRLTTY, for one, reads vcsa devices, which don't see CSI colour sequences at all, but are straightforward arrays of character+attribute pairs.

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

I was someone trying to connect a linux pty with the espeak backend.

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?

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

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

You can change the specific color shades to something nicer, but keep the color mapping the same (1=red, 2=green etc.), just like most of these themes: https://github.com/lysyi3m/macos-terminal-themes

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

env -u NO_COLOR command...

> The only disadvantage of NO_COLOR is that you can't unset it at the start of the command line.

There is no need. An empty string is equivalent according to the spec, so:

    NO_COLOR= command

is fine.

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

I have more luck with setting the environment variables, e.g.

    LS_COLORS="rs=0:di=0:ln=0:mh=0:pi=0:so=0:do=0:bd=0:cd=0:or=0:mi=0:su=0:sg=0:ca=0:tw=0:ow=0:st=0:ex=0:*=0:"
    GREP_COLORS=ms=0:mc=0:sl=:cx=:fn=0:ln=0:bn=0:se=0

ls assigned colors because it was configured to do so, either by you or your distribution.

> plus, it's unusable in a script, because then "ls" suppresses the color.

ls doesn't do anything different in a script, you probably just have an ls alias. Aliased are typically not sourced for non interactive shells

it depends on the invocation, and by default it checks for tty or not. the aliasing often does not touch this.

example alias:

  $ alias ls
  ls='ls --color=tty'

and from ls(1): "With --color=auto, ls emits color codes only when standard output is connected to a terminal. The LS_COLORS environment variable can change the settings. Use the dircolors command to set it."

("tty" and "if-tty" are the same as "auto")

       alias ls='ls -F'

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

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

Use the Tango color scheme.

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

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

The “natural” background for text is light though. Hard to find books, newspapers, or magazines that put a dark background behind text of any significant length.

Accordingly, the Xerox Alto had a light background too, back in the 1970s. Demonstrated here with Smalltalk:

https://youtu.be/NqKyHEJe9_w

And here with a GUI based text editor:

https://youtu.be/2Z43y94Dfzk

As did Engelbart's NLS, as seen in ‘the mother of all demos’. https://www.youtube.com/watch?v=yJDv-zdhzMY

What little actual research exists suggests dark on light is more readable for people with normal vision. People with cataracts benefit from light on dark, and people with astigmatism benefit from dark on light.

Light background for books IMHO is no more natural than dark background for old CRT displays - both are what works best for a given medium: while making dark paper is not harder than light one, it is hard to make a pencil or ink which would be clearly visible on black paper (white markers do exists but they are a recent invention). Blackboard and chalk where natural until we got plastic whiteboards and easy to erase markers.

Modern screens are more or less unique in not limiting background colors so we can use any and and argue which one is better.

Actually there is at least one more common media where we can freely choose between dark and light (at least in the last 100+ years) - guide signs on roads. Both options are common (e. g. white on green/blue and black on white). But even if there are studies showing which background is better for signs it is not necessary the same for a computer screen: road sign should be legible from a maximum distance under variety of conditions - from a sunny day to LED lighting at nigh or heavy rain. Legibility is the main design goal. Computers on other hand are usually used in an environment where we can control lighting to some degree and a distance is fixed. Legibility is important but comfort is important as well (choose of colors should minimize eye strain / fatigue in case if it can affect this).

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.

> as accessibility best practices suggest to convey semantically relevant markup

You may have missed that this is about CLI applications, not web-pages.

Accessibility is important for everyone, CLI users included. If you live long enough, you will depend on accessibility features yourself.