Wanted to confirm my understanding as SC 1.4.11 applies to hover

[mraccess77]

Based on reading the SC and the associated github comments -- only the parts needed for identification have to meet contrast requirements for the hovered state.

• A unchecked checkbox when hovered has a border < 3:1 to adjacent colors - FAIL
• A checked checkbox when hovered has a border < 3:1 but the checkmark > 3:1 - PASS
• A button with text when hovered has a border < 3:1 to adjacent colors - PASS - borders are not required to identify a button according to this working group

There continues to be misunderstanding in the community around the hovered and focused states and this SC. For example, this SC does not require a focus ring to meet 3:1, etc.

[patrickhlauke]

i would say the "hover" aspect here is a bit of a red herring, and that generally the point is:

• the SC doesn't require that the contrast between any of the colors chosen for individual states need to be 3:1 amongs each other (i.e. it doesn't say something like "when a component is hovered, or focused, or selected, its color must contrast 3:1 against its normal default look" or something). only exception: if there are controls that butt up against each other, with no gap, making the focused or hovered or selected color adjacent to another component's default color - but technically, even a single pixel gap makes them non-adjacent.

• what the SC does say is that if the non-text element (the outline, or border, or extra icon, or whatever) is essential to identify a component itself, or its state, then that must have a 3:1 contrast against the background - and this applies to all possible states of a component.

For example, this SC does not require a focus ring to meet 3:1

the understanding doc does explicitly call this out though "In combination with 2.4.7 Focus Visible, the visual focus indicator for a component must have sufficient contrast against the adjacent background when the component is focused". and, from the normative language of the SC, having a focus ring (if that's the only thing that indicates focus) IS required to "identify [...] state".

what this SC doesn't cover, in my view anyway, is a scenario where focus indication is simply a change of color and luminosity - say all regular controls are blue, but the focused control uses a different color (but otherwise no other visual indication) - as long as focused and non-focused controls aren't adjacent, there's no prescription that says anything about how contrasty the focused/unfocused colors need to be between them, only that taken individually (if they're required to identify that something IS a control) they're contrasty enough against the background of the page. (though it may be argued that this would also violate "color alone", but i do recall some fairly hairsplitting discussion about changes in both hue/saturation/lightness counting or not counting as a "color alone" case, I forget which one was argued in the end).

[JAWS-test]

I think the big difference between hover and focus is that there is an own SC for focus and not for hover. I.e. the WCAG does not require an element to change at all for hover. However, it requires a visual change while maintaining focus.

• If the colors change in hover so that the element is no longer sufficiently visible (e.g. contrast between foreground and background < 3:1 or 4,5:1), it is a violation of 1.4.11 or 1.4.3.
• If the hover effect itself is not sufficiently visible (e.g. the background color changes imperceptibly), this does not violate any SC, because hover effects are not required. Unless you say that's a color coding (1.4.1).
• But if the hover effect is indicated by an icon and the icon does not have enough contrasts, it would be a violation of 1.4.11.

I find the last two points somewhat inconsistent. Either I misunderstand or there is still a need for improvement.

I also find it a pity that SC 2.4.7 does not make any statements about the minimum contrast required for the focus. I.e. if the background colour changes only imperceptibly with focus, the question is again whether this would be a violation of 2.4.7 or 1.4.1. or no violation.

[mraccess77]

@patrickhlauke according to @alastc on the last LVTF call the contrast of the focused state is not covered (to my surprise). That is he said that when in the focused state the control must still be identifiable with 3:1 but that the focused ring itself was not covered by the states clause a the working group had intended states like checked, selected, etc. Alastair correct me if I am wrong here. Alastair is working on a new focus SC that will fill this gap and also fill the gap with the focus state contrasting with the non-focused state.

I understand that SC 1.4.11 does not apply to comparing states like hover and non-hover. But we need to clarify what is and is not covered in regard to hover. Based on the discussion related to focus -- it seems that being able to detect that something is in hover state is not covered per above and only what is covered in hover is that what is required for identification of the control is general is is covered. That is when hovered the border of an unchecked box still must have 3:1 to an adjacent color as that is the identifier. In the case of a checked box -- that is not the case as the checkmark is now the identifier and so only the check mark is required to have a 3:1 contrast to adjacent color.

We really need to get in clear agreement with a table listing scenarios as this is causing mass confusion in the community and it seems even among people on this working group people don't agree on what is and is not required. This SC unfortunately does little of what was intended by the low vision task force.

[jake-abma]

As I remembered Focus was indeed excluded...

About a SC for Focus and not Hover, my best guess is the hover already has a cursor pointer as an alternative, focus not.

[patrickhlauke]

how is focus excluded if the understanding doc has this explicit section?

"In combination with 2.4.7 Focus Visible, the visual focus indicator for a component must have sufficient contrast against the adjacent background when the component is focused".

[patrickhlauke]

it seems that being able to detect that something is in hover state is not covered per above and only what is covered in hover is that what is required for identification of the control is general is is covered

was being able to discern hover ever a concern? i'm not quite following scenarios where it's essential to see when something is hovered (while for focus it's quite clear that you need to be able to note what has focus).

That is when hovered the border of an unchecked box still must have 3:1 to an adjacent color as that is the identifier. In the case of a checked box -- that is not the case as the checkmark is now the identifier and so only the check mark is required to have a 3:1 contrast to adjacent color

I'm also not getting why you're specifically talking about the hovered state here. what you say relates to situations other than hover too - whether hovered or not, a user needs to be able to know that there's a checkbox there on the page. if it's unchecked, they need to be able to perceive the border at least. if it's checked, they can perceive it to be there based on the checkmark if necessary, even without a border/contrasty border. or am i missing something specific to the "hover" aspect here?

[mraccess77]

@patrickhlauke my comment was in a specific situation. For example, an unchecked checkbox has a border that is 3:1 and passes. When you hover over the checkbox the border lightens to 2.8:1. This seems like a failure of this SC -- but only in the hover state. Does that make sense?

Regarding the identification of focus not being covered by 1.4.11 - I'd defer to @alastc to explain his comments to the LVTF. But from reading the understanding document it seems to say it applies under 1.4.1 Use of Color although I believe most people would reject that assertion if it was reported in an assessment as they will claim they aren't using "color" -- in the traditional sense of the way people understand it.

[JAWS-test]

When you hover over the checkbox the border lightens to 2.8:1. This seems like a failure of this SC -- but only in the hover state.

I think the answer to this question is simple: it is clearly a violation of 1.4.11 because the contrast requirements apply to all states. In 1.4.3 the case is even explicitly named: "The minimum contrast success criterion (1.4.3) applies to text in the page, including placeholder text and text that is shown when a pointer is hovering over an object or when an object has keyboard focus". And also in 1.4.11 it is described: "However, the component must not lose contrast with the adjacent colors"

Much more complicated is the question of whether the hover effect must be recognizable. I.e. the checkbox still has sufficient contrasts. But the border of the checkbox gets only a bit darker? If the difference between border in normal state and border in hover state is less than 3:1, this is not a violation of 1.4.11, but either 1.4.1 or no violation at all.
Understanding (1.4.11): "For example, there is not a new requirement that visited links contrast with the default color, or that mouse hover indicators contrast with the default state"
"not a new requirement" - It sounds like there's an old one in another SC. But in which one?
For links, this is clear: they must be identifiable according to 1.4.1. But does this also apply to hover?

However, if the hover state is indicated by an extra focus ring, the requirements of 1.4.11 apply again. This is actually difficult to understand. It should be explained even better in the Understandings. For WCAG 3.0, I would suggest that 1.4.11 not only apply to adjacent colours, but to all colours whose contrasts transmit information.
1.4.1 could then only deal with the information that is actually transmitted via colour and not via contrast, e.g. red = bad, green = good.

How absurd the current distinction between 1.4.1 and 1.4.11 is can be seen at #875 . In addition, the explanations on contrast distances at 1.4.1 are not sufficient, see: #873

[alastc]

There's lots of scenarios/cases to this, I've just been reminding myself of the previous conversations and changes:

• PR Non-text contrast updates #550 with lots of conversation in it.
• Survey: https://www.w3.org/2002/09/wbs/35422/technique-approvals3/results#xq22
• Minutes: https://www.w3.org/2018/12/18-ag-minutes.html#item03

we need to clarify what is and is not covered in regard to hover.

My running assumption has been that the control should maintain contrast during hover (and other) state, i.e. not 'disappear' by going to a lighter color. If the control doesn't have contrast by default then that's also a fail.

I made an overly blanket statement on the call, as Pat outlined above there are some scenarios where 1.4.11 comes into play, but I don't think that's enough. There is a weakness in using 'adjacent' colors for a dynamic change, which is why I think the focus-visible-enhanced SC is useful.

We really need to get in clear agreement with a table listing scenarios as this is causing mass confusion in the community and it seems even among people

Agree, I've been a bit swamped, can anyone help with this?

[JAWS-test]

We really need to get in clear agreement with a table listing scenarios

Before such a table is written, however, agreement would have to be reached on what 1.4.11 covers and how 1.4.11 interacts with other criteria. I am thinking, for example, of questions such as

• should the same problem belong to different criteria depending on whether there is a border between 2 colors or not (1.4.1 or 1.4.11? #875)?
• which contrast at 1.4.1 is sufficient to distinguish colors (Explanation of exception in F81 insufficient #873)?
• what visual changes must be made to ensure that the 3:1 difference in contrast is sufficient and to which elements this requirement applies to comply with 1.4.1 (Does G183 only apply to "links and controls" with additional requirements or in general? #871)?
• it is considered problematic that a poorly visible hover state is only a problem at 1.4.11 if it is displayed with an additional visual element, but not if only the colors change (then it's not a problem at all, Proposal for a new SC for hover (WCAG 3.0) #899)?
• it is considered problematic that a poorly visible focus state is only a problem at 1.4.11 if it is displayed with an additional visual element (e.g. focus ring), but not if only the colors change (then it is a problem at SC 2.4.7, but without any contrast requirements, Does SC 1.4.11 require comparing focused and non-focused states #541)

[alastc]

In terms of the original question in the thread, I think that has been answered in the updated to the understanding doc in #931, so closing this issue.