[css-color] color-contrast() default algorithm

[fantasai]

In #7356 and #7357 we're discussing adding syntax to specify specific contrast algorithm(s) to use. That leaves open the question of what algorithm is used if no contrast algorithm is specified. Options going forward:

• A) Use the UA's “best available” algorithm, which can change over time.
• B) Default to WCAG2.
• C) No defaulting: the algorithm must always be explicitly specified.
• D) Plan to default to whatever WCAG3 requires; in the meantime require it to be explicit.

As noted in multiple issues, WCAG2 has problems. It can return poorly contrasting colors in many cases, particularly in dark mode, and using it as the default entrenches the algorithm. The main benefits of using it are that it's already defined and very widely used, and allows us to return identical results in all UAs over time... at the expense of readability in the cases where it does poorly.

Defining color-contrast() to use the “best available” doesn't guarantee “interop” in the sense of always returning identical colors, but, it maximizes readability for users over time.

(Issue filed following breakout discussions between @svgeesus, @LeaVerou, @argyleink and myself)

[SebastianZ]

I believe we agree that we do not want B) because of the reasons outlined. And it's in most cases probably to much to ask authors to make a proper decision on the algorithm.

For the reason above I'd go with A). Though then we need to ensure that authors know that the algorithm is subject to change over time and that it may provide different results across UAs. In any case, it should still be possible to optionally define an algorithm to make the results match.

Sebastian

[dbaron]

I think A seems likely to be problematic because authors will adjust the colors until they have a result they like... and they may not want that result to change later, or to differ between browsers. (It might change in the direction of either more or less contrast as a result of switching to a different algorithm.)

[svgeesus]

My preferred option is D. Plan to have a good default down the line but meanwhile require the algorithm (and thus, also the target levels) to be explicit. That gives consistency from the start, while improving ease of use and brevity without ambiguity later.

[alastc]

I would suggest D as well.

From my personal experience (accessibility testing websites, including with users with low-vision, but not a colour expert) the current WCAG 2 formula does catch a lot of poor colour combinations. A lot of combinations which possibly should fail (but don't) are not attractive and tend not to be used anyway. The dark-mode aspect is concerning.

The bottom line from a WCAG point of view is that there needs to be some specific user-research done to ensure we have a solid footing for WCAG 3.

In the meantime, I would definitely want to avoid a situation where the results of contrast-contrast change with a browser update, or are different between browsers.

Alastair (Co-chair of AGWG)

[argyleink]

Another vote for D, but i'm also still interested in B

[SebastianZ]

To expand on my previous comment, I slightly prefer A over D, then C, then B.

And I want to throw in option E:
Defer color-contrast() until WCAG3 is stable and then default to it.

Sebastian

[svgeesus]

Defer color-contrast() until WCAG3 is stable and then default to it

A drawback with that approach is the length of time to get all of WCAG 3 stable, when

a) we only need one small part of it
b) that part isn't even normatively referenced at present

For example, the currently proposed draft charter for the Accessibility Guidelines Working Group states that WCAG 3.0 will not move to Recommendation during the two-year charter period.