Changes to 1.4.1 Use of Color understanding

[patrickhlauke]

Various tweaks/additions to the 1.4.1 understanding doc, as this seems to still cause some confusion (mainly due to its overlap with other SCs present and future - see #1775)

• Remove benefit mentioning monochrome displays - this situation may not be helped by the "using a difference in contrast/brightness, not just hue" way of addressing this SC.
• Change the last benefit, as it only applies if something else like extra visible/announced text is added. And the "listen" part implies that this is intended to help AT users, which for this SC is not the case (that's a 1.3.1 / 4.1.2 issue)
• Add two more examples - toggles whose state (on or off) is only distinguished by a color change, and controls whose focused state is only conveyed by a color change.
• Reword first examples for information conveyed by color differences so they don't sound like instructions/descriptions - currently, these examples sound far more like 1.3.3 Sensory Characteristics related instructions
• restructure the examples as a more readable/scannable list
• add an explicit example of links versus static text
• add note about potential overlap with 2.4.11 in WCAG 2.2

Closes #1775

[JAWS-test]

@patrickhlauke

Thank you for your PR. I still have 3 comments

Is it possible to include a reference that color means not only difference in hue, but also in saturation or lightness, so that e.g. using light gray and dark gray or white and light gray is also color coding? See: #1781

However, particularly in the case of state/focus indication, note that if the visual indicator was not previously present, this does not count as a change in color. For instance, if a focused element has a new border, or a new solid background color, that was not there in its unfocused state, this does not count as a change of color alone, since the indicator was not presentation to begin with

I'm not sure that's sufficiently understandable: Every element has a background. What is a new background that wasn't there before? Probably you mean when the background of the element is identical to the background of the page/surrounding area and there is no border arount the element. In this case, however, insufficient contrast of the new background would automatically be a violation of SC 1.4.11 - this could be mentioned here already and not below where you mention it, but only in connection with focus.

Note that when it comes to focus indication, there are additional criteria that apply. For instance, in this case, the additional outline will pass this criterion - as it provides another visual cue to distinguish the focused element - but the outline itself will still need to pass 1.4.11 Non-text Contrast

I find this section a bit misleading because it sounds like the additional requirements only apply to the focus indicator. But they apply to all information transmitted via color. For the focus indicator there are only specific requirements from WCAG 2.2 with SC 2.4.11 and 2.4.12.

[patrickhlauke]

Any news on this @alastc ?

[ghost]

Forgive my ignorance (and please signpost me to another ticket if there is a better place for this), but I am still struggling to wrap my head around how the SC applies to focus indication.

At time of writing, the live wording does not seem to mention focus indication explicitly. As well, focus visible for not seem to talk about it. There is some wording in Non-Text Contrast, though.

These updates talk about checking focus indication, but I am not sure I understand it, still.

• When I focus in something, I'll check that the touching colours pass Non-Text Contrast (including any focus indication), but I won't check the focus and unfocused states against each other, though.
• In the future, I may use Focus Appearance to check the before and after contrast, thickness of the focus, and as on.

But for use of colour, my understanding was that I am looking for one of two things:

1. The use of colour relies on my ability to perceive an exact colour (e.g. green).
2. The use of colour relies on my ability to perceive that two colours are different (but it does not test my perception of knowing that something is some specific colour)

For example, with informative text: green means good and red means bad. No amount of contrast matters here. I need to have access to the same information some other way, such as an up arrow and a down arrow.

But with the case of focus, do users need to visually perceive the exact colour, or do they just need to perceive that the colour is different?

For example, if a link has a border and the border changes colour radically (i.e. the difference in the colours used for the border contrast very strongly), based on the wording in the success criterion, would I not be able to perceive that...

1. the border has visually changed
2. the border is now different to the other borders on the page.

This seems to be the case in this wording:

If content is conveyed through the use of colors that differ not only in their hue, but that also have a significant difference in lightness, then this counts as an additional visual distinction, as long as the difference in relative luminance between the colors leads to a contrast ratio of 3:1 or greater. For example, a light green and a dark red differ both by color (hue) and by lightness, so they would pass if the contrast ratio is at least 3:1.

However, if content relies on the user's ability to accurately perceive or differentiate a particular color an additional visual indicator will be required regardless of the contrast ratio between those colors. For example, knowing whether an outline is green for valid or red for invalid.

However, there is then the following as an example failure ...

the interactive element that currently has focus is only distinguished by changing the color of the element's existing background or border

... which makes me less sure.

[patrickhlauke]

it's not necessarily being able to perceive exact colour. just that colour is used to signify something, identify something, etc.

say you have buttons with gray backgrounds. the focused one becomes subtly greenish/gray to differentiate it. the difference is too subtle to count as a change of luminosity (the difference between the gray and the greenish/gray is less than 3:1). in that case, the focus indication relies purely on the ability to perceive colour/colour differences (not which exact colour is used)

[ghost]

If in that case, the difference was more than 3:1, would you still fail it? For example, the border changes from blue to orange, and otherwise passes the non-text contrast checks.

[patrickhlauke]

if the change is 3:1 or higher, it doesn't count as colour alone, as it also significantly changes in lightness/luminosity. as per the second note in https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html

[patrickhlauke]

@alastc @mbgower any chance this could be looked at?

[patrickhlauke]

ping again...

[giacomo-petri]

Agree with the edit.

Not a problem, but in points 1 and 2, we delineate the beneficiaries of a proper implementation. In points 3 and 4, alongside identifying the beneficiaries, we also clarify that they will reap the benefits if other visual cues are present (although this may not be necessary). Should we stay consistent?

[patrickhlauke]

i think with the first two the only thing you could then say is a platitude/truism a la ", so not relying on color alone will help them". in a sense, the first three bullets all get to the same point and could even be combined.

[mbgower]

Suggested change

	<li>required fields are only identified by changing their border to a red color;</li>
	<li>required fields are only identified by changing their existing border to a red color;</li>

[mbgower]

For the state of toggle buttons, I also think we're on thin ground. Again, it helps to think about these visuals all being carried out in black and white, and gray. I point again to the creation of Non-text Contrast as proof that Use of Color was considered inadequate to fail subtle state changes.

[patrickhlauke]

again, non-text contrast can't compare things that aren't visually adjacent. use of color, on the other hand, can

[patrickhlauke]

the point of this example was the "also styled to appear pressed" and the alternative use of icon, just to make sure it's more than just a change of background colour alone (below 3:1) that distinguishes toggles that are on and toggles that are off. without those, you're relying purely on the user's ability to be able to tell the difference between the two shades, which fails use of color (and can't fail non-text contrast because they're not adjacent, unless the toggles all butt up with each other with no dividing line or anything)

[mbgower]

Thinnest ice of all. The WG introduced Non-text Contrast in 2.1, it can be argued, because a 'background color change' especially from white to something else, passed Focus Visible. Then the working group introduced Focus Appearance in 2.2, because the wording in Non-Text Contrast was not deemed as sufficient to cover several situations. A 10% gray fill replacing a white fill in a text input does not fail Non-text Contrast. Any two visible non-text contrast visualizations of state that both achieved 3:1 against adjacent colors but not against each other likewise do not fail Non-Text Contrast.

[patrickhlauke]

but unarguably you're just relying on color here to convey something. so while non-text contrast can't compare two different states that are not adjacent, use of color can (because if the change is less than 3:1 it counts as only a change in color, which is a use of color)

[mbgower]

but unarguably you're just relying on color here to convey something

Not unarguable, since that's exactly what I'm challenging! I think it is clear that a transition from nothing (blank white page) to any content was not intended to be caught by Use of Color. By that definition, EVERYTHING added to or removed from a page is a failure of use of color, since the text, the symbols, the shadows, etc., is simply a use of color. Color alone is forming the letters (even if they're black). Color alone is forming the shapes. Color alone is forming the fills. Everything ever added to a page would fail this SC.

Clearly, Contrast (Minimum) was intended to specifically assess the contrast between text and its background. And Non-text Contrast was added to assess contrast between any non-text visually present feature and its adjacent color (typically the page background).

In the example, if toggle buttons showed for their pressed state with only a less than 3:1 inner shadow (i.e., no use of the 'tick') that would still pass Use of Color. Not saying it would be good design, but especially in the days before Non-text Contrast (which introduced the idea of 3:1) no one would have argued using a shadow is an example of Use of Color.

I'm not trying to split hairs here. Your final note identifies the exact same problem.

However, particularly in the case of state/focus indication, note that if the visual indicator was not previously present, this does not count as a change in color. For instance, if a focused element has a new border, or a new solid background shape, that was not there in its unfocused state, this does not count as a change of color alone, since the indicator was not present to begin with.

[patrickhlauke]

getting lost between resolved comments, your myriad of tiny changes (could really do with doing them with proper git and pushing up a single commit, rather than piecemeal) etc. thought this comment was still about toggles, but i see it's the next one. and in this case, this was an example where it's not JUST a use of color change, and it's the additional outline that absolves the example from being a FAIL.

[patrickhlauke]

if anything, it's the whole angle of these (existing) examples (which i then added to) ... even the existing ones aren't examples of failures, but examples of "this would fail, were it not for..."

[detlevhfischer]

Rendered view
Wasn't there the idea to have illustrations to give examples of focussing situations where a mere color change is enough (row of buttons where bg color difference on focus is above 3:1) and where it is not, i.e. not alone (underlined link where difference color alone doesn't have enough contrast when also meeting 1.4.3)? These are still missing, it seems.

Or are there some real differences of opinion in the WG as to what 1.4.1 means and whether it also applies to focus states? I thought that was clear and uncontroversial? Have no time right now to delve deep into this...

[patrickhlauke]

As there's been some back and forth in code comments etc, wanted to take a step back to reset the conversation here with my rationale - as it seems some folks are vehemently opposed to making use of color apply to anything relating to state...

See https://codepen.io/patrickhlauke/pen/YzbEdPL/10c3d5ebeb8bc713ebf1637ca3c74ae0 for examples, but in short my thinking is, and always has been:

• if you rely purely on color (meaning the change/difference is below 3:1 contrast, as per the note in the understanding for use of color that talks about contrast https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html#intent) to convey information - which does include "conveying the state of something" - then you fail use of color
• if this state happens to be focus indication, and you do evaluate against AAA, then yes, something may fail both use of color and focus appearance
• can't evaluate against non-text contrast, because the different colours applied to with/without that state are not visually adjacent (can't compare a change, only two pixels in proximity to each other at the same time)

[patrickhlauke]

Wasn't there the idea to have illustrations

probably...i'll be honest, there's so many places where WCAG could do with illustrations, and time is so limited...

but if we can get behind the principle (as outlined in my codepen there #1788 (comment)) then I'd be happy to polish up some better/cleaner illustrations here too.

[patrickhlauke]

x-ref #3717 which I still need to see where the overlaps are with this older PR of mine

[Myndex]

I saw something in the meeting minutes that I believe needs to be addressed, hopefully this is the place to do so.

Regarding lightness, color, and visual function

Click for CIE definitions and links

.
Definitions: The CIE is the authoritative reference for color terminology.

The most recently revised glossary provides two definitions for the word "color" by itself, and a number of compound definitions:

color, <psychophysical>

specification of a colour stimulus in terms of operationally defined values, such as three tristimulus values

And

color, <perceptual>, perceived color

characteristic of visual perception that can be described by attributes of hue, brightness (or lightness) and colourfulness (or saturation or chroma) --- Note 1 to entry: Perceived colour depends on the spectral distribution of the colour stimulus, on the size, shape, structure and surround of the stimulus area, on the state of adaptation of the observer's visual system, and on the observer's experience of the prevailing and similar situations of observation.

But an important definition of color is the specific achromatic color:

achromatic colour,

perceived colour devoid of hue --- Note 1 to entry: The colour names white, grey and black or, for transmitting objects, colourless and neutral are commonly used in relation to achromatic colour.

In other words, the broadest term "color" can have "no colorfulness."

SIDE NOTE: I recognize that the terminology surrounding light and color is confusing and a big part of the problem towards understanding.

---

The broadest use of the term "color" includes a color with "no colorfulness."

Is the broadest definition of color as "lightness, hue, and colorfulness" the same "color" that is mentioned in 1.4.1? There is a reductio ad absurdum here: If 1.4.1 means not only hue and saturation, but also lightness, then nearly all websites fail. Text is most often displayed as only a difference in lightness/darkness, and even black and white line drawings would fail, or greyscale photos.

Therefore this cannot be the meaning of 1.4.1

Instead, let's examine the three aspects of color:

1. Lightness/darkness/brightness (perception of luminance)
2. Uniqueness (perception of hue)
3. Colorfullness (perception of saturation/chroma)

And what is important to us, is how the human vision system processes each. After the three LMS cone types absorb light, a matrix of cells converts the three cone signals to a red/green opponent (a), a yellow/blue opponent (b), and a separate lightness/darkness opponent (L) which holds fine details, and is critical for text.

Lightness (our perception of luminance) is processed separately from hue and chroma. Variations in lightness are fundamental to vision. Individuals with color vision deficiency are frequently more capable at detecting lightness contrasts than standard vision.

In terms of accessibility, it is hue that is the biggest concern, followed by chroma (the amount that a hue is different than neutral grey). Reading 1.4.1, it's hard to see how to apply it to anything other than hue/chroma.

Click for More on Why 1.4.1 is About Hue/Chroma and not Lightness

.

Standard trichromatic human vision, with LMS cone types perceives four unique hues of red, yellow, green, blue, with secondaries purple, magenta, orange, cyan.

Typical dichromatic vision (LS or MS) effectively perceives blue and yellow, some studies indicate a heightened sensation of saturation, but otherwise a significant limitation distinguishing the standard four unique hues. Dichromats tend to use the luminance differences of colors to aid in differentiation.

In the example below, we see that the natural lightness differences of red and green mean the difference is distinguishable to all in this case. But notice that the lack of lightness difference between green and yellow (for the protan) makes green and yellow indistinguishable.

And Lightness/darkness is distinctly different from hue/chroma as far as our visual function is concerned. "Saturation" is chroma divided by lightness, so yes you can say that lightness is an aspect of color per se. But as far as visual function, lightness and hue are very separate.

---

---

Hi @patrickhlauke

• if you rely purely on color (meaning the change/difference is below 3:1 contrast, as per the note in the understanding for use of color that talks about contrast https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html#intent) to convey information - which does include "conveying the state of something" - then you fail use of color

I've been given the notion that what is written in the understanding document is not "normative" — or is it? The understanding document seems to change a lot after the SCs become recommendations.

That said, there is no science to back up the assertion that 3:1 is needed to define a state change. At best, the 3:1 defined in WCAG 2.x is a reference to a 1980s era standard for text on monochrome displays, but otherwise lacking in evidence—Dr. Arditi's 2017 paper discussed the problems with using contrast math as a guideline.

More to the point, sticking the 'ol 3:1 into SCs because it happens to by lying around, does not make it useful nor correct.

What's missing in 1.4.1

What is actually important, and what should be focused on in 1.4.1, is the ability to discriminate between two items of information.

For items that are adjacent or near adjacent, a lightness difference creates a luminance contrast sensation. The actual amount of lightness contrast needed is dependent on the spatial characteristics of the element, which is generally not accounted for in WCAG 2.

But for items that are spaced apart, or completely independent, a lightness change without an adjacent reference, must be substantial to be easily recognized. This is true for all vision types, because by itself, a grey is neutral and not unique.

If 1.4.1 is to be helped, then some discussion of adjacent/near adjacent vs distant or isolated items would be a good step in the right direction.

Focus Indication

The nature of the indicator: spatial, luminance, difference from the surrounding, and near by comparisons to similar but un-focused elements, all together dictate what is needed here. As a multi-axis set of conditions, a specific normative statement is elusive.

• a 1px outline close to a button needs to be nearly maximum luminance contrast to be reliably readable.
• a 4px outline, especially with a 2 px space from a button, works with less than 3:1 contrast.
• But a 4px outline around every button, where the only change is from green to yellow, can be a non starter, and needs evaluation for CVD issues.

Click for additional examples and visual simulations of CVD

.

• For another example, red #ff2200 and dark green #004400 meets the 3:1 criteria, but for someone with protanopia, the difference in invisible even with adjacency as in the below example:

---

• In the following, the same colors but increasing the focus border width 50% to 6px:

The 50% thicker border is helpful for the white buttons, as the border itself registers are 50% thicker. But the dark buttons may still be challenging, because the button is close to the luminance of the border, and so the 2px increase in border thickness is a much smaller percentage of change to the total dark area of the button.

---

---

TL;DR

I came here initially just to say that lightness or luminance contrast does not belong in 1.4.1, which should be referencing hue and chroma. Lightness plays a part here only insofar as it affects saturation or the perceived colorfulness.

Otherwise, lightness (luminance) is processed in our brain separately from hue and chroma, and for accessibility reasons should also be handled separately. The place to handle lightness differences or contrast is in a guideline with a perceptually uniform contrast metric.

References

• The CVD simulator as used above.
• Overview of perceptual contrast and color, with further references.
• Linktree of related resources

[patrickhlauke]

@Myndex while I'll be the first to acknowledge that the proposed changes here don't go far enough, and should really be expanded much more to distinguish the different aspects of vision ... that would go far beyond what we can do in a non-normative document. this PR tries to patch/cover how people have been interpreting "use of color" right now. while the 3:1 contrast ratio is a very blunt and simplified measure, it's what we have. it's the "for this exercise, we assume the cow is spherical" oversimplification.

For items that are adjacent or near adjacent, a lightness difference creates a luminance contrast sensation. The actual amount of lightness contrast needed is dependent on the spatial characteristics of the element, which is generally not accounted for in WCAG 2.

But for items that are spaced apart, or completely independent, a lightness change without an adjacent reference, must be substantial to be easily recognized. This is true for all vision types, because by itself, a grey is neutral and not unique.

As the SC aims to provide a simple pass/fail that authors can evaluate, this sort of correct thinking is too complex. Particularly as relative position of items can change dramatically depending on viewport size, reflow, etc. Nobody's going to be able to evaluate things if they depend on a complex analysis. So yes, as with many other things, this is an oversimplification, for the purpose of allowing auditors to give a quick and hopefully consistent pass/fail.

The place to handle lightness differences or contrast is in a guideline with a perceptually uniform contrast metric.

as we're not adding any new guidelines/criteria, and have to make do with what we currently have, that's not going to happen. I recommend pushing for this in WCAG3 discussions.

[patrickhlauke]

in short...yes, WCAG 2.1 introduced (in the understanding doc, rather than hidden away as it was in a technique) the idea that two colours (defined as both hue and chroma, together) need to have a contrast difference of at least 3:1 to be considered "different" enough. this was always was a brutal simplification, an "assume the cow is spherical" approach.

but now, given that simplification, this PR applies the thinking to common cases where we see things being differentiated visually by different colours (different hue and/or different chroma). and again, the aim here is not perfection in modelling vision (noting also that the elephant in the room here is that authors have no control over a user's settings, badly calibrated monitors, challenging ambient lighting around their monitor/screen, etc), but to give a very simplified line in the sand to be able to make a binary pass/fail judgement.

[Myndex]

Hi @patrickhlauke

And thank you for the comments, and as you know I am aware of these nuances.

The principal reason for my comments relates to statements I read in the minutes to the related meeting, which presented a common misunderstanding of the importance of separating hue/chroma from lightness. It is best practice to recognize their difference as visual functions that are processed separately and independently therein. And also in pertinent aspect, that 1.4.1 is best described as a matter of hue/chroma and the disregarding of luminance or lightness.

This is well supported by nearly a century of vision and color science. And in fact, the claim in 1.4.1 understanding, though unsupported, that one can assert a 3:1 contrast difference (which applies to luminance only) does by definition indicate the separation of hue/chroma vs lightness.

But again, the reality is not well described by such a simple claim, outside of some given context.

"...As the SC aims to provide a simple pass/fail that authors can evaluate, this sort of correct thinking is too complex. Particularly as relative position of items can change dramatically depending on viewport size, reflow, etc..."

If "thinking correctly is too complex" for an SC, then arguably, it should not be an SC. Instead it may be useful in a best practices document.

This is one of several fundamental failings inside WCAG. And if WCAG were nothing but a voluntary guideline, such assertions could be disregarded. Unfortunately, some legislatures are elevating WCAG 2.x into laws or regulations, with legal effect and purpose.

This is not going to end well, especially where AGWG and the resultant WCAG guidelines continue to develop claims or make assertions that are unsupported by the vast corpus of peer-reviewed science.

Ultimately, this is a suggestion that some consideration be made, as to where the continued severance from actual science and factual evidence-based knowledge might be softened a bit. This is to the benefit of the document. Instead of continuing unsupportable claims with terminology such as "shall" or "must", perhaps using non-normative terms, such as "suggested" or "in some cases", might help salvage the various untenable problems inherent throughout WCAG. Problems which I hasten to add, will not stand per the legal contexts that are being promoted.

WCAG is a fertile container wherein pandas might find a plum-tree of possibilities.

Thank you for reading.

[patrickhlauke]

If "thinking correctly is too complex" for an SC, then arguably, it should not be an SC. Instead it may be useful in a best practices document.

This is one of several fundamental failings inside WCAG. And if WCAG were nothing but a voluntary guideline, such assertions could be disregarded. Unfortunately, some legislatures are elevating WCAG 2.x into laws or regulations, with legal effect and purpose.

and again, for 2.x, you've missed the boat on these things by ... a good two decades. so yes, by all means, take these concerns to WCAG 3. for 2.x, we're fairly bound by what has been set up already, and just filling in some of the gaps and bits around the edges.

[Myndex]

Hi @patrickhlauke

..for 2.x, you've missed the boat on these things by ... a good two decades.

Yes, the compelling reason it is now a matter for discussion is the recent mad-dash to convert this, a voluntary guideline, into statute law or regulations with legal consequence.

That was not intended, as was so stated back in 2007.

…so yes, by all means, take these concerns to WCAG 3…

As far as anyone knows, WCAG_3 is as much as ten years away. As such, it is not relevant to the present problem.

…for 2.x, we're fairly bound by what has been set up already…

Yes we have discussed this at length. If WCAG 2.x were not being promoted as a stable standard suitable for, and defensible in, a court of law, then there would be no concern or controversy.

But the fact remains that it has been so promoted.

I know you feel I am constantly missing your point Patrick, just as I recognize that my posts are rarely taken as intended.

But the point I’ve wanted to impress herein, is how liability attaches to WCAG the document when it is specifically referenced as the basis for statute law.

My previous posts in this thread were to indicate ways to limit that.

[patrickhlauke]

Yes, the compelling reason it is now a matter for discussion is the recent mad-dash to convert this, a voluntary guideline, into statute law or regulations with legal consequence.

And again, this has already been the case for aeons in many parts of the world, not something new...

[alastc]

From the meeting: Pat to review and check that the pass/fail aspect is clear.