[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.

[SebastianZ]

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

I guess it would be enough to have that part be stable, right? And it looks like with the changes you referred to, it gets properly referenced soon.

Anyway, I just wanted to mention this option as it is a possible solution. If it requires the whole WCAG 3.0 spec. to be stable, then it's probably not the best choice to wait for it.

Sebastian

[Myndex]

Hello everyone @alastc @dbaron @fantasai @SebastianZ @argyleink @svgeesus

I will strive to make this post as brief and succinct as possible (I'll fail, but the thought is there).

My position:

A) "Best available" when discussing human perception is intangible. And in general, this approach leads to ambiguity, so IMO A is a bad idea.

B) I am already on the record for my objection here.

C) In the future, this will "probably" be necessary in conjunction with the use of multiple different display color spaces, as HDR and SDR, and color spaces like Rec2020 have distinctly different needs here, not just for accessibility, but for all sighted users.

D) Of the four listed, I'd say this one, but wait there's more...

E) I was going to suggest a different E option than Sebastian, as I was under the understanding that color-contrast() was being moved to CSS 6, and I'd expect (hope) WCAG 3 would be moving to recommendation by then.

But there is something not mentioned here, that I have mentioned in the past elsewhere, and this is probably a good time to discuss. Let's call it option DE .... ∆E if you like (itty bitty pun intended).

The gist is: Per D, default to a WCAG 3 specification when adopted, but in the interim independently fast-track the candidate method which has been developed in conjunction with the Visual Contrast Subgroup of Silver/WCAG 3 for three years, has been in public beta over a year, and is already being adopted in beta with tools being developed and used, and has received generally positive feedback from early adopters, and positive third party reviews.

Background and Supporting Arguments

WICG Incubator Proposal

A couple months ago, I floated this proposal in the incubator. The purpose as stated in that post relates directly to the conundrum we face today. It was inspired in part by the assertion by some accessibility advocates that "visual contrast is not the important part of accessibility". Without delving into the veracity of this assertion (which I generally disagree with) let's consider the utility of a separate set of guidelines which include non-normative but useful design guidance, and which are intended ultimately to be a superset of (and incorporating) any adopted normative guidance.

Hey Normative

Normative standards tend to gravitate to a minimum acceptable level for the "shall" or "must" and ideally also include a "should" or "preferred". An example is the related ISO standard: "shall" be at least 3:1 but "should" be 10:1, on the other hand, the NIST guide on voting systems states "Luminance contrast must be at least 10:1"¹. These figures are using different math than WCAG 2, so the values are relatively different, nevertheless all including WCAG 2 will progressively over-report as the lightest color gets darker than #ffffff.

A useable metric that is perceptually uniform over the visual range has been a challenge historically, as Dr. Arditi mentions in his 2017 paper "Rethinking ADA Signage"² where he questions the use of contrast as a normative metric at all. Congress removed math-based contrast specifications from the ADA signage requirement, at one point it used Weber though now it's simply "text must contrast against the background" with no actual specified contrast. Around the world there are a few contrast maths being used for signage, ranging from questionable to bizarre. The problem is the vast uncontrollable ambient lighting in the environment and the effects on light adaptation, makes a reasonable standard for architectural signage very challenging.

The problem of visual contrast of text and non-text graphics on self-illuminated monitors is a much smaller problem, with a reasonable solution for the reason that adaptation is substantially affected by the self-illuminated display itself. This opens the door for reasonable estimations and points to some best practices that can become actionable with reasonable normative guidelines.

Still, normative guidelines will usually prefer a set of simple minimums that are testable. But designers and developers, particularly those developing design systems, will want more complete guidance, beyond normative minimums and more in tune with best practices.

The Spectrum of Reading

The thing is, visual contrast for readability is a spectrum, where "how readable does it need to be for what it is" is a completely valid question, and in fact an important question. The copyright bug on the side of an image does not need the same size and contrast as a column of main content body text. And the copyright bug SHOULD be at a much lower contrast to be unobtrusive.

A well designed visual hierarchy requires contrast modulation, and I include in that all forms of contrast, not just luminance and color, but contrasts of size, contrasts of position, contrasts of shape, etc. But it is challenging to make such a wide swath of metrics normative without also including so many exceptions as to make the normative part less that instructive. Nevertheless, there needs to be actionable guidance, and it is an open discussion as to where the conformance to a normative standard best lay; such a standard will always be a subset of the grand scheme fo design guidance.

Accessible For All

The spectrum of human perception is as wide as the human experience itself. The WHO has reported the median vision worldwide at 20/40, a reality for non-industrialized nations without access to affordable eye care. In industrialized nations, 20/20 is a commonly considered standard vision: but that is not "perfect" vision. Perfect vision is more along the lines of 20/12 to 20/16 (the world record for a human is 20/09, eagles are around 20/04). And over the course of a year or two, someone using glasses may have a shift from 20/20 to 20/30 before getting a new refraction.

The majority of people have less than standard eye sight, and even fewer have anything close to "perfect" eyesight. Youth don't reach peak contrast sensitivity until age 20, and a mere 25 years later, presbyopia sets in and reading glasses are required. Another 15 years after that, and the toll of aging drags visual function ever downward.

Readability is for ALL, and ALL have user needs.

Guidelines for readability-for-all can arguably exist as an advisory superset that includes or references normative guidelines. In fact one could argue that leading as an advisory set paves the way to better and more useful normative guidelines in the future.

Thank you for reading,

Andy

[1] Maureen Stone NISTIR 7537
Guidelines for Using Color in Voting Systems
National Institute of Standards and Technology

[2] Aries Arditi
Rethinking ADA signage standards for low-vision accessibility.
Journal of Vision 2017;17(5):8. doi: https://doi.org/10.1167/17.5.8.

[svgeesus]

Just responding to one question in passing:

I was under the understanding that color-contrast() was being moved to CSS 6,

Yes, it was moved on June 17

and I'd expect (hope) WCAG 3 would be moving to recommendation by then.

I have no idea. I can't estimate the going-to-Candidate-Recommendation date for CSS Color 6 at this early point, and the proposed two-year charter for AG WG does not expect WCAG 3.0 to become a recommendation during the charter period.

[Myndex]

Yes, it was moved on June 17

Ah thank you for the clarification.

[melaniephilipp]

Hi All, I see several references to WCAG3 and the timing of normative guidance regarding text contrast in this and other issues. For your awareness, the current project plan for WCAG3 shows it going to CR in mid-2026. Many think that is an optimistic estimate as it has undergone a substantial reset since the last wide release and since this schedule was conceived.

The current Editor’s Draft of WCAG3 incorporates a maturity level rating system for draft content. It is a 5 level system starting with “Placeholder” (described as: AG has identified we need content but do not yet know what it should look like) and advancing through “Mature” (described as: Content is believed to be ready to become a W3C Recommendation). The text contrast content that includes reference to the APCA has been tagged as a maturity level of “Exploratory” - the second lowest of five maturity levels described as “AG is exploring one or more possible directions for this content” with a likelihood to change of “Very Likely”.

Which direction / formula WCAG3 will ultimately settle on for (text and non-text) contrast is far from settled.

[Myndex]

Hi @melaniephilipp

At the moment, everything is tagged as Exploratory (or placeholder). Nothing has moved beyond that in part as the overall conformance model is still in development.

That said, APCA is also an independent standard. There is nothing that I am aware of that would prevent it from being used in any other context, including CSS, Though Chris might have additional thoughts here.

[svgeesus]

Thanks @melaniephilipp for the helpful comments regarding maturity levels and timescales.

[css-meeting-bot]

The CSS Working Group just discussed default algorithm.

The full IRC log of that discussion

<emilio> Topic: default algorithm
<fantasai> github: https://github.com//issues/7361
<dbaron> s/Topic:/Subtopic:/
<emilio> fantasai: (1) use UA default that can change over time, (2) wcag2 forever, (3) always required
<emilio> (4) mandatory for now, default later
<emilio> (5) changing default, but only without candidates, so either white or black
<emilio> fantasai: so you don't have these more subtle color distinctions
<lea> so it will basically be only contrast-color(over var(--color))?
<TabAtkins> yes
<emilio> ... we can use wcag2 by default now and change it, without more subtle changes
<emilio> chris: I disagree with lots, first that white / black are not much change
<emilio> florian: it won't chose between brand color and something else
<emilio> chris: wcag2 default is problematic. I'd formally object to that
<emilio> s/I/ we already have a formal objection
<dbaron> s/I'd formally object/We already have a formal objection/
<emilio> TabAtkins: to get around that we can leave the algo undefined to UA determination
<lea> if we can also provide the algorithm, we've just resolved #7345
<emilio> florian: It's probably good to not say it's WCAG, which means people wouldn't rely on it for legal reasons
<una> I love the usefulness of `contrast-color(over var(--color))`
<emilio> astearns: so with option five you it's invalid if you provide candidates?
<emilio> fantasai: yes
<lea> q+
<emilio> astearns: if we go for (5) we also go for (4) when we have candidates?
<emilio> fantasai: yes
<astearns> ack lea
<emilio> lea: wanna point out since we are about to resolve in the simplified form, if we can also provide an algo, can we resolve #7345 first that allows us to avoid candidates?
<una> q+

[css-meeting-bot]

The CSS Working Group just discussed default algo, and agreed to the following:

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

The full IRC log of that discussion

<emilio> Subtopic: default algo
<fantasai> github: https://github.com//issues/7361
<chris> q+
<astearns> ack una
<emilio> una: I really like having no algo specified, just the value you want contrast against
<fantasai> emilio: if you fall off the list, do you implicitly end up with white and black and if white passes contrast testing...?
<TabAtkins> TabAtkins: No, you take the one that's more contrasting
<florian> q?
<fantasai> chris: They're not tried in order, just either give me white or black
<florian> q+
<lea> q+
<fantasai> TabAtkins: if you want to specify the order, give a list
<lea> q-
<chris> q-
<lea> emilio: this is why it's not unfortunate that we're maximizing: color: color-mix(contrast-color(over var(--color), var(--color) 20%);
<astearns> ack florian
<emilio> dbaron: open to default in the future right?
<emilio> TabAtkins: yes
<dbaron> (I was responding to a statement of the proposed resolution that wasn't minuted.)
<emilio> florian: so options are either contrast-color(over ...), or contrast-color(over foo <algo>, a, b, c..) right?
<emilio> astearns: objections with going with (4) + (5)
<emilio> Proposed: We have an unspecified default, the best available to the UA, which gets updated, only when there aren't any candidates. If you include any candidates, algorithm is mandatory
<fantasai> contrast algorithm is optional, and defaults to the best available to the UA (which gets updated over time), if no candidate colors are specified
<fantasai> yes
<emilio> RESOLVED: We have an unspecified default, the best available to the UA, which gets updated, only when there aren't any candidates. If you include any candidates, algorithm is mandatory