Skip to content
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

Closed
JAWS-test opened this issue Aug 27, 2019 · 9 comments
Closed

1.4.1 or 1.4.11? #875

JAWS-test opened this issue Aug 27, 2019 · 9 comments
Labels

Comments

@JAWS-test
Copy link

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?
listbox1
listbox2

@electronicwoft
Copy link

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

@JAWS-test
Copy link
Author

JAWS-test commented Sep 15, 2019

SC1.4.1 is about the perception of colour. SC1.4.11 is about the perception of differnces in colour

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.

@alastc
Copy link
Contributor

alastc commented Sep 29, 2019

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.

@JAWS-test
Copy link
Author

JAWS-test commented Sep 30, 2019

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

@alastc
Copy link
Contributor

alastc commented Sep 30, 2019

Indeed, so in your second example above with the red borders, 1.4.11 wouldn't apply, but Use of color could.

@JAWS-test
Copy link
Author

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?

@alastc
Copy link
Contributor

alastc commented Sep 30, 2019

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.

@JAWS-test
Copy link
Author

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

@alastc
Copy link
Contributor

alastc commented Sep 30, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants