[css-color-6] `contrast-color()` MVP in Level 5

[LeaVerou]

In the NYC F2F in 2022, we discussed defining an MVP of contrast-color() that would only return black or white depending on what color text is most readable for the background color passed. This would address the most common use case where authors have a dynamic color (often user selected) and need to display text on it. Currently authors need to know a lot about a11y and color theory to calculate this reliably, and more often than not the result is suboptmal. You can see an example in this very page:

However, the only relevant resolution was this one:

RESOLVED: We have an unspecified default, the best available to the UA, which gets updated, only allowed when there aren't any candidates. If you include any candidates, algorithm is mandatory

But this only defines defaults, not a path for UAs to implement an MVP of this while we settle the details of the extended syntax. For this to happen, the simpler syntax needs to sit at an earlier level of CSS Color. UAs are extremely keen to ship an MVP for this and have been since 2022, so it's about time we settle on it, without being distracted by the multitude of issues for the extended color-contrast() syntax. Out of these issues, only these need to be resolved for this MVP, and none of them is really a roadblock:

• Maybe [css-color-6] contrast-color() and gamut mapping #8539 though I’m hard pressed to think of cases where gamut mapping would actually change the result
• Maybe [css-color-6] color-contrast() should take transparency into account #7358 though I’m not sure picking a strategy would change the result here; maybe even ignoring opacity would be fine for this

Apart from those, we'd need to also decide on the syntax, which should be much simpler to do for this than for the extended case, since the point of this is to reduce the number of knobs authors have to understand and tweak and just do the right thing automagically, in line with the TAG principle on balancing simplicity and complxity.

I would propose just contrast-color(<color>) in Level 5 (since it's not CR yet) where:

• Contrast algorithm is UA dependent (for background, this is the result with various existing algorithms, though UAs have also been doing their own explorations when they implemented accent-color). Yes, there is a concern that authors might be unhappy with the text color changing from white to black as UAs refine their algorithms, but remember this would only happen in case it improves the result. From conversations with Chrome folks, it appears they are happy to go this route (and have been taking a similar approach for other high level properties, e.g. text-wrap: pretty), hopefully other implementors share the same sentiment.
• <color> is assumed to be background and the function returns white or black depending on which one produces the highest contrast for text (choosing white if there’s a tie). Yes, we have a resolution that it should be mandatory to specify whether the color argument is foreground or background, but in doesn't really make a difference here, so it would be unfortunate if authors had to add this noise everywhere.
• If people are worried about syntax lock-in, we could even use an entirely different function name. E.g. max-contrast-color(<color>) or just max-contrast(<color>) since for every color, either white or black produce the maximum contrast. Or name it in a way that indicates it returns a foreground/text color.

[svgeesus]

In the NYC F2F in 2022, we discussed defining an MVP of contrast-color() that would only return black or white depending on what color text is most readable for the background color passed. I thought we had a resolution on this, but I can’t find it.

The resolutions are in Minutes New York F2F 2022-08-02 Part II: CSS Color and Minutes New York F2F 2022-08-02 Part III: CSS Color .

I think the one you are thinking of might be

RESOLVED: We have an unspecified default, the best available to the
UA, which gets updated, only allowed when there aren't any
candidates. If you include any candidates, algorithm is
mandatory (Issue #7361: color-contrast() default
algorithm)

although (relevant to your proposal above) we also have

RESOLVED: Whatever keywords for foreground/background are named,
they are are required (Issue #7359)

[LeaVerou]

Thanks @svgeesus, I updated the OP accordingly.

[stubbornella]

I’m the PM for Web UI at Chrome, my team would be implementing color contrast if it were ready. I would like to get to resolution on this issue sooner than later because it is a high priority for us this year. This is my suggestion about how we could move forward. We don’t yet know the optimal algorithm for color contrast, and I believe we need to find a way to make this an iterative process, so we can start experimenting with it as soon as possible.

TL;DR I’m proposing that we specify an MVP contrast-color() function which has a UA controlled algorithm.

We want to support both user needs and author intent in a way that is performant, usable, accessible, readable, and beautiful. An example of where we've done this by initially specifying UA control is text-wrap: balance, where we started with only a couple heuristics, but plan to expand and refine over time.

Looking at this diagram, it is clear that there are a lot of cases where WCAG 2.1 can be improved on, however it may take time to find those opportunities and experiment to determine if they work.

If the author specifies the algorithm now, UAs won’t be able to make improvements and up-level the web. However, if we provide a basic color contrast function now, we can always allow more author control over the algorithm in the future. Going the other way around would require each site to manually upgrade, which would take a long time for users to realize the value.

An iterative, UA-first approach would also remove the burden to get everything right up front and instead move us to a more agile process. For example, we could try improvements behind a flag, effectively allowing us to see how that would affect UX across the web.

Yes, initially this would make the property a bit less predictable for the values in the middle of that chart, but the user benefit of being able to iterate in the UA outweighs author control (just for now). I am excited to see how much better we can make contrast-color() given time and iteration.

I propose that we:

1. Specify an MVP contrast-color() function which has a UA controlled algorithm.
2. Follow up on issues against that algorithm that can be considered independently.
3. Begin UA experimentation on algorithm improvements
4. After we’ve discovered the most important levers in contrast from our experiments, consider exposing them to authors on a case by case basis

[stubbornella]

To be clearer about what I'm proposing vs what @LeaVerou suggested:

I don't think we should specify white/black text or anything else about how the algorithm for contrast should work, except that it should always be better than WCAG 2.1 requires. It seems like the existing resolution may already be good enough to get started on that? (I'm not sure, I could definitely be reading it wrong? Especially the candidates part.)

RESOLVED: We have an unspecified default, the best available to the
UA, which gets updated

Our goal is maximizing readability and that is a nuanced question as I can see from the many open issues on this. We will undoubtedly want to add more to the algorithm over time, and if we go with white/black, I don't see a path to reducing the contrast later, even if it still meets WCAG 2.1. If we leave it up to the UA (for now), we can experiment towards maximum readability and good contrast without an artificial constraint imposed by any particular existing algorithm, other than the floor, provided by WCAG 2.1.

@LeaVerou What syntax that would leave open the possibility of adding additional arguments to this function in the future? Perhaps a basic function that just takes in a color and returns another. Could we later add additional optional parameters to the function when we know more about where author control could be helpful?

I'd like to take all the ideas that have come through so far, and start experimenting with them in the UA, for the moment with the non-color expert author in mind. I realize that could feel like relinquishing a lot of control to the UA, but what I really mean is that I'd like for us to partner in a tight loop to improve the UA algorithm together. I think the v0 we would ship would look a lot like what @LeaVerou proposed. I'm suggesting we wait to put it into a spec until we feel confident that we've done everything we can in the UA to have good outcomes for users needing contrast, even when sites are built by authors who don't understand color.

[LeaVerou]

To summarize for the call, what we need consensus on is:

1. Do we generally agree to ship a very high level contrast-color() function focused around calculating a contrasting text color so we can address the most pressing use case while we figure out the specifics for addressing the more complex use cases?
2. Assuming the resolution to (1) is "Yes", what exactly should be UA-dependent and what should be specified for this MVP?

For (2), the two proposals so far are:

1. Algorithm is UA-dependent, return value is either black or white depending on which one produces the maximum contrast when used as text over the provided color (@LeaVerou, @fantasai)
   The rationale for this is:
   1. Given that existing contrast algorithms have so many issues, returning one of the two extremes makes it more likely to actually get a readable color
   2. Knowing what to expect (even if it's one of two values) makes authors more likely to use it than an "anything goes" function
   3. A pure value like black or white is more versatile: it can be blended with other colors, made lighter, darker, more transparent etc, to be used in other visual elements as well (e.g. borders and other decorations)
2. Everything is UA-dependent, including the return value. The only guarantee is that the value returned will be a color that is guaranteed to be readable on the background provided. (@stubbornella)
   The rationale for this is
   1. It allows maximum UA innovation
   2. For the common use case of text colors, it can return a more aesthetically pleasing result than black or white out of the box
   3. It allows more innovation and experimentation around readability

[css-meeting-bot]

The CSS Working Group just discussed [css-color-6] `contrast-color()` MVP in Level 5, and agreed to the following:

• RESOLVED: pursue this approach in level 5

The full IRC log of that discussion

<emeyer> lea: contrast-color() is supposed to give an actual contrast
<fantasai> -> https://github.com//issues/9166#issuecomment-1688124086
<emeyer> …Because there are so many issues to figure out, in practice what happened was a year floated past and nothing really happened
<emeyer> …How about we ship a simple `contrast-color()` that take one color, the background, and returns either black or white, as fantasai proposed
<emeyer> …This sidesteps a number of things
<emeyer> …I think we need a number of levels to get at a full function
<TabAtkins> +1 to this scope reduction
<emeyer> …If we scope it down that far, we can get something out
<emeyer> …The only point of contention was, how predictable shoudl the return color be?
<chris> I strongly prefer the black-or-white MVP not the anything-goes one
<Rossen_> q?
<fantasai> +1 to lea's position
<emeyer> …Should only black and white be allowed, or can UAs have room to return other values?
<Rossen_> zakim, close queue
<Zakim> ok, Rossen_, the speaker queue is closed
<chris> +1 to lea's proposal
<bramus> present-
<emeyer> Rossen_: We’re over time, so, are there any objections to pursuing this in L5?
<florian> +1 to do it, preference for black/white only
<fantasai> https://github.com//issues/9166#issuecomment-1666863256
<fantasai> Let's do it
<emeyer> …(no)
<emeyer> RESOLVED: pursue this approach in level 5
<chrishtr> so is the resolution to allow not black and white, but prefer them?