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

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.

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

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.

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

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

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.

@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

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.

Let me string the SC text and understanding together and try to get a logical outcome:

"the visual information used to indicate states and boundaries of user interface components have a contrast ratio of at least 3:1 against adjacent color(s) except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;"

In the understanding as:

any visual boundary that indicates the component's hit area (the region where a pointer can activate the control) must have sufficient contrast with the adjacent background. Also, the visual effects which indicate state, such as whether a component is selected or focused, must also provide the minimum 3:1 contrast with the background adjacent to the component.

Therefore:

• No visible state change is required by this SC.
• If there is a visible state change, it should maintain contrast with the component's background (desirable to meet the intent of the SC).
• Just because there is something that is on a component boundary, doesn't mean it is the "visual information" to indicate the boundary. The implication is that it has to be the thing that makes it recognizable as a component. (I think the reference to hit-area in the understanding needs updating.)

This does not answer @goetsu's original point:

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

However, that is a (potentially) conflicting requirement with:

I believe the hover state needs to have sufficient contrast as well... If we have to move the mouse away to then get sufficient contrast that might mean panning the magnified view.

At least for 'flat' links/buttons, if the hover state is a noticeable (contrasting) change with it's default state, that makes it very difficult to do whilst also maintaining contrast with the surroundings.

I think seeing a thing is more important than seeing a change in the thing (is that right @allanj-uaag, @WayneEDick?), it does seem to be indicated here.

The states aspect is in the normative text, but I wonder if there's a way we can indicate that if something starts with no boundary, adding a boundary on hover that does not have 3:1 contrast is not an issue.

While we are updating this text we should be sure to be clear regarding our understanding of the following: that for boundaries we only need the inside or outside of the boundary -- not both in order to distinguish it as a boundary. The same would go for the focus indicator. I assume the focus indicator would be the same as well -- contrast with the pixels outside or inside of it but not both. If people interpret it differently then we should discuss. I'd prefer contrast on both sides but I don't think that may be practical given borders, backgrounds, and focus indicators all next to each other.

Just because there is something that is on a component boundary, doesn't mean it is the "visual information" to indicate the boundary. The implication is that it has to be the thing that makes it recognizable as a component. (I think the reference to hit-area in the understanding needs updating.)

have you some example ? I confirm this part isn't clear at all. This will be part of lot of confusion and interpretation I think

At least for 'flat' links/buttons, if the hover state is a noticeable (contrasting) change with it's default state, that makes it very difficult to do whilst also maintaining contrast with the surroundings.

Sorry but I disagree with that it's not more difficult than maintaining contrast with the surroundings when indicator isn't on hover. If you choose to do an indicator using border/background it must be contrasted enough on all cases not only for keyboard users

For an example, imagine you have a graphic of something that is wrapped in a link. If the content is an image (JPG of a person) that would probably come under the 'essential' part of graphical objects. However, it fills the hit-area, so it does come to the boundary, but is not the boundary indicator as such (in the same way that text isn't a boundary indicator).

I disagree with that it's not more difficult than maintaining contrast with the surroundings when indicator isn't on hover.

Take a bootstrap button, the left is default, middle is the hover state.

In order to get 3:1 with both itself and the background, you'd need to use the version on the right, which is almost black, and not within the desirable range for branding colours. (This is a demo of James' point above.)

@alastc sorry but
left button : fail SC 1.4.3 , pass SC 1.4.11 (ratio 4.1:0)
middle button : pass SC 1.4.3, pass 1.4.11 (ratio 5.3:0)
right button : pass SC 1.4.3, pass 1.4.11 (ratio 11.8:0)

So the problem with this example is about SC 1.4.3 not SC 1.4.11

Kinda missing the point. If the middle one was the default, the right one would have to be even darker.

The point being that differentiating hover from the default state with contrast is not feasible if design / branding is a factor.

sorry but I still don't get your point if middle one is default and right is on hover you have nothing to change as both are passing SC 1.4.11

I'm not asking for a contrast ratio between background color of standard state and hover state but to apply the 3:0 ratio between the background of the page and boundaries of the hover state as the SC currently require for focus state.
On your example the boundaries have a ratio > 3 on all cases

Going back to the opening comments, I thought you were asking for the default and hover states to have contrast between each other, but re-reading perhaps I was mistaken.

There are many possible variations and examples in this area, I believe it will be the focus on discussion over the next few days, keep an eye on the list for more.

[Proposed response]: Thank you for the comment. The Working Group discussed this issue and the primary concerns for the hover state are a bit different than the focus state. For the hover state, user has the benefit of additional information when viewing the hover state in that the user is in control of the pointer position so between following the pointer position as the user moves it and the change in the pointer shape there is additional information that is available to clarify the hover state. The focus state is different because there isn't a positional relationship between the keyboard presses and the location of the focus on screen, so the focus contrast is more critical to help users find their place on screen.

For both keyboard focus and hover, it is important for the content to continue to have sufficient contrast, although it will depend on whether that content is text (relates to 1.4.3) or graphical (1.4.11) in nature.

Contrast of the content being hovered or keyboard focused is particularly important for screen magnifier users. When using a magnifier at a high zoom level the focus or hover determine the position of the magnifier viewport, so there users may not view content that isn't focused or hovered.

and the change in the pointer shape there is additional information that is available to clarify the hover state

not always the case specially for button element, label or fake interactive element done with aria and tabindex

This issue was moved to w3c/wcag#400