-
Notifications
You must be signed in to change notification settings - Fork 55
SC 1.4.11 contrast on hover included or not #913
Comments
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 |
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).
… |
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:
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:
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/ |
@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 :
|
SC 1.4.3 understanding says:
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:
In the understanding as:
Therefore:
This does not answer @goetsu's original point:
However, that is a (potentially) conflicting requirement with:
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. |
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
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 |
@alastc sorry but 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. |
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. |
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 |
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
The text was updated successfully, but these errors were encountered: