Comment by seanwilson
21 hours ago
> This process means that there is some error. For example, ideally, a color with L=50 looks twice as bright as a color with L=25. Except, with very strongly saturated colors like red, this isn’t actually the case in any of these color spaces.
A benefit of doing it this way is you account for color blindness and accessibility e.g. all colors at L=50 will have the same WCAG contrast ratio against all colors at L=25. This helps when finding colors with the contrast you want.
Related, I'm working on a color palette editor based around creating accessible palettes where I use the HSLuv color space which has the above property:
https://www.inclusivecolors.com/
You can try things like maxing out the saturation of each swatch to see how some some hues get more bold looking at the same lightness (the Helmholtz-Kohlrausch effect mentioned in the article I think). You can also explore examples of open source palettes (Tailwind, IBM Carbon, USWDS), where it's interesting to compare how they vary their saturation and lightness curves per swatch e.g. red-700 and green-700 in Tailwind v3 have different lightnesses but are the same in IBM Carbon (the "Contrast > View colors by luminance only" option is interesting to see this).
I've found the WCAG contrast ratio to be almost worthless. Unless you have a legal requirement to use it, I'd stay away.
Why worthless? I'm not saying it's perfect, but isn't it a better-than-nothing guide? If you've got good eyesight, it's not always intuitive which colors have good contrast. If WCAG says the contrast is bad, it's probably bad (but there are known exceptions where it gets it wrong).
https://www.inclusivecolors.com/ includes the APCA contrast measurement which is meant to be more accurate than WCAG, if you want to experiment with how it compares.
WCAG and APCA mostly agree on what has good vs bad contrast for dark on light color pairs with some exceptions. For light on dark colors though, WCAG isn't accurate and ACPA is much stricter in what's allowed.