Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Red/green colors are identical lightness, which is a huge a11y no-no #58

Open
tabatkins opened this issue Oct 15, 2020 · 6 comments
Open

Comments

@tabatkins
Copy link
Member

The red and green colors used in diagrams and text to indicate good or bad results have identical LCH lightness (both ~47.5). This is a well-known accessibility mistake, as many forms of color-blindness (not just red-green blindness, tho that's the most common form in any case) have trouble distinguishing these two colors at similar lightnesses. See https://webaim.org/articles/visual/colorblind for some details.

It's fine to keep red and green as the hues - they're evocative and have established meaning - but please change the colors to use different lightnesses. I can tag in some of the W3C a11y folks for guidance if needed.

(Note: I have deuteranopia, a slightly rarer form, and I have trouble reading the diagrams.)

@garretrieger
Copy link
Contributor

Thanks for the report. 6690821 and #59 changed the colour scheme for regression/improvement to use different colours.

@tabatkins
Copy link
Member Author

Note that 6690821 did not change the colors used; Chris added an alternate stylesheet with different colors. Alternate stylesheets are not a widely supported feature across the browser landscape, and for browsers that do support them, they're not exposed in an obvious way or easy to turn on. Hiding the accessible version of the spec behind a difficult-to-find and usually-actually-impossible-to-find toggle is not a sufficient response here, unfortunately.

@tabatkins
Copy link
Member Author

Ah, right, in Chrome at least, alternate stylesheets are just turned on all the time, so actually this does solve things now.

(The colors are ugly, but they're certainly distinguishable, so that works.)

@svgeesus
Copy link
Contributor

It's fine to keep red and green as the hues - they're evocative and have established meaning - but please change the colors to use different lightnesses.

The trouble is that for text on a white background, making one of the pair much lighter than the other looses contrast against the background.

I was thinking that, in addition to different colors (in the text and in the graphics), using different text styling for one (like small caps or italics) would also make them more distinguishable.

@tabatkins
Copy link
Member Author

They don't really need to be "much" lighter/darker. Just not the literally identical lightness that they currently are, which appears to have been done intentionally (since the HSL lightness values are different, but the more accurate Lab lightness values are within 0.2 of each other).

If you were to hue-shift, just changing the red to, say, a blue or purple, while slightly lightening the green, should do fine. Then you at least still get the green=good correspondence, rather than having a more confusing brown=good purple=bad correspondence.

@tabatkins
Copy link
Member Author

tabatkins commented Oct 20, 2020

Tho, playing around a bit, it looks like the purple you used is LCH lightness 54, and the brown is LCH lightness 36.

Staying within red and green, using hsl(0, 100%, 35%) gives LCH lightness of 38 while still being recognizably red, and hsl(120, 100%, 30%) gives LCH lightness of 55, and is definitely a recognizable green. So that gives us nearly identical lightness values without compromising on the original color choices.

(WCAG 2.0 judges the green to be insufficient while the purple is okay, but we're all aware of the limitations in WCAG's contrast calculations. I think the Lab-lightness calculations are more meaningful, right?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants