SC 1.4.11 contrast on hover included or not

[goetsu]

Hi,

current text inside understanding state :
"Regardless of the whether or not there is a visible indication of the hit area for the button, the focus indicator for the component must have sufficient contrast when the component is focused."

I think hover indicator must also have a sufficient contrast otherwise people using mouse only may not see the change of state specially on button element where cursor isn't changing to pointer by default

[goetsu]

Also in case like this one https://www.lvmh.fr/ (click on the search icon in the header) or https://knowbility.org/ where search input has no border and transparent background having a hover effect with suffisant contrast will definitly be helpfull for everyone specially low vision user to understand those are interactive area

[detlevhfischer]

As to mouse operation, while it is desirable to have good hover focus, the fact that the user places the visible cursor over the interactive element is IMHO a sufficient indication in terms of minimal SC requirements (for mouse operation).

…

[mraccess77]

I believe the hover state needs to have sufficient contrast as well. Just because a point is over something doesn't mean it's the item we want to activate. If we have to move the mouse away to then get sufficient contrast that might mean panning the magnified view.

[goetsu]

Also as I already said in some cases (button element for example) cursor isn’t changing. So if user don’t see the change of state because contrast isn’t sufficient he will may consider the element as not interactive

[detlevhfischer]

I would support the requirement, I just think the current SC text and understanding text do not make it unambiguously clear that a hover state is required. The current master understanding text has:

This success criteria does not require that controls have a visual indicator, but that if there is an indicator, it has sufficient contrast.

Regardless of the whether or not there is a visible indication of the hit area for the button, the focus indicator for the component must have sufficient contrast when the component is focused. If only the text (or icon) is visible and there is no visual indication of the hit area, then there is no contrast requirement beyond the text contrast (as per 1.4.3) or icon contrast as per this Success Criteria. Regardless of the whether or not there is a visible indication of the hit area for the button, the focus indicator for the component must have sufficient contrast when the component is focused.

I find this hard to parse, perhaps also because of the echo of "Regardless of whether or not". I would wish some explicit distinction between focus (as in keyboard focus) and hover (as in cursor operation) and a clearer statement what this means for the applicability of 1.4.11.

2.4.7 explicitly calls out keyboard focus. My current reading is that 1.4.11 does not require a change of state for controls when hovered over (including a change of cursor). Such a requirement may be a good thing and some readers may think its is implied, but this is not my reading of (minimal) requirements right now. I am happy to be proven wrong, though.

[goetsu]

I don’t ask to have a mandatory hover state but like focus if there is one it must be contrasted enough specially if it used to let user know boundaries of the component / hit area

[alastc]

That section is currently under discussion (email and conf call later today), I don't think we can ask for both:

• Contrast between the component and its surroundings and
• Contrast between the states within the component.

You end up needing three (or more) directions of contrast, which even at 3:1 it is difficult or impossible depending on your colour schreme.

My current reading of the SC would be that: If you have a hover state involving the boundaries of the control, it should have sufficient contrast with the surrounding colour(s).

[jnurthen]

If hover is included at least one of the reference sites fails. https://www.w3.org/WAI/WCAG21/implementation-report/implementation?implementation_id=178

references https://www.funka.com/
The top menu entries have either a grey hover feature or a yellow hover feature, neither of which meet the 3:1 ratio. Honestly requiring a 3:1 ratio when moving a mouse over a web site is so jarring that designers will never accept it. I suggest ensuring that hover is not covered by this SC.

[goetsu]

@jnurthen even without taking care of contrast of hover state most of current reference sites fails with existing criteria as it is right know see #914

Using designer consideration isn’t an option here I think. Otherwise you must remove even the current criteria on text contrast because Vast majority of them still not respect it.

I think we must either :

• remove all boundaries part of this SC
• move it to a new SC AAA
• keep it here but include focus and hover state

[DavidMacDonald]

SC 1.4.3 understanding says:

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. If any of these are used in a page, the text needs to provide sufficient contrast.

I think that means WCAG requires contrast on hover or focus, even in WCAG 2.0, on Text that is.