>But, on a large project, with a large team, carefully managing such details can become a really hard task to get right. Suddenly a dark button has unreadable black text, and users can’t figure out what to do.

Cant someone take a look at the buttons before the large project ships? Alternatively make it mandatory to never have black text on a dark button and tell every team member including the large ones.

Interesting to read about the perceptual contrast vs mathematical - I did not know that. Going to integrate that into my workflow.

there is a way to do something close to this using lch:

  --text: lch(from var(--bg) calc((49.44 - l) * infinity) 0 0);

source: https://til.jakelazaroff.com/css/swap-between-black-and-whit...

I'm still not convinced that the contrasting colour should be the browser vendor's decision, it won't always be right or predictable. Will this be a definitive deterministic standard across all browsers? Instead this function feels like a tool to help UX teams during design phase.

This is a great overview of the pros/cons of this. For those creating just a simple site, this is a solid easy way to have proper contrast.

For those making anything at a production scale where you need wcag compliance however, I'd avoid this and leverage a proper semantic token layer. Semantic tokens will help both accelerate your dev cycle, and they'll help guarantee proper contrast ratios in a way that looks visually better than just switching your foreground layer to black or white. The great thing about a semantic token layer is they're extremely easy to theme, which means you get light/dark theming for very little additional cost. You can also create separate WCAG2 / APCA accessible themes, should your brand color be one of the ones that WCAG2 has issues with - will get you compliance while still providing a better visual contrast option.

This is kind of my niche domain specialty - I run the variables/tokens stream at Figma, and I've worked on the dark mode implentation for both Figma and Atlassian. Happy to answer any questions about tokens/themes/accessible color.

For this problem, I'm working on a tool to help create palettes where color pairs have simple and predictable WCAG/ACPA contrast by design (it has more features on desktop):

https://www.inclusivecolors.com/

So one approach is you create swatches of different colors that go from grade 100 (light) to grade 900 (dark), where the lightnesses are chosen such that all grade 700 colors contrast against grade 100 colors, all grade 800 colors contrast against grade 200 etc.

And then you know red-700 vs gray-100, green-800 vs yellow-200 and so on will contrast without having to check.

If you go to the Contrast menu, you can also explore how much stricter the APCA algorithm (meant to be more accurate) is compared to WCAG. For dark on light colors especially, APCA is much stricter about what contrast so you really shouldn't use WCAG for dark themes.

Also, if you go to the Examples menu and check out the Tailwind and IBM Carbon color palettes, you can see how the swatches in hand designed palettes vary their saturation and hue across grades in a non-linear way. So automatically picking if white/black contrasts the best is more straightforward (like the article mentions), but for more deliberate/branded palettes, you can't just generate a color with a simple lightness component shift, so this is more open ended.