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):<p><a href="https://www.inclusivecolors.com/" rel="nofollow">https://www.inclusivecolors.com/</a><p>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.<p>And then you know red-700 vs gray-100, green-800 vs yellow-200 and so on will contrast without having to check.<p>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.<p>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.
there is a way to do something close to this using lch:<p><pre><code> --text: lch(from var(--bg) calc((49.44 - l) * infinity) 0 0);
</code></pre>
source: <a href="https://til.jakelazaroff.com/css/swap-between-black-and-white-text-based-on-background-color/" rel="nofollow">https://til.jakelazaroff.com/css/swap-between-black-and-whit...</a>
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.<p>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.<p>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.
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.
>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.<p><i>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.</i><p>Interesting to read about the perceptual contrast vs mathematical - I did not know that. Going to integrate that into my workflow.
Back when systeem colors were actually cool I made some system color styles. It looked really nice but you don't know how they contrast. That one is called [say] buttonFace and another buttonText turned out to to be meaningless. Someone wrote some js for me that took getComputedStyle and calculated the contrast. If it was unacceptable it either took a second candidate color or failed back on text-shadow to darken or lighten an aura around the text sufficiently.<p><a href="https://i.sstatic.net/18bQt.png" rel="nofollow">https://i.sstatic.net/18bQt.png</a><p>I forget the calculation but thinking about it you can probably just take the average of the 3 rgb values and compare them(?) It would produce a low value for blue and give preference to white text.
At a minimum it would be nice to know good colors for the pseudo classes active, focus, hover, link, visited and their various combinations for a light and dark theme. Additionally material UI adds disabled, before, after.
I made a video tutorial about a similar thing long time ago - choosing black or white for text color given a color background. My solution was very simplistic. I just transformed the color to gray scale and compared it between black and white. It was a fun project. I'm not good making videos though.<p><a href="https://youtu.be/tUJvE4xfTgo?si=vFlegFA_7lzijfSR" rel="nofollow">https://youtu.be/tUJvE4xfTgo?si=vFlegFA_7lzijfSR</a> (warning: video is in Portuguese)
You choose all the colors in a color scheme, so why is this easier than just choosing a contrasting button text color in the first place? This is a feature to help teams so dysfunctional that individuals are free to choose an inconsistent background color yet at the same time aren't able to choose a contrasting foreground color?<p>What really needs a fix is when you have text over an image or other diverse background (like, sticky/fixed text over a scrolling background) and need to have it always visible. And... this doesn't help at all.<p>So not only does this only (maybe) help in very questionable circumstances, they needed to come up with an entirely new verb for it, it has an anemic feature set (only selects black or white), and they did it with the worst possible contrast selection algorithm (doesn't select the choice with the most perceptual contrast). Way to go!
Is there a good alternative for this that is done at build time? Something that works on top of SASS, Tailwind, etc?<p>It will take some time until this feature is broadly available, and I'm having some doubt that it will be implemented in the same (or correct) way on all platforms.
Tentative future of this feature, that addresses many concerns in this thread:<p><a href="https://drafts.csswg.org/css-color-6/#colorcontrast" rel="nofollow">https://drafts.csswg.org/css-color-6/#colorcontrast</a>
Recently I made a little hypertext browser in 500 lines. Then I added this sort of automatic contrasting color selector in another 200 lines. In the process I learned a lot about color spaces.<p><a href="https://akkartik.name/post/2025-04-04-devlog" rel="nofollow">https://akkartik.name/post/2025-04-04-devlog</a><p>One difference in my approach is: it's an authoring-time tool. If no sufficiently contrasting color exists you get an error. And so you have to change the background until there is one.
Cool! I did a similar thing manually with python and terminal colours <a href="https://calbryant.uk/blog/destroying-the-right-server-with-colour-association/" rel="nofollow">https://calbryant.uk/blog/destroying-the-right-server-with-c...</a>
I remember doing something similar back in the day using YIQ value - <a href="https://medium.com/@gkobilansky/a-color-changing-take-on-the-sticky-menu-8096ddd533df" rel="nofollow">https://medium.com/@gkobilansky/a-color-changing-take-on-the...</a>
Here's one method for this that I have bookmarked: <a href="https://miunau.com/posts/dynamic-text-contrast-in-css/" rel="nofollow">https://miunau.com/posts/dynamic-text-contrast-in-css/</a>
Surely the relative colour theory colour wheel is the answer to this problem.<p>"Color Wheel: The Basic Color Theory for Artists and Designers"
<a href="https://dessign.net/color-wheel-theory/" rel="nofollow">https://dessign.net/color-wheel-theory/</a>
The article is wrong:<p>- Their work <i>does</i> ensure contrast.<p>- The white on blue clearly has <i>less</i> contrast, not <i>more</i>. (squinting is a cheap way to test, or, walking backwards from your monitor)<p>With APCA, backgrounds around L* 60 tend to still allow white foregrounds, which is <i>aesthetically</i> closer to what the eye wants.<p>A black foreground would have more contrast regardless, even by APCA.<p>To be fair, this is how APCA is almost always demonstrated as a win over the long-running standard, so people run with the premise that the demo image of APCA is <i>more contrast</i>, rather than "ours say you'll have <i>enough</i> contrast to be accessible with a white foreground, even if it also says the contrast would be higher with a black foreground".<p>(source: in 2020 built color system around the same science, enabling latest iterations of Material theming)