Feedback from color blind users

[jamestalmage]

We currently use red / yellow / green to signal error / warning / ok level messages.

@bcoe brought up a good point in an nyc thread.

red/green is a bad color scheme for a good chunk of the male population

I know very little about being colorblind aside from what I've read on Wikipedia, so I would like to here from colorblind users.

1. Is it a big deal to you that AVA try to output colorblind accessible colors?
2. Is it typical to make these adjustments at the OS level? I know Terminal.app on the mac allows you to change the ansi color scheme, so maybe that's the de facto solution for colorblind users (manipulate the color scheme to one they can see).
3. Would there be a better set of colors? Ideally one that offered the same intuitive feedback for non-colorblind users.
4. Can it be reduced to a single color set, or does it need to be configurable depending on what type of colorblindness you have?

If you aren't comfortable discussing this in an open forum, please email me (my email is available on my profile page).

[bcoe]

@jamestalmage if I recall @isaacs did a lot of research into this when he was coming up with a color scheme for node-tap.

[jamestalmage]

https://github.com/tapjs/tap-mocha-reporter/blob/master/lib/reporters/base.js#L54-L75

[sindresorhus]

I naively assume setting it in the terminal would be the best solution as it would fix it everywhere, not just in this project, but would be cool if someone knowledgeable about this would comment here (or email James).

[isaacs]

tap's default reporter does use quite a bit of red and green. Mostly, the difference between red and green is also communicated by the text itself, so it's fine.

Where it gets tricky is in the diff coloring, where red and green colors carry a lot of the semantic weight. I sought out various sorts of less-color-sensitive folks on Twitter, and used Sim Daltonism to verify that the + and - coloring was distinct in every setting.

[davewasmer]

Moderate deuteranope weighing in here:

Is it a big deal to you that AVA try to output colorblind accessible colors?

As long as additional, non-color indicators are present, it's not critical (i.e. + and - next to diff lines).

Is it typical to make these adjustments at the OS level? I know Terminal.app on the mac allows you to change the ansi color scheme, so maybe that's the de facto solution for colorblind users (manipulate the color scheme to one they can see).

For me, yes. I've picked (and tweaked) a color scheme to have high contrast red/green, since that's a problem area of the spectrum for me.

Would there be a better set of colors? Ideally one that offered the same intuitive feedback for non-colorblind users.

I'd say leave it to "red" and "green" and let the user set their terminal to render whatever colors are sufficiently contrasty / intuitive for them. It would be difficult to find a single color scheme that worked for all types of color blindness (and potentially impossible if you consider the rare cases of totally monochromatic vision).

Can it be reduced to a single color set, or does it need to be configurable depending on what type of colorblindness you have?

Everyone's color deficiencies are different, and vary in severity. I suspect coming up with enough schemes that work for everyone isn't feasible.

[novemberborn]

Thank you @davewasmer for your input. We are prefixing lines with non-color indicators, so I think we're covered.

If anybody comes across this issue because we've ended up with unreadable output please let us know. We care, you matter.

[Laoujin]

Could we add some configuration for the colors?
For me Chalk.red is (almost) impossible to read to the point that I have to select the errors before I can make anything of the message.

chalk.js:

const Chalk = require('chalk').constructor;

exports.set = options => {
	if (ctx) {
               // Cannot easily override because of this:
		throw new Error('Chalk has already been configured');
	}
	return new Chalk(options);
};

colors.js

const chalk = require('../chalk').get();

module.exports = {
	log: chalk.gray,
	title: chalk.bold,
	error: chalk.red,
	...
};

I tried the following but it didn't take :)

const colors = require('ava/lib/reporters/colors.js');
const Chalk = require('chalk');
colors.error = Chalk.magenta;

Would a PR with an additional colors configuration option be merged?

Example package.json:

"ava": {
  // Currently available:
  "colors": true/false,

  // Would be added:
  "colors": {
	"log": "gray",
	"title": "bold",
	"error": "red",
        ...
  }
}

[novemberborn]

Hi @Laoujin, thanks for the feedback. I think ideally we'd have a theme suitable for color blind users. I'm not sure if there's any standard for CLI tools on how to indicate that preference. We could switch it based on an environment variable — that way you could configure it in your shell and any AVA-using project would pick it up, without needing additional configuration. What do you think?

[Laoujin]

I don't think you can have a "color-blind safe theme" because there are different types of colorblindness: What works for the red/green guys might not be suitable for other types of colorblindness.

But yeah, if there is any way to change red to any other color (I usually pick magenta), then I will be very happy.

If you can give a few pointers (ie: implement this like xxx), then perhaps I can help creating the PR?

[davewasmer]

@Laoujin configuring the colors certainly isn't a bad feature to add, but if you're looking for a stop-gap solution, most terminals allow you to configure your color scheme such that when ava prints something "red", you can pick what that red color is.

I've done this with my terminal setup, as mentioned above, and found it immensely helpful even outside of ava (since it affects all the terminal colors, not just one program at a time).

[novemberborn]

I don't think you can have a "color-blind safe theme" because there are different types of colorblindness: What works for the red/green guys might not be suitable for other types of colorblindness.

Yea fair enough.

I think if we can make sure we have semantic names for the colors we use, and we can configure those through a straight-forward object, then we could support an AVA_COLORS environment variables containing a JSON-encoded object. We'd decode that and merge it with the defaults. We can list sample values in the documentation.

[isaacs]

@novemberborn I did a lot of research into this a few years ago, and haven't heard any complaints about TAP ever since. #413 (comment) sums it up. The feedback I got from a bunch of people who struggle with this was:

• Use Sim Daltonism to simulate what the output looks like to various color sensitivities, and pick one that is the least useless in all the different cases.
• This means you'll probably need to use (at least) 256 color mode. If that's unavailable, use default system shell colors, since most people will customize those to be less bad.

You have my explicit permission to copy node-tap's diff coloring. It works well, and in fact, even as a person with very high color sensitivity, I've found it so much clearer that I've configured git to use that color scheme as well. It's just easier to look at.

Keep in mind that it's not just color blindness to worry about. There's huge variability on how people respond to contrast as well. High contrast is necessary for some, but harmful for others, and same for low contrast. Some people can't easily look at light on dark, and others, dark on light. Accessibility is tricky.

Supporting an easy way to configure the colors is often best.