1.4.1 also relevant if hue is the same but brightness is different?

[JAWS-test]

The Understanding of 1.4.1 is exclusively about the fact that people who are color blind cannot distinguish color values (hue). It is not about contrasts when the color is the same. Nevertheless, in the discussions here (e.g. #1775, #875) 1.4.1 is also often applied when the hue is the same and the brightness is different. Color-blind people should probably have no problem with this (even though I am not an expert in this field). Hence my question:

• Is 1.4.1 only about hue differences? If so, do we need a new SC for sufficient contrasts (which currently only exists when it comes to adjacent colors (SC 1.4.3, 1.4.6 and SC 1.4.11) or focus (SC 2.4.11 and 2.4.12))?
• or is 1.4.1 in the end about contrast differences (see 3:1 exception). If yes: then shouldn't this be explicitly mentioned in Understanding (i.e. fixation on color blindness removed). In addition, the contrast requirements in SC 2.4.11 may then be unnecessary (see Does the adjacent color clause of SC 1.4.11 apply when focus changes swap colors but also are adjacent to the background ? #1775 (comment)).

[patrickhlauke]

fixation on color blindness removed

color blindness is not "not being able to perceive hue". a user with different colour perception will differentiate colours (hue+brightness+saturation) if they have a certain contrast delta. that delta can come from particular strong shifts in hue, or from the other two factors.

[alastc]

I would think of it as contrast being a mechanism to distinguish colours that doesn't rely on the hue, and there are other mechanisms as well (e.g. shape). I'm not seeing a reason to update the understanding doc.

[JAWS-test]

color blindness is not "not being able to perceive hue".

@patrickhlauke Someone who is e.g. red-green-blind can therefore distinguish a light red from a dark red (same hue, different brightness) worse than someone who is not red-green-blind? If that's the case, I understand it immediately. Unfortunately, I do not know enough about it. And does this then apply to all colors, e.g. light gray and dark gray or white and light gray?

[JAWS-test]

@alastc I'm afraid I don't understand your answer. Why do we need contrast requirements for the focus (SC 2.4.11), big text (SC 1.4.3) or non-text content (1.4.11) if they are already included in 1.4.1? Apart from the fact that 1.4.1 does not contain the 3:1 exception in the normative SC text.

[alastc]

I don't think the other SCs are covered by 1.4.1, and it would be very confusing to try and do it that way.

Someone who is e.g. red-green-blind can therefore distinguish a light red from a dark red (same hue, different brightness) worse than someone who is not red-green-blind?

My understanding is that in red-green colour-blindness you are missing some/all of the 'red cones', meaning that you don't see the red hue and it is darker than people who have the red cones.

So it isn't just about missing a hue, but the brightness can be affected as well.

But overall, the scope of the 1.4.1 is different from the others, so I don't really get the question.

[JAWS-test]

Four buttons: red and green / white and gray

• A page uses red for disabled buttons and green for operable buttons.
• Another page uses gray for disabled buttons and white for operable buttons.

Red and green would clearly be a color coding of disabled status and a violation of 1.4.1. Someone who is red-green blind may not be able to distinguish the two buttons.
White and gray: Is this a color coding of the disabled status and a violation of 1.4.1 (same hue, different brightness)? Someone who is color blind can probably distinguish the two buttons as well as someone who is not...?

With 1.4.1, it does not matter if colors are adjacent or not: if contrast is below 3:1, it is a violation.

The SC on contrast (1.4.3, 1.4.11) are always about adjacent colors, so the same color combinations (e.g. white and gray) can be a violation of contrast and 1.4.1 (if adjacent) or only a violation of 1.4.1 (if not adjacent) - see #875.
The new focus contrasts are about adjacent and non-adjacent colors.
Thus, either there is a lot of overlap (I can thus consider a focus with poor contrasts to be a violation of 1.4.1, 1.4.11, and 2.4.11) or 1.4.1 actually deals only with color differences (hue) and not contrast differences.

[patrickhlauke]

in short: yes there already currently is some overlap with 2.0/2.1 SCs. yes, there will be more overlaps under certain conditions in 2.2 as well. short of ditching existing SCs and starting from scratch with a view to never have an overlap...we'll have to navigate those potential duplications.

[JAWS-test]

@patrickhlauke I have no problem with an overlap. I just find it problematic that probably everyone considers 1.4.1 not applicable when there are adjacent colors and only apply 1.4.1 when the colors are not adjacent (see your comment at #1775 (comment)). But this is inconsistent. And that's why I suspect that 1.4.1 was not originally intended to measure contrast differences (3:1), but only 1.4.3 and 1.4.6 were intended for that. 1.4.1 is probably originally only meant to prohibit transmitting information about certain color values (like red = bad, green = good) - regardless of contrast.

In F81 color is still equated with hue. If color = hue, different contrasts with the same hue value would not be a violation of 1.4.1.

[JAWS-test]

So again the question:

• above I have 2 buttons without borders. The white one is operable, the gray one is disabled. Is this not a violation of WCAG, or of 1.4.11 (because the buttons seem to touch, although this is not really obvious, since there is no border), or of 1.4.1, or of 1.4.11 and 1.4.1?
• Below I have 2 buttons with the same colors, but with borders. Since they don't touch, it can't be a violation of 1.4.11. So that leaves only 1.4.1 or it is not a violation of WCAG??? Unless: the color does not convey the disabled status, but the focus status - then it is suddenly a violation of 2.4.11.

[mraccess77]

A change in lightness is not a change in color in my opinion. Changes in lightness can be used as an supplement to use of colors if the > 3:1 but that doesn't that a change of lightness is a change of colors - it means it's not!

[patrickhlauke]

this comes down to the vague definition of "color".

is it a "technical" definition, like "the CSS value" e.g. if it's in HSL model, then a change of any value - including saturation or lightness - would count as a "change of colour".

or is it the "popular"/"subjective" view of what "color" means? because then, paradoxically, you have situations where absolutely even just changing lightness can count as a different colour even to non-technical people ... e.g. pink versus red - there's only a difference in lightness/saturation, but ask any "regular" person if they're "the same color" and they'll say no, most likely. fun...

and even just with the "popular" view of color - perhaps only a pedant would argue that "no, changing from light green to dark green is not a change of color, as they're both green", at least for noticeably different lightness (and saturation).

or heck, the extreme cases... white and black are, technically, the same color (or they can be ANY color, to be more precise), just with saturation to zero (in the case of white, for black it doesn't matter) and lightness cranked up to extremes either way. would a change from red to black be "no, not a change in color, as black is the same hue, just set to lightness zero"?