1.4.1: Use of Color - understanding document needs to be clear if it's about "visual" or more

[patrickhlauke]

https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html currently seems to mix and match different concepts. while the SC normatively talks about "visual means" and notes specifically that it's about color perception, the understanding document starts talking about "text only displays" (which provide NO other cues other than pure text) and Braille displays.

To me, this makes the SC veer far more into "a text-based method of conveying information/distinguishing content must be provided", which I don't believe is the intention of the SC which was dealing purely with color perception.

In that light, this also seems to bump against that controversial escape clause in F73 https://www.w3.org/WAI/WCAG21/Techniques/failures/F73 where it talks about red/pink not just being a difference in color, but lightness ... since in the context of text-only or braille browsers, that excuse ("it's not just a change of color, it's also a change in lightness") wouldn't hold up.

does the understanding document need to be tightened to remove what I would suggest are actually misleading examples/benefits that take this into 1.1.1, 1.3.1 and 4.1.2 territory?

[patrickhlauke]

cross-reference this discussion on WebAIM https://webaim.org/discussion/mail_message?id=41883

[patrickhlauke]

and from that, as I note, if this DOES apply to text-only displays as well, then "even an additional icon or border or different text visual treatment or similar would not be sufficient to pass", arguably, as there's no guarantee a text-only display - assuming this means a terminal or similar - can display those.

[patrickhlauke]

lastly, which is the question from that discussion: that whole aspect of "color is hue" ... if an indication is given by completely inverting foreground/background, is that a valid way to pass 1.4.1?

[JAWS-test]

SC 1.4.1 is only about visual in standard view (e.g. not in HCM, with custom style sheet or anything else).

See also https://github.com/w3c/wcag/issues/1032

[patrickhlauke]

thank you @JAWS-test but that was not the question

[mraccess77]

Use of > 3:1 contrast can be a way to pass SC 1.4.1 when the difference in luminance is used to communicate meaning visually. The same thing goes for anything like a black caret or a black checkmark, blue background selection of a list item, or a black border -- they are all differences in luminance and not color that is communicating something -- a checked state, border, caret, selection.

A quick test is to grayscale something -- can you understand what is being conveyed in grayscale? If the answer is yes and the contrast > 3:1 then you meet the requirement from a visual standpoint. If the answer is no -- such as select the red button -- then you would fail.

[patrickhlauke]

then the understanding document:

• needs to remove/amend references to "text-only" and Braille displays (which won't care about use of > 3:1 contrast either)
• should really mention this directly (rather than segregating the "color = hue" idea to a note in a technique)

[mraccess77]

And I'd add that we are focusing on the visual aspects -- not including a selected state for users of screen readers would fall under SC 1.3.1 or 4.1.2 depending on the situation. I agree the understanding document should be updated. Anything on the webpage otherwise would be color -- even black text on a white background could be argued as use of color to communicate text!

[patrickhlauke]

Anything on the webpage otherwise would be color

exactly! glad to hear i'm not the only one that came to that "taking it to the extreme" interpretation

[JAWS-test]

thank you @JAWS-test but that was not the question

Even on a second thorough reading of your point here and the one in #1032 I can't see any difference

[patrickhlauke]

well here you talked about HCM/custom stylesheets. but i see now that #1032 doesn't touch on that. so with that, yes, it is related...but nothing to do with HCM/custom stylesheets related here

[JAWS-test]

@patrickhlauke

I wanted to say that SC 1.4.1 is not just about visual perception (i.e. it does not affect screen reader users, for example), but about visual perception in the unchanged default view of the page. I.e. a user who uses HCM can see. But SC 1.4.1 does not apply to her or him, because she/he has changed the presentation of the page. Because this is currently not named correctly in the Understanding, I have created the PR https://github.com/w3c/wcag/pull/1020 and https://github.com/w3c/wcag/pull/1033 and asked in https://github.com/w3c/wcag/issues/1032 whether the rest in the Understanding can also be adjusted. Only you answered the question - and I don't know if this is enough to create a PR.

[ghost]

My reading of the normative definition is that it requires visual cues that do not rely on colour.

If colour communicates something and it is not programmatically communicated, this is an issue with 4.1.2 Name Role Value (most likely) or potentially 1.3.1 Info and Relationships (less likely, e.g. if headings are only communicated by colour).

This is hit home in the intent with "In this case, providing the information conveyed with color through another visual means ensures users who cannot see color can still perceive the information."

However, I don't then understand the inclusion of "People using text-only" and "People using Braille displays or other tactile interfaces can detect text cues by touch." because the requirement is visual cues and not the information in text.

So I agree that the body of the SC could do with cleaning up.

In addition to that, though, I often see debates about how strict the SC is. As mentioned in this thread, I have seen mentioned people using greyscale as a test or levering the 3:1 for links for other components.

But this seems to be outside the normative description.

However, it this is then confused further by the wording on Relationship with Use of Color and Focus Visible in 1.4.11 implies that 1.4.1 implies only applies to changes in hue and not changes in luminosity). This is supported by the technique G183: Using a contrast ratio of 3:1 with surrounding text but this explicitly only applies to links.

So it seems like:

• the body of the document needs to straighten out to more explicitly focus on visual cues and not that information necessarily be communicated in text or be done in a way that is compatible with assistive technology.
• the requirements about hue, luminosity, and contrast need to be ironed out -- ideally in the normative language, such as exceptions which are present in other SC.

FWIW, I do not use greyscale as a check. That just seems like a glorified contrast check.

If something is only communicated by colour, I will fail it. This usually involves changing something about the shape.

For example, when colour is used to communicate the difference between one thing and another, adjusting the font-weight, text-decoration, or shape size, I reserve 1.4.11 for focus indication, boundaries, and so on.

I appreciate that others might disagree with this. But in that case, it seems like the SC wording needs tightening. For example:

A quick test is to grayscale something -- can you understand what is being conveyed in grayscale? If the answer is yes and the contrast > 3:1 then you meet the requirement from a visual standpoint. If the answer is no -- such as select the red button -- then you would fail.

I would agree if the wording was similar to sensory characteristics. For example...

Instructions, call-to-actions, and textual information must not rely solely on the precise colour vision. This success criterion is about recognising specific colours, such as "Press the green button", being the only way to understand information, differentiate content, and complete actions. Where colour is used more generally to communicate user interface components and states, see 1.4.11: Non-text Contrast. With that success criteria, you do not need to be able to perceive specific colours a certain way (e.g. perceiving green the same way as the designer) and so the only requirement is that the colours pass contrast".

[Myndex]

I posted an identical post in the pull request, not sure if it is better posted here, so sorry for the duplication.

I disagree with these changes IN PART.

While I certainly agree with the spirit of some of the changes, there is need of further revision IMO.

On commit 2622d7f:

I agree with the added word sighted: ...ensure that all sighted users...

But I disagree with the removal of "text only displays". These types of displays certainly affect sighted users. The world is a big place, while here in the US we may rarely see text only and limited color displays in direct use, we can't say that is true for the rest of the world.

And we do have a "text-only" here when we enter reader mode that ignores much of the CSS styling including color as in hue.

And if we are going to open this up for a change, we can clarify and modernize further. Here is a suggested alternate paragraph:

  <p>Color is an important asset in the design of Web content, enhancing its aesthetic appeal,
     its usability, and its accessibility. However, some users have difficulty perceiving color. 
     People with Color Vision Deficiency may be unable to recognize different hues, such as an
     inability to tell the difference between red and green. People with partial sight, cognitive and neurological
     impairments, as well as many older users, can have functionally limited color vision. People with these and
     other visual needs may use their own CSS styles that overwrite the author's original colors. Further, people
     using text-only, limited-color, or monochrome displays and browsers will be unable to access
     or understand information that is presented only as a difference in color.
  </p>

Later in this commit is this note, quoted only in part:

    <p>This criterion does not directly address the needs of users with assistive technologies.
        It aims to ensure that sighted users who cannot perceive color can still understand content.
        How information is conveyed to assistive technology users is covered separately ......

This may be true if assistive technologies only means screen-readers. However I consider extensions like "DarkMode" and other user adjustments to be assistive technology as well, and if we consider those then this SC does still apply, and I suggest it does apply to all sighted users. WHich brings us to this sentence:

     ...ensure that sighted users **who cannot perceive color** can still understand...

All sighted users can perceive color with the very rare exception of "Blue Cone Monochromats" who have no red or green cones and are the only ones that are truly "color blind". But they are not only incredibly rare (one in a million) they also suffer a profound impairment as blue cones are very poor in resolution among other things. They need assistive technology regardless.

The remaining individuals with Color Vision Deficiency still perceive color. They have a more limited gamut of color, and difficulty in differentiating between hues. I have a CVD simulator that demonstrates this clearly. But again, this SC does not only apply to CVD, it applies to all sighted users, and is primarily a restriction from coding information strictly with hue, which is bad design practice and I'll get to that in a moment. The statement "...who cannot perceive color" is repeated a couple times. All need to be revised to something like "those who cannot differentiate between some color hues."

Objection RE: Note on Coding Information

I most strongly object to the note of commit 9b74ac0, which implies that luminance contrast is useful for coding. IT IS NOT. Multiple international standards including the FAA/NASA have restrictions on coding using luminance contrast, for good reason.

Let's discuss.

Luminance contrast (light/dark, disregarding hue and saturation) is critical for things like letters, fonts, objects, so that the visual stimuli gets through the thalamus, and in the visual cortex is filtered by V1, sent to V4, and then to the VWFA (Visual Word Form Area) for decoding as whole words and letter pairs. For this to happen efficiently, we need ample luminance contrast, and hue/chroma contrast is not much a part of this.

But that does not mean that luminance contrast is useful for information coding based on contrast alone, and if in combination with hue only to support the hue coding, and the 3:1 reference is unsupported here. And luminance contrast should not be a part of this SC at all, it is not relevant (other than luminance contrast shall not be used for coding information). Luminance contrast can be useful for things like "focus" but not so much for things like "good/bad".

Something this SC does not appear to touch on (perhaps I missed it) is that color hues are also NOT absolute in meaning and are interpreted differently in different cultures. Words and symbols convey meaning. Color hues do not reliably convey meaning, and luminance contrast does not either (with the possible exception of "on/off").

Summary:

• Luminance contrast is important for details of content such as fonts, words, drawings of objects... But luminance contrast itself does not convey the meaning, the meaning is conveyed by the details in the stimuli.

• Color as in hue/chroma/saturation is less important for "details" and lexical processing. Hue/chroma is a third the strength of luminance in terms of contrast and resolution (this is how image data compression like jpeg gets away with throwing out most of the color information in an image).

  • Color hue & sat can be useful for coding information, but a number of limitations exist, some of which affect all users regardless of impairment.
  • Thus color hue can not be the only informational coding.
  • A STOP sign is not just a big red octagon. It is emblazoned with the word STOP. And here again, we have multiple information codings. The sign is reflective red, but it is also an octagon, and it also has a lexical, literal statement of meaning.

• Meaning is found in words and symbols.

  • Luminance contrast serves to makes THOSE words and symbols readable, but does not add meaning. However, consistent contrast of specific items (such as roads on a map) can help make that information more clear and organized.
  • Color hue/chroma can add meaning in some cases, but it can also detract and interfere with understanding if used improperly. For instance, what does Cerulean Blue mean? The answer is unknown without a legend. Color does not have universal meaning on its own.

• There are other kinds of contrast: size, shape, motion — but contrasts are not really relevant for this SC, which is about information coding. Contrast is better covered elsewhere.

SIde Bar on CVD

Keep in mind that color as in hue is already full of luminance contrast. Full green #0F0 is more than three times the luminance of full red #F00. But someone with protanopia won't even see red on one of the new UHD monitors. in eRGB, they see red a bit darker than we do, but most important can not distinguish between red and green. Protan and Deutan are the most common CVD types, and thus colors that vary only in their red to green ratios present a significant problem for them.

Again, luminance contrast does not convey information, but makes lexical information more clear. Examples:

Here is red and green, set to the same luminance (no luminance contrast). It does not matter if you have CVD or not, it is plainly hard to read:

But how do people with CVD see it?

There's an odd fact: the protanopia sees it BETTER because they see red darker, it actually improves their contrast. But it is literally unreadable to the deuteranopia and might as well be invisible.

Now let's boost the luminance contrast to a reasonable 80 (APCA):

This contrast boost did not add any real "information" it just made the words easier to read.

And both protan and deutan see it better as well. Now let's flip it around:

About the same APCA 80 contrast here...

But again the deutan and protan can really glean no "information" because they cannot distinguish red from green. The luminance contrast does not convey information, it just make information clearer. (Sounds like a BASF commercial, LOL).

Andy

[patrickhlauke]

extension like DarkMode, and browser's own Reader Mode, etc, which drop/change the author-created stylings etc may or may not count as "assistive technologies". note that there is an overlap here with SC 1.1.1 and 1.3.1 as well (when it comes to colors/symbols/etc conveying meaning, beyond just being used as visual differentiators).

and again, to be clear: what this PR does is move the loophole that was hidden away in F73 ever since WCAG 2.0, which redefined what "color" is by the backdoor, up one level to the main understanding, and takes it to its conclusion. And it tries to remove the muddled parts of the understanding document that started to cover things that are really part of 1.1.1 and 1.3.1 etc.

[JAWS-test]

The WCAG Working Group should reach agreement on this issue and publish it. I find it quite absurd that SC 1.4.1 has existed for many years with so many ambiguities

[Myndex]

Hi @patrickhlauke

As I said I'm with you in spirit, but if we're opening up this SC for major changes, there are things that need to be addressed...

and again, to be clear: what this PR does is move the loophole that was hidden away in F73 ever since WCAG 2.0, which redefined what "color" is by the backdoor, up one level to the main understanding, and takes it to its conclusion.

Yes, F73 is wrong and so is G183 for that matter, especially the G183 examples. Slapping a "3:1 contrast" as a requirement is not a cure all for visual distinguishability. It may be more than needed, and it may be insufficient, depending on the use case (and I'm not even getting into the math problem).

In other words, color as in hue or saturation does not miraculously become distinguishable just by adding luminance contrast.

To recap the few things I object to and I want to encourage reworking them:

• that text only displays and limited color displays and modes like readermode all are useful in the understanding as they all point to reasons color is not a sole conveyer of information. Should not be deleted, but in fact added to as indicated.

• I really want to encourage changing all phrases "sighted users who cannot perceive color" as all users can perceive color (except ultra rare BCM who also need AT). The difference is an important matter of understanding: CVD see a smaller number of colors, and thus have a harder time distinguishing SOME colors. This seems to be a very large misconception, and should be addressed.

• I disagree with the "note" and it promotes some of the same failings of F73 in that just adding luminance contrast to a color hue is not necessarily enough to convey information, depending on the use case.

Thank you

Andy

[patrickhlauke]

Yes, F73 is wrong and so is G183 for that matter, especially the G183 examples. Slapping a "3:1 contrast" as a requirement is not a cure all for visual distinguishability

and herein lies the rub. I have been told by various AGWG members in the past that no, those techniques are in fact what was intended (albeit as a compromise position so as not to fail the majority of the web out there, particularly when it comes to links).

if we're opening up this SC for major changes

the intent with this SC is to make that AGWG position explicit (and not hidden/squirreled away). it is not currently changing anything, just making explicit what has been agreed in the past.

for the "who cannot perceive color", I assume it intends to mean "who cannot perceive color/hue differences"

text only displays and limited color displays and modes like readermode all are useful in the understanding

but again, with exception of limited color, there is arguably overlap here with 1.1.1 at the very least. this SC does not try to address text only, at least not directly - otherwise, the normative wording of the SC would have something like "described to the user in text" or similar, as found in other SCs. but yes, if authors supplement color use with actual text, then as a side effect, it will benefit text only users. but it does not try to cover text only directly. reader mode, high contrast, things that actually modify the author's styling, are again on the cusp ... there have been arguments around high contrast before for other SCs, and whether or not WCAG tries to directly cover this, and how far the author responsibility goes (and where it overlaps, again, with things like 1.3.1).

anyway, i suggest that the rest of AGWG also engage with the more fundamental points of this SC (and yes, i'll note that it will be good to have some definitive and high-level "ruling" on this, which may not have happened in the past due to this point about hue/lightness vs 'color' being buried in techniques as a backdoor redefinition).

[mraccess77]

We cannot change the existing criteria and at the time the contrast ratio of 3:1 was meant to cover the majority of situations without complicating calculations. I understand that the contrast ratio does take into account some aspects of color deficiency even if not totally accurate. I don't think anyone is suggesting it's a cure all - but we only have 2 choices - require everything to have a non-contrasting visual indicator or pass everything like links that only rely on faint contrast -- we can't rewrite the criteria based on current understanding and corrections of calculating color. I' don't think we will get people to add underlines to all links for text only situations so if we remove the techniques then we can no longer fail links that are virtually indistinguishable with minimal contrast.

[JAWS-test]

In my opinion there are the following open questions:

Should there be an exception for 1.4.1 in case of sufficient contrast, i.e. is color coding allowed if contrast distance is sufficient?

• If yes: Which contrast ratio (3:1)?
• If yes: Do other requirements apply (as currently for links in G183, where another visual means must be visible for hover and focus)?
• If yes: Is this only valid for certain contents (like links) or for all?
• If yes: Does the contrast exception also apply if the color itself conveys information (e.g. red = wrong, green = right)?

Does 1.4.1 only apply to sighted users who use the default view of the page?

• If not: Does it apply to sighted users who adapt the default view to their needs? If yes: Which one? (text only, high contrast mode of the operating system, dark mode of the browser or operating system, user styles, color adjustment of screen magnifiers like ZoomText or SuperNova)
• If not: Does it also apply to non-sighted users who use a screen reader?

My suggestion would be:

• 1.4.1 applies only to sighted users without adjustment of the default display. There is the exception for a minimum contrast of 3:1 for all elements without any further requirements. The contrast exception does not apply if the color itself conveys information (e.g. red = wrong, green = right)
• The fact that colors are not perceptible when adjusting the display (High Contrast Mode, Userstyles, Text only) is evaluated at 1.3.1. However, the WCAG Working Group should clarify which adjustments are relevant at 1.3.1.
• The fact that colors are not perceptible to blind people/screen reader users should be evaluated at 1.3.1.
• Since a 3:1 contrast may be difficult to perceive, a new AA criterion should be introduced for WCAG 2.3 or 3.0 that tightens the requirements for color coding.