0

We have some discussion going on between myself (design) and lead engineer. With this key question:

Does the background of a hover state have to pass color contrast?

Our current system has our dropdown menu items with a hover state that is a light gray.

For example: menu dropdown

The text on the gray still passes contrast no problem (10:1). But the engineer is saying that according to wcag 2.1 success criteria for 1.4.11 Non-text Contrast that the background needs to pass color contrast against it's background AND the text needs to pass contrast against the background behind it.

That would mean the only way a menu item is successful on hover would be to invert is, such as the MacOS does:

menu dropdown inverted

HOWEVER, I would also like to point out that the success criteria for 1.4.11: Non-Text Contrast does say for Buttons that "does not need a contrasting visual indicator to show that it is a button" as well that it is not required that "mouse hover indicators contrast with the default state".

Both examples do change the cursor to the pointer.

So who is correct? Does the light gray hover state pass accessibility? Or only the inverted example shown here?

Improve this question
2
  • "...background needs to pass color contrast against it's background..." What is the source for that requirement?
    – bloodyKnuckles
    Commented Dec 14, 2022 at 16:46
  • One statement here may need to be revised: “the background needs to pass color contrast against its background AND the text needs to pass contrast against the background behind it. That would mean the only way a menu item is successful on hover would be to invert it”. If the text is black and the general background is white, the intermediate background can be any gray from #757575 to #959595. Then the text will have a contrast greater than 4.5:1 with the intermediate background, and the intermediate background will have a contrast greater than 3:1 with the general background.
    – Jonathan Pool
    Commented Dec 15, 2022 at 22:06

2 Answers 2

Reset to default
3

You should be aiming for a 3:1 contrast ratio on 'graphical elements'.

Part 1.4.11 of the WCAG 2.1 guidelines states:

Also, any visual information necessary to indicate state, such as whether a component is selected or focused must also ensure that the information used to identify the control in that state has a minimum 3:1 contrast ratio.

If you are aiming for AA accessibility then you need to comply with this.

The long version of this is that ANY form of information you provide to your users should be available to ALL users regardless of their accessibility requirements. The feedback supplied by the hover/focused state is information - It helps users to understand what they're about to access or do.

It should also be noted that this isn't just about vision-impaired users - A higher contrast ratio for a hover/focused state also helps those with cognitive impairments and those with situational problems (such as people in a hurry).

I wrote an article about recognising accessibility issues if you're interested.

Improve this answer
3
  • If that is true, then please help me understand why the wcag criteria itself conflicts with what you are saying. According to the success criteria for 1.4.11 on the w3 web site, it says "A button which has a distinguishing indicator such as position, text style, or context does not need a contrasting visual indicator to show that it is a button, although some users are likely to identify a button with an outline that meets contrast requirements more easily." Emphasis on does not. While you say it does. w3.org/WAI/WCAG21/Understanding/non-text-contrast.html
    – Aaron Merritt
    Commented Dec 15, 2022 at 17:15
  • Granted, that's the point of the debate I am having with the developer. We do have a button style that has a background only on hover (similar to the chrome browser hover in the toolbar), but that is button. Is a menu item a button or something else such as would require the background change from the surrounding elements to be 3:1?
    – Aaron Merritt
    Commented Dec 15, 2022 at 17:18
  • 1.4.11 is simply saying that you don't have to have a coloured block for a button element to be classed as a button. An Example might be the "Edit tags" at the bottom of your question - It does the job of a button but doesn't have a contrasting background. 1.4.11 just says that this is OK.
    – Roux Martin
    Commented Dec 17, 2022 at 10:53
2

1.4.11 Non-text Contrast says that "states" of interactive elements must have a 3:1 contrast with adjacent colors. In the definition of states it says "hover" is an example.

While the "understanding" section of 1.4.11 (which is non-normative but still helpful) does say that mouse hover indicators do not need to contrast with the default state, it qualifies that by saying when the colors "do not appear next to each other". That is, if you have a button with one color and a hover state with another color, the hovered and non-hovered colors don't have to contrast with each other because you never see them at the same time.

But in your example, you do see both states at the same time because you can see hovered and non-hovered elements at the same time.

Is the hover color only available by mouse hovering? Can I see the hover color by tabbing to the dropdown then arrowing down through the list (keyboard focus)? If you can see the hover color using the keyboard (which I guess is not really "hover"), then you must have sufficient contrast between the hovered and non-hovered states.

If you can only see the hover color when using a mouse, then this might not be as severe a problem because the hover color also has a mouse ptr. That is, the hover color isn't the only indicator that I'm over an element. My mouse ptr also shows where I'm hovering (although that's more of a 1.4.1 Use of Color issue). So if the hover color is only available when using the mouse, technically it doesn't fail 1.4.11 because the qualifier for 1.4.11 says "Visual information required to identify states". In this case the hover color is not required to identify the state because you also have the mouse ptr to identify the state. It's a bit nuanced but allows you to pass, but again, only if the hover color is seen when only using the mouse.

For keyboard users, they need an indicator as to which item they're on when you arrow down through the list. As mentioned above, if the hover color is used for keyboard navigation, then it does require sufficient contrast because the hover color is required to identify the state.

You could satisfy the requirement if the currently hovered or keyboard focused element used a bold font in addition to your light gray background color. The gray background isn't the only clue that the element has focus/hover. Something like this:

enter image description here

Improve this answer
2
  • Ok, thank you for clarifying. There is a different indicator for focus, which is a dark border that appears on focus. The background changes for both hover and focus, but only the focus has the dark border also. Someone else also pointed out at our company that the way the menus are built, they are technically button, so what wcag says about buttons also relates to menu items.
    – Aaron Merritt
    Commented Dec 16, 2022 at 23:14
  • Yes, a border around the currently focused menu item would also prevent 1.4.11 from failing.
    – slugolicious
    Commented Dec 17, 2022 at 15:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.