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.
> 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.
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.
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.
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*.
BTW, would this relatively simple way to determine if the color is dark work?
$luminance = 0.299 * $r + 0.587 * $g + 0.114 * $b;
return $luminance < $threshold;
- 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)
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!"
> 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.
--text: lch(from var(--bg) calc((49.44 - l) * infinity) 0 0);
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.
The article says the standard specifies the calculation to use.
"Color Wheel: The Basic Color Theory for Artists and Designers" https://dessign.net/color-wheel-theory/
https://youtu.be/tUJvE4xfTgo?si=vFlegFA_7lzijfSR (warning: video is in Portuguese)
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!
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.
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.
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.
crtasm•4h ago
judah•4h ago
miiiiiike•4h ago
homebrewer•4h ago
> 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/
jeroenhd•13m ago
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).
ctippett•4h ago
mgkimsal•1h ago
ctippett•1h ago
JimDabell•1h ago
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...