1.4.11 seems to include the ACTIVE state of links and buttons.

[DavidMacDonald]

The SC seems to require every state to have sufficient contrast. Technically I would say that includes the ACTIVE state of clicking which is visible for a spit second while clicking.

https://www.w3.org/TR/WCAG21/#dfn-states

Do we need language in the understanding about transient states not being what was intended.

[awkawk]

This was discussed as part of #157 and we addressed the bulk of the issue but this part was missed. I doubt that this comes up too often in reviews, but we should add something in the understanding document to clarify.

It seems like since the SC speaks to "Visual information required to identify user interface components and states" that we would be able to make the case that the visual information for the active state isn't required to identify the state because the user is actively clicking on it.

[mraccess77]

I agree a note would be useful. When we discussed I believe we had agreed it was the case that the active state was excluded for the reason Andrew describes.

[alastc]

Someone asked me if all 16 states(!) of links needed to be contrasting with each other, so this could do with clarification!

[patrickhlauke]

on the "with each other" part: as the SC talks about "adjacent colors", am i right in thinking that the SC itself doesn't require that there be sufficient contrast between different states of the same control, provided they're not adjacent? (example of adjacent colors would be, for instance, a horizontal row of rectangular buttons, with no gap between them, and one of them is "selected" with a darker background color - there the requirement would be that the selected background color, since it's adjacent to non-selected background color, have a sufficiently different color)

in other words: does this SC intend that the state (say, focused) needs to have sufficient contrast (assuming it uses only a color change) with another state (say, non-focused)? my initial reading of the SC normative text would suggest no, if not adjacent.

[mraccess77]

It was my understanding that the states between a selected tab and non-selected tab would be covered here by the contrast requirement if there was no other mechanism to visually tell them apart. However, separate states that aren't necessary to understand the purpose aren't covered like active state. In addition, comparison between states like focus and hover state doesn't add any value so there is no need to have contrast differentiation between the different hover and focus states -- just each state by itself.

I think the question people should ask - if you removed the insufficient contrasting colors do you lose anything required to identify/provide understanding that you can't get another way.

[patrickhlauke]

It was my understanding that the states between a selected tab and non-selected tab would be covered here by the contrast requirement if there was no other mechanism to visually tell them apart

this potentially stretches the meaning of "adjacent colors" though? do they only count as adjacent if they're literally touching, and there's no gap between the tabs? it was more my understanding that the requirement here is for each control, in all its states, be differentiated from the background/its boundaries should have sufficient contrast...and not that the different states should be differentiated enough from each other.

[awkawk]

Please take a look at Pull request #530

[mbgower]

@patrickhlauke

it was more my understanding that the requirement here is for each control, in all its states, be differentiated from the background/its boundaries should have sufficient contrast...and not that the different states should be differentiated enough from each other.

Sufficient contrast is not the only means to distinguish states from each other, but it may enter into it. Please see the note on use of color.

The Use of Color success criteria addresses changing only the color of an object (or text) without otherwise altering the object's form. If a control's indicator of state (e.g., button background) varies only by color this is acceptable if the luminosity contrast ratio between the colors of the states differ by at least 3:1, or if there is another indicator of state. For example, a text link that only differs from adjacent text using color where there is no other visual indication that the text is linked (i.e., the link underline is removed) needs to ensure that the link color meets the 3:1 luminosity contrast ratio relative to the non-linked text color in order to meet the related Success Criteria 1.4.1.

Additionally, my recollection is that 2.4.7 Focus Visible was used as the rationale to require a clear distinction between a focused and unfocused state.

[mraccess77]

I'd be interested in getting an official opinion on comparing focused and non-focused states. While I agree these may be issues for the user -- I think this could be hard to test as there could be inversion of colors, etc. and the area of the change may be larger than just a line -- such as changes in the background. I do see this issue come up a lot and it's a real issue for users -- but I'm not sure what the intention of the group was to cover it.

An example I commonly see is a control with a darkish background and light text and when the control is focused the background becomes darker. It's a subtle change that is hard to detect for people with limited contrast sensitivity.

[awkawk]

@mraccess77 perhaps since we resolved the original question you should open up a new issue and include some examples?

[alastc]

New issue opened in #541, as this was dealt with via a PR I'll close this one.