Friendly plug for HCT -- it's a color space I built to enable Material You, it weds the lightness measure mentioned here to the latest and greatest color science space --- LAB/LCH is from 1976!
It makes design more intuitive, they only need to know that a 40 difference in 'T' ensures that WCAG standards for buttons are met, and a difference of 50 meets the standards for text.
Cool! Any thoughts on how HCT compares with https://www.hsluv.org/comparison/? (Similar with HCT, the difference in "L" here makes picking contrasting colors more straightforward)
On the same topic, any thoughts on https://www.myndex.com/APCA/ and approaches if this becomes a standard? The color contrast value between a pair of colors depends on which color is the foreground and which is the background, so just comparing the difference in "T" won't be enough now?
re: HSLuv, I don't know much of it but I've heard it mentioned several times, so it must be helpful. This comment[1] goes into more detail, but TL;DR the core to me seems to be having L* and whatever H and S measurement works for you, so I'd say HSLuv is spot on.
I love APCA, Myndex (Andrew Somers, APCA author) was an absolute inspiration to me for getting interested in color, I wouldn't have known 1% of what I do or have done 1% of it without his deep dives showing how to work in this space.
It has an interesting effect on the community in that the general language around it is read too strongly: it is an important and crucial advance, getting science-backed data on exactly the right contrast in multiple scenarios is _absurdly important_ in a world of Ambient Computing™.
The mistake that's made is reading into this too heavily as _the previous spec or WCAG aren't based on data at all_.
Yes, the calculation is based on absurd stuff -- 100 nit monitor, you can't track down a source for every bit of it.
But there's a _whole separate field_ that spatial frequency comes from and it is _very_ well known and understood.
Most importantly: the APCA predictions for contrast were only about 5-7 L* different last time I checked. This is important, thats a _lot_ --- but it also isn't a lot, that's on a scale of 100. What we have today isn't completely utterly alienly different and broken.
Comparing the difference in T will be enough as long as the luminance measure APCA relies on is monotonic to RGB (HSL's lightness is hilarious, its the max of RGB minus min of RGB)
Are there any good resources to learn how to use it?
Let's say that I knew that I needed 6 colors in an application: a red, a yellow, a blue, an orange, a green, and a purple — that is, the 3 primary colors and the 3 secondary colors. Finally, say I didn't care much about which colors I arrived at, but that I would like to try to equalize for brightness (maybe saturation, too?) while being somewhat identifiable as those 6 colors.
I'm sure there's no exact answer, since Yellow is very bright and blue is very dark, so I'd probably have to arrive something approximate.
How would I do that? Are there tools or tutorials for learning such a thing?
That's the sales pitch for HCT, you get to claim you can normalize along C to get similar colorfulness, or normalize along T to get similar lightness (with the bonus of T getting you the WCAG/a11y compatability). And why is yours right? Because you used the latest and greatest color science for H (hue) and C (chroma / saturation) and great color science for T, matches WCAG.
This isn't quite as helpful as it might sound, i.e. it can't settle all debates, then design needs to become playing within the system: ex. lets say you land at you want mostly pastels. You could settle on lightness 90 -- get nice yellows, teals, but...no red!?!? It turns out light red is pink. And then on top of it, the yellows and teals colorfulness can get crazy high: lets say 80. But red can only get to 16, this breathy pink.
This can be extremely aggravating, ex. yellow. It just doesn't contrast with white, there's absolutely no way to get any a11y number to tell you that a nice bright yellow can be a button in light mode. But the system is empowering in that you know you can't do any better on the implementation, and you can trust the #s.
That sounds like the answer to my question is: that's what HCT is meant for, but no there aren't any such resources, because it’s supposed to be as simple as tweaking the numbers. Am I reading that right?
Also, I'm getting the impression that I'd have to be working in the Android ecosystem, maybe?
100%, I used to joke the reason for this is its the "nobody got fired for buying IBM" color system.
#1 it takes the most modern widely accepted space in color science, CAM16 for hue and colorfulness. CAM16 is relatively incredibly complex, about 500 lines of code.
#2 it maps it to L*.
#1 is because nobody gets fired for basing Google's color system on CAM16.
#2 is for WCAG.
There was continually interesting conversations on what exactly the name of the space was and whether it represented a new color space that precluded more formalization of it, the code ended up being the spec as it were. I did get a blog post out: https://material.io/blog/science-of-color-design
It makes design more intuitive, they only need to know that a 40 difference in 'T' ensures that WCAG standards for buttons are met, and a difference of 50 meets the standards for text.