-
Notifications
You must be signed in to change notification settings - Fork 256
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1.4.1 or 1.4.11? #875
Comments
SC1.4.1 is about the perception of colour. SC1.4.11 is about the perception of differnces in colour. The conundrum you point to might be the result of the senses of colour being used in each SC and the all-encompassing nature of the phrase 'visual element'. |
If by "SC1.4.1 is about the perception of colour" you mean that it is not about the differences of colours, but about the meaning of individual colours (in the sense of red = bad, green = good), this would be a sensible distinction between 1.4.1 and 1.4.11, but this does not seem to make the WCAG in the two SCs. Then all cases in which the colors would be arbitrarily interchangeable but not distinguishable would fall under 1.4.11. And all cases in which the colours would not be interchangeable (but might even have sufficient contrasts) fall under 1.4.1. Then both of the above figures would fall under 1.4.11. But for this 1.4.11 would have to be changed: it would not only be about adjacent colors, but about all colors of the page that are related to each other, no matter how far apart they are from each other. In any case, I would welcome such a distinction in the future (WCAG 3.0). But at the moment it is not possible, because the WCAG has grown historically. First there was 1.4.1, which should cover as much as possible, because 1.4.11 did not exist yet. With WCAG 2.1, 1.4.11 was added, which can only cover a little, because it could not take anything away from 1.4.1. This led to this unsatisfactory situation we now have. |
The user-interface component is the select box, which in the example above has a dark border, so that would pass. If select is considered a state, and if it was adjusted by the author, it would need to be contrasting with it's adjacent siblings. |
However, your statement contradicts the example Figure 7, because there the colors also transmit a status, but it says: "the first fails the Use of color criteria due to relying on yellow and white hues". And @patrickhlauke insists that adjacent only directly adjacent means |
Indeed, so in your second example above with the red borders, 1.4.11 wouldn't apply, but Use of color could. |
Okay, got it. But it doesn't seem a good solution to me to test the same problem with borders at 1.4.1 and without borders at 1.4.11. Especially since no contrast requirements are formulated in SC 1.4.1. I would like to see a clear distinction in future versions of WCAG between 1.4.1 and 1.4.11, where 1.4.11 should apply to all contrast distances, even for contrasts of distant elements. Is this planned? |
We have to build up from things we can reliably test, so there will always be a long tail of niche cases where something may not apply as we would like to. Using 'adjacent colors' made sense for text contrast, and it is useful for some scenarios of non-text contrast, but not all. We have a new proposed SC in 2.2 aimed at focus styles which tests the change of contrast, rather than adjacent colors. That is a well known situation (and it's still complex), I don't think we have the basis for applying that to other states at the moment. We need research on more examples of different controls/interactions. |
I don't understand why WCAG 2.2-SC for sufficient contrast of focus should not apply to all contrast differences of distant but content related elements (e.g. contrast difference between pressed and not pressed button, between deactivated and not deactivated element, between active menu item and not active menu item, between selected list entry and the not selected list entries etc.). |
The change of focus is something you have to track around a page. Active / inactive /pressed etc is something that needs to make sense in place; it is a different scenario. That does generally come under non-text contrast at the moment, with the caveat about it needing to be adjacent (as that is how contrast is measured by non-text contrast) or use of color. |
If I have understood it correctly, 1.4.11 applies only to adjacent colours, i.e. colours which directly adjoin each other spatially (#868 (comment)).
In the selection list (see Figure 1) the selected list entry is marked with a blue background colour. This colour adjoins the white of the other list entries. The insufficient contrast between white and blue could thus be weighted as a violation of 1.4.11, wouldn't it?
The second selection list has a red border around the list entries. Now white no longer adjoins blue. So it would be a violation of 1.4.1, wouldn't it? I wonder whether it makes sense to assign the same problem at an element in different designs to different SCs. Or do I only have a fallacy?
The text was updated successfully, but these errors were encountered: