[css-color-6] color-contrast() should allow specifying multiple contrast algorithms that need to be satisfied

[LeaVerou]

Assuming we can specify the contrast algorithm at all (see #7356), we should be able to specify multiple of them as a safeguard for algorithm bugs, as well as to satisfy legal constraints.

E.g. we know that WCAG 2.1 contrast is severely broken, yet it is legally mandated that websites pass it. Once we have a better contrast algorithm, we may want color-contrast() to find us a color pair that both satisfies WCAG 2.1, as well as the new improved algorithm.

Syntax could just be a space-separated list of contrast algorithms.

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

[svgeesus]

To take one example, in The Science of Color & Design by James O'Leary discusses their hybrid color model HCT which uses the L axis from CIE Lab (Tone) but Hue and Chroma axes from CAM16 (Hue, Colorfulness). Contrast is then the difference in Tone:

The HCT color system makes meeting accessibility standards much easier. Instead of using the unintuitive measure of a contrast ratio, the system converts those same requirements to a simple difference in tone, HCT’s measure of lightness. Contrast is guaranteed simply by picking colors whose tone values are far enough apart—no complex calculations required.

For example, to meet WCAG contrast requirements, smaller elements (less than ¼” or 40 dp) require a tone difference of 50 with their background, larger elements require a tone difference of 40. This principle works consistently for any pair of colors.

Note that the minimum contrasts for small and large text (50 and 40) are different from the thresholds for WCAG 2.1 and for APCA; thresholds are algorithm-specific.

[argyleink]

color-contrast(white vs yellow, blue to wcag3(AA) hct(40) wcag2(AA)) is starting to be a mouthful, but could be mitigated with custom properties and supports queries.

@supports (color: color-contrast(#F00 vs #00F, #0F0 to wcag3(AA))) {
  :root {
    --target-ratio: wcag3(AA);
  }
}

.custom-label {
  background: var(--some-bg);
  color: color-contrast(var(--some-bg) vs w3c/silver#111, #eee to var(--target-ratio, wcag2(AA)));
}

[alastc]

E.g. we know that WCAG 2.1 contrast is severely broken,

I think that is overblown, the article says (several times) "if the ‘APCA Lightness Contrast’ is more accurate...". If it isn't, the conclusions are not applicable.

When I've run usability testing with people with low vision, there has been good correlation between colours they struggled with, and WCAG 2 fails.

I've been following the work (as a non-colour expert) and I think APCA is probably a better formula, and we should continue to work incorporating a better formula into WCAG 3.

I'm just requesting that people in W3C don't use language like "severely broken", when the overall impact of the current guideline is still a net positive.

[svgeesus]

Also from that article:

the range of possible background colours for black text reduces by approximately 47% (for these particular thresholds).

the range of possible background colours for white text increases by approximately 63% (for these particular thresholds).

47% false positives and 63% false negatives with a sample size of 8000 tested color pairs does not fill one with confidence. "Broken" seems applicable.

"if the ‘APCA Lightness Contrast’ is more accurate..."

In the cited article, on a calibrated screen and with my normal color vision (slight age-related macular yellowing) the APCA was more accurate in all cases.

I agree that more testing is needed.

[Myndex]

Hi Lea @LeaVerou

.... as well as to satisfy legal constraints....WCAG 2.1 contrast ... is legally mandated that websites pass it.

Legally mandated is a strong term for the narrow areas where there is actual codification into law.

In the USA, the ADA does not mandate WCAG 2 contrast (indeed, the native ADA signage regulations were gutted of any specific contrast guidance regarding architectural signage some time ago). For government sites and government procurement, the 508 rules do specify WCAG 2 contrast, but with two big exception clauses:

1. Commercially available. If something is needed but no commercially available solution is WCAG 2 compliant, it does not have to comply.
2. Alternate method. An alternate method can be used so long as it provides for equivalent or better accessibility.

As for case law, the 11th circuit vacated Winn-Dixie in February, so that is moot.

Above is federal level. For state level there is mainly New York and California. I don't have Lexus Nexus access at the moment, but from what Ive seen, no cases relating to contrast have gone to trial and won on merits. Most are out of court settlements, and I'm going to guess many of these were relying on Winn-Dixie.

For other nations it's a grab bag, but in nearly all cases the specification of WCAG 2 is limited to governmentally controlled entities or sites. An exception is Finland. In Australia it extends to non-governmental sites, but last I checked it was level A only, so contrast is not included. In Canada, there is some case law, but a number of exclusions.

....we may want color-contrast() to find us a color pair that both satisfies WCAG 2.1, as well as the new improved algorithm.

I'd like to introduce you to Bridge-PCA. It is fully backwards compatible to WCAG 2 but using APCA technology, it fixes the problem of false passes. What is lost is the greater design flexibility of the full APCA guidelines. Bridge-PCA was created specifically to answer the question of "meeting legal obligations by the absolute letter of WCAG 2, regardless of actual veracity".

I do not suggest Bridge PCA as a permanent solution—it is specifically a stop-gap, stepping-stone to address various concerns. It does a much better job calculating for dark mode for instance, and also has enhanced conformance levels. The npm package is:

npm i bridge-pca

And the demo tool is https://www.myndex.com/BPCA/

[Myndex]

.... HCT which uses the L axis from CIE Lab (Tone) ....
Note that the minimum contrasts for small and large text (50 and 40) are different from the thresholds for WCAG 2.1 and for APCA; thresholds are algorithm-specific.

I've been watching James' developments with interest. I'm a little surprised at the use of L* instead of J.

∆L* has an interesting attribute in that is sort of lines up with WCAG 2 — the implication is, that contrast using a plain L* suffers the same issues as WCAG2.

Digging up some of the early comparison tables, here's one with ∆L*:

An L* simple difference, when the lightest color is white, lines up with a little less than 40 = WCAG 3:!, 50 = 4.5:1, and 62 = 7:1 ... and still as colors get darker, contrast is over reported. I've also tried this with multiple offsets, but that still is not polarity sensitive.

But wait, isn't L* perceptually uniform?

L* is based on Munsell value, so it is perceptually based.... on diffuse reflected light using large color patches, when the observer is in the defined ambient/adaptation conditions.

Viewing text on a self-illuminated monitor is a different matter, and a different perception. "Middle contrast" for text and other high spatial frequency stimuli isn't at 18%, it's up between 34 and 42 (ish).

As such, ∆L* without some offsets and massaging is not much different than WCAG 2 as this chart shows:

[Myndex]

I agree that more testing is needed.

Me too. And I realize I need to start publishing sooner rather than later.

[svgeesus]

I've been watching James' developments with interest. I'm a little surprised at the use of L* instead of J.

Yes. Going to all the trouble of taking viewing conditions into account, to calculate the hue and chroma from CIECAM16, while ignoring them to calculate tone (L*), is odd, and not well explained in the article.

[svgeesus]

What is SmrsModWbr? I assume it is a modified Weber, got a reference?