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):
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.
Can honestly say this article changed my perspective on this subject drastically, such an amazing tool. I was very surprised that my designer friends hadn't heard of oklch at all, it solves a whole category of problems.
I’ve never seen any CSS function that has this call back style where you get parameters that you can modify. So interesting! Are there any other examples of this or is this unique to lch?
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.
With regards to color on the web, semantic tokens refer to css variables that are named in a way that describes their use, ie:
* bg-brand (this would be used whenever you need your brand color as a background)
* text-danger (likely a red text color)
* icon-warning-hover (likely a dark yellow-orange that's slightly different from icon-warning)
Generally speaking, there are three "levels" of tokens: primitive, semantic, and component. Primitive tokens describe the value. In the case of color, this might be a color ramp. IE red/100, red/200, red/300. Semantic tokens reference primitive tokens. IE bg-brand might have its value set to blue/300. This layer is sometimes called a "reference" layer because of this, but I'm not a fan of that nomenclature since the component layer also references the semantic layer. The component layer is one that describes where in a component the token should be used, ie button-bg or button-text. I highly, HIGHLY recommend against using a component layer though in all but the most extreme multi-brand situation. If you aren't unilever, you should never use component tokens.
Nathan is talking about naming schemes within each tier I mentioned, not different tiers. That blog is detailing naming schemes for the semantic and component layer.
The primitive/semantic/component set of tiers are a general practice. Naming within them heavily differs (and should!). The names you use for the individual tokens depend on goals and intent - ie Google’s material’s semantic layer uses a naming schema that’s designed for colorful variety of themes (albeit at the expense of clarity of how they should be used), whereas Apple uses a far more simplified naming schema since the design of their apps has far fewer design differences.
I don’t disagree, in fact I absolutely agree but the last 2/3 just sounds like meaningless jibber jabber to make yourself look smart. I’m not saying it’s not true but it’s word vomit.
I like the feature but in a corporate site/application, you don’t want to rely on this function because you cannot control what the result is going to be. For all I know, WebKit could fix some later bug or change something that changes the result color to something that I don’t want.
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.
I'm already feeling some issues with HDR displays, embedded devices, and other special cases. The standard Safari on macOS/iOS and chrome on Windows/Linux/Android are probably going to handle it correctly. But I'm very happy if proven wrong :)
Consistent, it is not. Ex. we can imagine a background at L* 50 that is ~equally served with a white or black foreground - in that case, the aesthetic principles come into play.
To also disambiguate that, and get to 100% reliable, if both a darker and lighter color are available given contrast K and background color C, look at C, if it's L* is >= 60, choose lighter.
>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.
> Cant someone take a look at the buttons before the large project ships?
They can, of course, but this is how you end up with pre-release regression testing cycles that are weeks or even months long. A "large project" might easily have thousands of buttons (or more!), many of which are only seen when certain settings are enabled, certain options are chosen during a complex workflow, etc.
You can have them with WCAG2, the stock APCA example hides the ball significantly and leads to a lot of incorrect conclusions in the article (tl;dr: black has more contrast by either measure, its just that APCA says you don't need as much contrast, so you can use white and have sufficient contrast)
No it doesn't? The screenshot of the calculator in the blog post very clearly shows that white has a greater contrast according to APCA. (If the negative numbers are confusing, you can also put the colors into a BridgePCA calculator like https://www.color-contrast.dev/?txtColor=FFFFFF&bgColor=317C... to see WCAG-2-style "contrast ratio" metrics computed using APCA.)
The point of APCA is to make the contrast calculation more perceptually accurate, not just lower the threshold.
I know about WCAG, too. You can also just implement a function that detects whether or not a color is dark or not. It is a general purpose function, e.g. my "isDark" function is: "func() < 0.5" (func() is omitted, but it is an algorithm). You can have "isLight", too, by doing "> 0.5". There are many ways to do this. You can just simply convert a hex color to RGB, then compute the luminance of the color, and then compare the luminance to a threshold (e.g. 0.5) to classify it as dark or light. The luminance function (WCAG luminance formula) converts RGB values to the range 0-1, applies gamma correction, and calculates luminance using the weighted sum of the gamma-corrected RGB values.
> APCA says you don't need as much contrast
You can always specify the threshold if you want, e.g. "apcaContrast(color)) >= $targetContrast" after adjusting, depending on what you want to do.
It really is easy, just make sure you have enough color space.
The WCAG luminance formula (relative luminance in color science terms) has perceptual mid gray at 0.18, not 0.5.
re: just change APCA contrast target, that's separate from the Not Even Wrong stuff in the article. I didn't mean to imply APCA is wrong to say you need less contrast, but rather, that the article is wrong to conclude white has more contrast.
Well, I used 0.5 as a convenient and intuitive midpoint of the 0-1 luminance range, but this of course is a simplification and doesn't align with human perception (edit: it is aligned), it was more of an example if anything.
You are right, 0.18 is indeed perceptually closer to "middle gray" because the eye responds more sensitively to darker tones, so yeah, using a threshold closer to 0.18 makes more sense if we want to identify whether a color "feels" light or dark.
That said, 0.5 is a mathematical midpoint, but as I said, not aligned with how humans perceive brightness (edit: it is aligned).
There are two physical quantities for luminance, relative, and perceptual, so that passed along a nugget for those not as wise as you who might not know that :) As you know and have mentioned, using 0.5 with the luminance calculation you mentioned, for relative luminance, would be in error (I hate being pedantic, but it's important for some parties, a11y is a de facto legal requirement for a lot of work, and 0.5 would be spot on for ensuring WCAG 2 text contrast as long as used with perceptual luminance, L*)
> doesn't align with human perception
It is 100% aligned with how humans perceive brightness, in fact, it's a stable work product dating back to the early 1900s.
> Ultimately one could use 0.18-0.3 as threshold
Perceptual luminance and relative luminance have precise mathematical definitions, one can be calculated in terms of the other.
If you need to hit contrast K with background color C, you won't be able to treat this as variable. What you pass along about it being variable is valuable, of course, in that, given K and C, output has a range, i.e. if contrast algo says you need +40 L* for your text to hit APCA/WCAG whatever, and your C has 50 L*, your palette is everything from 90 L* to 100 L* and 0 L* to 10 L*.
So 0.5 is correct after all?! I thought I was completely off with 0.5 and I thought it does not align with human perception because I thought I was wrong. Ouch. In my defense, it has been a while. :D
BTW, would this relatively simple way to determine if the color is dark work?
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.
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.
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?
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.
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!
Its limiting to dismiss a tool out of hand simply because you haven't encountered a situation where that tool would be useful.
Plenty of web sites allow the end-user to select colors[1], or automatically derive colors from assets provided by the end-user. For those that care about accessibility, they typically calculate contrasting colors to prevent the user from creating a non-accessible experience. A built-in CSS tool like this will, hopefully, encourage more sites to provide a basic amount of accessibility while in no way hindering those who want to build an even better experience.
It would be cool if this was more customizable like the npm contrast-color package but the blog post details why they started with white/black with intentions of changing the algorithm later.
Yep. A simple use case I had was letting users create "tags" and choose their own color for the chips (think Github PR tags like "good-first-issue" "bugs" but custom)
I'm surprised parent hasn't come across this usage, I see it everywhere.
> and they did it with the worst possible contrast selection algorithm
They specifically say they are following WCAG 2 algorithms, and that WCAG 3 may correct this issue. They say that they can easily adjust to use the better algorithm in the future when it's standardized.
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.
Is there a good alternative for this that is done at build time? Something that works on top of SASS, Tailwind, etc?
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.
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.
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.
You don't need the Technology Preview, it's available as a WebKit Feature Flag under the advanced settings of normal Safari. I just enabled it on my phone and was able to view the demos.
MDN doesn't even have it yet. Looks like it's WebKit exclusive for a while.
The [draft for addition to the CSS spec](https://drafts.csswg.org/css-color-5/#resolving-contrast) just got added. Kind of wonder why Apple includes this in Safari as color-contrast rather than -webkit-color-contrast until other browsers have at least indicated a position on this draft. All I can find is decisions to defer the specifications (going back to as far as 2020).
Prefixes are no longer used for new features, and any that still exist are old. What happens now is that features are gated behind feature flags for testing until the browser working group settles on the final spec for that feature, at which point any browser-maker is free to implement it in public releases.
- The white on blue clearly has less contrast, not more. (squinting is a cheap way to test, or, walking backwards from your monitor)
With APCA, backgrounds around L* 60 tend to still allow white foregrounds, which is aesthetically closer to what the eye wants.
A black foreground would have more contrast regardless, even by APCA.
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 more contrast, rather than "ours say you'll have enough contrast to be accessible with a white foreground, even if it also says the contrast would be higher with a black foreground".
(source: in 2020 built color system around the same science, enabling latest iterations of Material theming)
> The white on blue clearly has less contrast, not more.
Is your screen really badly miscalibrated, or do you have some unusual vision condition? That’s all I can think of. I agree with the article, the white is very clearly higher contrast.
> A black foreground would have more contrast regardless, even by APCA.
OK, now I’m just baffled. The article shows the lightness contrasts for white and black on that particular blue: black gets Lᶜ 38.7, white gets Lᶜ −70.9. White foreground has more contrast, according to APCA.
I really am baffled by what you’re saying, because it all sounds coherent… except it’s all back to front.
The only explanation I can think of is that GP is, somewhat tautologically, defining contrast as "the value returned by WCAG 2's formula for computing contrast" (and, probably, assuming that WCAG 2's "science" has more basis in reality than it actually does).
I can't speak to Material You, but I've seen this sort of thinking at companies that are more concerned with legal compliance with the strict wording of WCAG 2, rather than on-the-ground user experience. People can even learn to ignore their lying eyes and fairly accurately guess what the WCAG 2 "contrast" metric for a given pair of colors will be, independently of how easy or hard the colors are to distinguish from one another.
Hopefully WCAG 3 will incorporate better color guidance from places like APCA, and at the very least these companies will stop producing unreadable black-foreground buttons and badges all the time.
Voters, I'd be very happy for feedback, I'm quite surprised it is -3.
EDIT:
I get it, it is easily read as "the entire article is wrong" instead of "the article is wrong on these points"
You're free to elaborate on your concerns. We could raise this to a conversation, I think that'll feel better for both of us than me taking that remark about me personally.
For example, I agree that the primary container color shouldn't have been L* 90 and used for buttons, and they shouldnt have severely limited chroma. In fact, I left over it and the dysfunction between VPs wondering why we didn't have it day 1, approving fixes repeatedly, and Android dysfunction that kept the conversation at "What? Didn't hear nothing from nobody in engineering! Anyways, lock screen clocks!"
I didn't vote, but "your article is wrong" take ignores literally the entire article, and the rather detailed explanation on why "bigger contrast by pure numbers is more contrast" does not work.
> in 2020 built color system around the same science, enabling latest iterations of Material theming
No wonder everything Google builds, including Material, always has issues with contrast.
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.
there is a way to do something close to this using lch:
source: https://til.jakelazaroff.com/css/swap-between-black-and-whit...LCH is awesome but OKLCH is even better!
https://evilmartians.com/chronicles/oklch-in-css-why-quit-rg...
Can honestly say this article changed my perspective on this subject drastically, such an amazing tool. I was very surprised that my designer friends hadn't heard of oklch at all, it solves a whole category of problems.
I’ve never seen any CSS function that has this call back style where you get parameters that you can modify. So interesting! Are there any other examples of this or is this unique to lch?
This is "relative color" syntax, it works with a range of color spaces/color functions. The key is the "from" at the front. Here's the MDN documentation: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_colors/...
It may be confusing, but everything here is static param. The —- prefix is css variables, where inside a css declaration block you write: —bg: blue
The `l` isn't!
Some newer ones like calc-size are also like this.
there is a good article from lea verou https://lea.verou.me/blog/2024/contrast-color/ on a workaround like this
I will trust you on that since I did see the page load before it turned white on this phone browser combination.
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.
What do you mean by semantic tokens?
This exact type of functionality has caused a major project a work on to use CSS in JS (for relative colors and contrast colors.
I’m glad to see this type of thing coming around the corner and look forward to it being widely available in a couple years.
With regards to color on the web, semantic tokens refer to css variables that are named in a way that describes their use, ie:
* bg-brand (this would be used whenever you need your brand color as a background)
* text-danger (likely a red text color)
* icon-warning-hover (likely a dark yellow-orange that's slightly different from icon-warning)
Generally speaking, there are three "levels" of tokens: primitive, semantic, and component. Primitive tokens describe the value. In the case of color, this might be a color ramp. IE red/100, red/200, red/300. Semantic tokens reference primitive tokens. IE bg-brand might have its value set to blue/300. This layer is sometimes called a "reference" layer because of this, but I'm not a fan of that nomenclature since the component layer also references the semantic layer. The component layer is one that describes where in a component the token should be used, ie button-bg or button-text. I highly, HIGHLY recommend against using a component layer though in all but the most extreme multi-brand situation. If you aren't unilever, you should never use component tokens.
Aren't there many, many schemes for naming tokens in design systems? Aren't you being a bit forward in presenting this as a general practice?
https://medium.com/eightshapes-llc/naming-tokens-in-design-s...
Nathan is talking about naming schemes within each tier I mentioned, not different tiers. That blog is detailing naming schemes for the semantic and component layer.
The primitive/semantic/component set of tiers are a general practice. Naming within them heavily differs (and should!). The names you use for the individual tokens depend on goals and intent - ie Google’s material’s semantic layer uses a naming schema that’s designed for colorful variety of themes (albeit at the expense of clarity of how they should be used), whereas Apple uses a far more simplified naming schema since the design of their apps has far fewer design differences.
Not parent, but the generalization is true. There’s usually a base layer (red/300, etc) and a more semantic layer (.text-danger).
As your link covers, there’s then a million different ways to implement/extend that based on whatever theming and systems you’re implementing on top.
This only works if you don’t let users theme your site. If you do, then OPs approach works better.
I don’t disagree, in fact I absolutely agree but the last 2/3 just sounds like meaningless jibber jabber to make yourself look smart. I’m not saying it’s not true but it’s word vomit.
I like the feature but in a corporate site/application, you don’t want to rely on this function because you cannot control what the result is going to be. For all I know, WebKit could fix some later bug or change something that changes the result color to something that I don’t want.
If you don't understand something it doesn't always make that a word vomit:)
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.
> Will this be a definitive deterministic standard across all browsers?
The article says the standard specifies the calculation to use.
I'm already feeling some issues with HDR displays, embedded devices, and other special cases. The standard Safari on macOS/iOS and chrome on Windows/Linux/Android are probably going to handle it correctly. But I'm very happy if proven wrong :)
Choose is a strange word here. There is an algorithm that calculates the color.
c.f. https://news.ycombinator.com/item?id=44015980, when you cut out the incorrect stuff due to confusion re: APCA's button example, it's a bit clearer that it's 100% right.
Consistent, it is not. Ex. we can imagine a background at L* 50 that is ~equally served with a white or black foreground - in that case, the aesthetic principles come into play.
To also disambiguate that, and get to 100% reliable, if both a darker and lighter color are available given contrast K and background color C, look at C, if it's L* is >= 60, choose lighter.
Then, it is 100% correct and consistent.
>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.
> Cant someone take a look at the buttons before the large project ships?
They can, of course, but this is how you end up with pre-release regression testing cycles that are weeks or even months long. A "large project" might easily have thousands of buttons (or more!), many of which are only seen when certain settings are enabled, certain options are chosen during a complex workflow, etc.
You may want to read about APCA, as you can have perceptual contrast calculations using the APCA algorithm.
You can have them with WCAG2, the stock APCA example hides the ball significantly and leads to a lot of incorrect conclusions in the article (tl;dr: black has more contrast by either measure, its just that APCA says you don't need as much contrast, so you can use white and have sufficient contrast)
> black has more contrast by either measure
No it doesn't? The screenshot of the calculator in the blog post very clearly shows that white has a greater contrast according to APCA. (If the negative numbers are confusing, you can also put the colors into a BridgePCA calculator like https://www.color-contrast.dev/?txtColor=FFFFFF&bgColor=317C... to see WCAG-2-style "contrast ratio" metrics computed using APCA.)
The point of APCA is to make the contrast calculation more perceptually accurate, not just lower the threshold.
I know about WCAG, too. You can also just implement a function that detects whether or not a color is dark or not. It is a general purpose function, e.g. my "isDark" function is: "func() < 0.5" (func() is omitted, but it is an algorithm). You can have "isLight", too, by doing "> 0.5". There are many ways to do this. You can just simply convert a hex color to RGB, then compute the luminance of the color, and then compare the luminance to a threshold (e.g. 0.5) to classify it as dark or light. The luminance function (WCAG luminance formula) converts RGB values to the range 0-1, applies gamma correction, and calculates luminance using the weighted sum of the gamma-corrected RGB values.
> APCA says you don't need as much contrast
You can always specify the threshold if you want, e.g. "apcaContrast(color)) >= $targetContrast" after adjusting, depending on what you want to do.
It really is easy, just make sure you have enough color space.
The WCAG luminance formula (relative luminance in color science terms) has perceptual mid gray at 0.18, not 0.5.
re: just change APCA contrast target, that's separate from the Not Even Wrong stuff in the article. I didn't mean to imply APCA is wrong to say you need less contrast, but rather, that the article is wrong to conclude white has more contrast.
Well, I used 0.5 as a convenient and intuitive midpoint of the 0-1 luminance range, but this of course is a simplification and doesn't align with human perception (edit: it is aligned), it was more of an example if anything.
You are right, 0.18 is indeed perceptually closer to "middle gray" because the eye responds more sensitively to darker tones, so yeah, using a threshold closer to 0.18 makes more sense if we want to identify whether a color "feels" light or dark.
That said, 0.5 is a mathematical midpoint, but as I said, not aligned with how humans perceive brightness (edit: it is aligned).
Ultimately one could use 0.18-0.3 as threshold.
> midpoint of the 0-1 luminance range
There are two physical quantities for luminance, relative, and perceptual, so that passed along a nugget for those not as wise as you who might not know that :) As you know and have mentioned, using 0.5 with the luminance calculation you mentioned, for relative luminance, would be in error (I hate being pedantic, but it's important for some parties, a11y is a de facto legal requirement for a lot of work, and 0.5 would be spot on for ensuring WCAG 2 text contrast as long as used with perceptual luminance, L*)
> doesn't align with human perception
It is 100% aligned with how humans perceive brightness, in fact, it's a stable work product dating back to the early 1900s.
> Ultimately one could use 0.18-0.3 as threshold
Perceptual luminance and relative luminance have precise mathematical definitions, one can be calculated in terms of the other.
If you need to hit contrast K with background color C, you won't be able to treat this as variable. What you pass along about it being variable is valuable, of course, in that, given K and C, output has a range, i.e. if contrast algo says you need +40 L* for your text to hit APCA/WCAG whatever, and your C has 50 L*, your palette is everything from 90 L* to 100 L* and 0 L* to 10 L*.
So 0.5 is correct after all?! I thought I was completely off with 0.5 and I thought it does not align with human perception because I thought I was wrong. Ouch. In my defense, it has been a while. :D
BTW, would this relatively simple way to determine if the color is dark work?
Where $threshold is 128, I think? IIRC 128 is a common threshold from what I remember, in this case.I thought the white looks sharper but is not really. I would darken the blue a bit to be happy about it.
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.
https://i.sstatic.net/18bQt.png
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.
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?
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.
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!
Its limiting to dismiss a tool out of hand simply because you haven't encountered a situation where that tool would be useful.
Plenty of web sites allow the end-user to select colors[1], or automatically derive colors from assets provided by the end-user. For those that care about accessibility, they typically calculate contrasting colors to prevent the user from creating a non-accessible experience. A built-in CSS tool like this will, hopefully, encourage more sites to provide a basic amount of accessibility while in no way hindering those who want to build an even better experience.
It would be cool if this was more customizable like the npm contrast-color package but the blog post details why they started with white/black with intentions of changing the algorithm later.
[1] Example: https://coolors.co/8fbfe0-7c77b9-1d8a99-0bc9cd-14fff7
Yep. A simple use case I had was letting users create "tags" and choose their own color for the chips (think Github PR tags like "good-first-issue" "bugs" but custom)
I'm surprised parent hasn't come across this usage, I see it everywhere.
> and they did it with the worst possible contrast selection algorithm
They specifically say they are following WCAG 2 algorithms, and that WCAG 3 may correct this issue. They say that they can easily adjust to use the better algorithm in the future when it's standardized.
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.
https://youtu.be/tUJvE4xfTgo?si=vFlegFA_7lzijfSR (warning: video is in Portuguese)
Funny a sister comment gave a color space formula to do just that
https://news.ycombinator.com/item?id=44015990
Video seems fine. I don't speak Portuguese though so can't judge what you said but code looks good!
Appreciate it
Cool! I did a similar thing manually with python and terminal colours https://calbryant.uk/blog/destroying-the-right-server-with-c...
Is there a good alternative for this that is done at build time? Something that works on top of SASS, Tailwind, etc?
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:
https://drafts.csswg.org/css-color-6/#colorcontrast
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.
https://akkartik.name/post/2025-04-04-devlog
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.
I remember doing something similar back in the day using YIQ value - https://medium.com/@gkobilansky/a-color-changing-take-on-the...
Here's one method for this that I have bookmarked: https://miunau.com/posts/dynamic-text-contrast-in-css/
>This browser does not support contrast-color(). Try this demo in a browser that does, like Safari Technology Preview
You don't need the Technology Preview, it's available as a WebKit Feature Flag under the advanced settings of normal Safari. I just enabled it on my phone and was able to view the demos.
not available on desktop safari (version 18.2 (20620.1.16.11.8)) under feature flags.
It’s available in desktop Safari here, I’m using version 18.5 (20621.2.5.11.8).
Safari has had several security fixes since then, so you should update:
18.3: https://support.apple.com/en-us/122074
18.3.1: https://support.apple.com/en-us/122285
18.4: https://support.apple.com/en-us/122379
18.5: https://support.apple.com/en-us/122719
Also, 18.4 was a pretty big update for standards support and other features:
https://webkit.org/blog/16574/webkit-features-in-safari-18-4...
thanks for info. i've had 'auto update apps and security responses', just not full macos. will review.
I'm on version 18.5 (20621.2.5.11.8) and it's there.
And I don't yet see an entry for this on caniuse.com. I'm guessing this is super new.
MDN doesn't even have it yet. Looks like it's WebKit exclusive for a while.
The [draft for addition to the CSS spec](https://drafts.csswg.org/css-color-5/#resolving-contrast) just got added. Kind of wonder why Apple includes this in Safari as color-contrast rather than -webkit-color-contrast until other browsers have at least indicated a position on this draft. All I can find is decisions to defer the specifications (going back to as far as 2020).
Prefixes are no longer used for new features, and any that still exist are old. What happens now is that features are gated behind feature flags for testing until the browser working group settles on the final spec for that feature, at which point any browser-maker is free to implement it in public releases.
https://drafts.csswg.org/css-color-5/#contrast-color
Very new. I think Safari is the only one that ships it and even then it’s still in preview
It works in "Gnome Web", which is mostly a wrapper around WebKit.
> Support for this feature first shipped in March 2021, in Safari Technology Preview 122.
https://webkit.org/blog/11577/release-notes-for-safari-techn...
> Added experimental support for CSS Color 5 color-contrast()
https://trac.webkit.org/changeset/273683/webkit/
Surely the relative colour theory colour wheel is the answer to this problem.
"Color Wheel: The Basic Color Theory for Artists and Designers" https://dessign.net/color-wheel-theory/
Sadly, doesn't work on firefox yet :(
TLDR: "This browser does not support contrast-color(). Try this demo in a browser that does, like Safari Technology Preview."
[dead]
The article is wrong:
- Their work does ensure contrast.
- The white on blue clearly has less contrast, not more. (squinting is a cheap way to test, or, walking backwards from your monitor)
With APCA, backgrounds around L* 60 tend to still allow white foregrounds, which is aesthetically closer to what the eye wants.
A black foreground would have more contrast regardless, even by APCA.
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 more contrast, rather than "ours say you'll have enough contrast to be accessible with a white foreground, even if it also says the contrast would be higher with a black foreground".
(source: in 2020 built color system around the same science, enabling latest iterations of Material theming)
> The white on blue clearly has less contrast, not more.
Is your screen really badly miscalibrated, or do you have some unusual vision condition? That’s all I can think of. I agree with the article, the white is very clearly higher contrast.
> A black foreground would have more contrast regardless, even by APCA.
OK, now I’m just baffled. The article shows the lightness contrasts for white and black on that particular blue: black gets Lᶜ 38.7, white gets Lᶜ −70.9. White foreground has more contrast, according to APCA.
I really am baffled by what you’re saying, because it all sounds coherent… except it’s all back to front.
The only explanation I can think of is that GP is, somewhat tautologically, defining contrast as "the value returned by WCAG 2's formula for computing contrast" (and, probably, assuming that WCAG 2's "science" has more basis in reality than it actually does).
I can't speak to Material You, but I've seen this sort of thinking at companies that are more concerned with legal compliance with the strict wording of WCAG 2, rather than on-the-ground user experience. People can even learn to ignore their lying eyes and fairly accurately guess what the WCAG 2 "contrast" metric for a given pair of colors will be, independently of how easy or hard the colors are to distinguish from one another.
Hopefully WCAG 3 will incorporate better color guidance from places like APCA, and at the very least these companies will stop producing unreadable black-foreground buttons and badges all the time.
Voters, I'd be very happy for feedback, I'm quite surprised it is -3.
EDIT:
I get it, it is easily read as "the entire article is wrong" instead of "the article is wrong on these points"
You're free to elaborate on your concerns. We could raise this to a conversation, I think that'll feel better for both of us than me taking that remark about me personally.
For example, I agree that the primary container color shouldn't have been L* 90 and used for buttons, and they shouldnt have severely limited chroma. In fact, I left over it and the dysfunction between VPs wondering why we didn't have it day 1, approving fixes repeatedly, and Android dysfunction that kept the conversation at "What? Didn't hear nothing from nobody in engineering! Anyways, lock screen clocks!"
I didn't vote, but "your article is wrong" take ignores literally the entire article, and the rather detailed explanation on why "bigger contrast by pure numbers is more contrast" does not work.
> in 2020 built color system around the same science, enabling latest iterations of Material theming
No wonder everything Google builds, including Material, always has issues with contrast.