WCAG' Non-text contrast requirements, what exactly are the guidelines with hover?

Question

WCAG does a weird job of explaining their non-text contrast requirements with hover states.

Within their "Understanding non-text contrast" documentation, they have this bizarre example:

As shown here, it outlines that the background color of this (odd) hover state for a checkbox passes accessibility when you are comparing the gray to the black, but it does not mention that gray to the white background (upon checking) fails the 3:1 ratio.

The next example provided shows that it fails because of the focus state being too subtle:

So why is the first ok, but the second isn't? Are hover requirements different than focus, even though their doc doesn't differentiate the two? Earlier in their doc, they outline that hover states are required to pass the contrast ratio similarly to their focus state (with adjacent colors):

User Interface Components Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;

and to clarify what a state is:

States do not affect the nature of the component, but represent data associated with the component or user interaction possibilities. Examples include focus, hover, select, press, check, visited/unvisited, and expand/collapse.

From what I'm gathering, the default state must pass accessibility for perceiving of that component (like inputs, buttons, etc). However on hover it has to unless some specific scenario (that has been undefined) is present?

What am I missing here? Resources are necessary to help not only convince me, but my team too.

Answer 1

You are correct that it's a bit confusing. WCAG 1.4.11 is one of the more difficult ones to understand.

The main purpose of 1.4.11 is to be able to "identify" where a user component is and what its (important) state is. (Ignoring the "graphical object" part of that success criterion for the moment.)

I added "important" to the state because some states are more important than others, although the "understanding" section doesn't say that.

If you wanted to "rank" the importance of states for a checkbox, I'd say:

1. The "checked" state of a checkbox is the most important. You must be able to see (and hear) whether a checkbox is checked or not. With a low contrast checked state, you wouldn't know if the checkbox is selected.

2. The "focused" state of a checkbox is a very close second. If a sighted keyboard user can't tell they tabbed to a checkbox, they won't know if pressing space will select the checkbox. Most checkboxes are non-destructive in that checking or unchecking them doesn't do any harm. The "checkedness" of the checkbox usually doesn't come into play until a form is submitted, so checking and unchecking it usually doesn't hurt. So if a user can't see the focus on a checkbox but they think the focus might be on the checkbox, they can always press space and see what happens.

   Of course, if their focus was on a button with an equally low contrast focus, they might end up selecting the button, which could be destructive, such as submitting a form or deleting a row. Just to be clear, I'm not saying that the focus state is not important. It absolutely is, but when it comes to checkboxes, the checked state is slightly more important than the focus state. But for buttons, since it doesn't have a "checked" state (unless we're talking about toggle buttons), the focus state becomes the most important one. But I'll stick to the checkbox example since those were the examples you posted.

3. And lastly, the "hover" state is the least important. Sure, it's important for a sighted mouse user to see the hover state, but it's not critical. If they can't see the hover state, presumably that have a mouse pointer shape that they can see so they still know they are hovering over a checkbox and can click it. They just might not see the fancy visual effect. But that doesn't prevent them from using the checkbox.

So given that precedence, which, granted, is my opinion and is not stated in the "understanding" doc, I think that might help explain the examples.

In the hover example, it's important to know where the box is for the checkbox so you know where to click. Without the hover state, the box is black on a white background so has sufficient contrast.

With the hover state, a gray circle appears. You want to make sure that gray circle doesn't interfere with the box. You don't want it to make the black box "invisible" or unable to detect. When you compare the contrast of the gray circle with the black box, it has a 15.8:1 contrast so is still good. A user will still know where the box is so they can check it.

Can all users see the hover state? No. It has a contrast of 1.3:1 with the white background, which is very low contrast. Should it have a better contrast? Probably, but the hover state is mainly "eye candy" and doesn't add to the functionality of the page. But I agree that 1.4.11 doesn't explain that very well.

If the hover state were darker, causing a contrast below 3:1 with the black box, then it would interfere with the user seeing the box and would fail 1.4.11.

In the second example, it's showing a focus state, which again in my opinion, is more important than the hover state.

The thicker gray border around the box has a contrast of 2.9:1 compared to the white background, so the contrast may not be sufficient for some users to see so they won't know their focus is on the checkbox. As mentioned earlier, the user can try pressing space but that's obviously not a great solution. You want the user to be able to see where the keyboard focus is.

The second example is a little more obvious to see it fails if the thicker focus was a lighter color, such as