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 #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 #1020 and #1033 and asked in #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.

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