search

w3c / wcag

Web Content Accessibility Guidelines
https://w3c.github.io/wcag/guidelines/22/
Other
1.13k stars 256 forks source link

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

Open JAWS-test opened 3 years ago

JAWS-test commented 3 years ago

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. https://github.com/w3c/wcag/issues/1775, https://github.com/w3c/wcag/issues/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:

patrickhlauke commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

button Four buttons: red and green / white and gray

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 https://github.com/w3c/wcag/issues/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 commented 3 years ago

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 commented 3 years ago

@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 https://github.com/w3c/wcag/issues/1775#issuecomment-832110108). 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 commented 3 years ago

button2

So again the question:

mraccess77 commented 3 years ago

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 commented 3 years ago

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

alastc commented 3 years ago

For the grey/white examples, I'm not convinced that WCAG requires you to differentiate a disabled button visually.

For 1.4.1, Color is not used as the only visual means of:

1.4.11 doesn't require buttons have contrasting boundaries.

Patrick has outlined the difficulty of using language for this topic (at least English, perhaps other languages are clearer). So again, 1.4.1 is what it is, I'm not seeing a change to make to the understanding doc.

JAWS-test commented 3 years ago

@alastc My question is not about disabled buttons - those were just an example. My question is whether 1.4.1 also applies when the color (hue) is the same but the brightness is different.

That being said, I think the status of a button (such as disabled, focused, pressed, expanded, etc.) is very much information.

bruce-usab commented 3 years ago

My question is whether 1.4.1 also applies when the color (hue) is the same but the brightness is different.

If you have 4.5:1 contrast between two things, IMHO that is enough for passing 1.4.1. In OP you ask is 1.4.1 in the end about contrast differences? Yes and no, sorry. Yes, high contrast can be enough. But no, because the same hue with significant brightness difference is not typically how 1.4.1 is addressed.

That being said, I think the status of a button (such as disabled, focused, pressed, expanded, etc.) is very much information.

Yes, agreed, a button being disabled (or not) is information. The reason for the exception (in 1.4.3 for inactive ui components) is that there is an inherent contraction between communicating inactive visually with having strong contrast (because of the long-standing convention that inactive ui elements should be grayed out.

mraccess77 commented 3 years ago

@bruce-usab I think the question is NOT is >= 3:1 contrast acceptable instead as a way to communicate things that also rely on color - but instead: If you have < 3:1 contrast for two colors of the same hue like light blue and a medium blue - is that use of color - or just a use of contrast not covered by SC 1.4.1.

electronicwoft commented 2 months ago

From a chromatological perspective, hue and brightness are therefore unrelated, but, from the perspective of the 'data of perception', are inextricably linked.

Note that 'colour' in 1.4.3 is really a misnomer as 'contrast' refers to degrees of brightness as in 'relative brightness' so in this case hue and brightness or lumanosity are one and the same.

Brightness is a phenomenon of perception and cannot really be measured objectively, but it is considered central to visual acuity.

The 3:1 ratio is considered sufficient for people with average visual acuity (what is called 20 20 in the U.S.) to perceive a hue or differences in hue using a 'standard' setup. 4.5:1 is for people with 10 in 20 visual acuity and 7:1 is for people with 5 in 20 visual acuity. Legal blindness in most countries is 2 in 20 which equates to about 10.5:1. these have correlates with the lines on a Snelling chart (20 20 is line 7, for example).

The exception in 1.4.3 is a mistake, but can't be remedied because presumably it would make any website or application that uses either the user agent or authored stylesheet non conforming overnight. It is an inconsistency that should be one day rectified.

One aspect missing about 1.4.1 is that the user agent stylesheet uses CSS background to make inactive elements 'greyed out' which is completely removed using WHCM.

electronicwoft commented 2 months ago

oh, and none of the SC really deal with the use of alpha channel or opacity with regards to its impact on the perceivability of a given UI component.