Visual information that changes on hover or focus must keep the same contrast

What it is

A passing rest state does not mean the hover or focus state still passes. If hover, focus, or press reports “you are here” with a slightly lighter or darker fill, that fill is visual information and it must meet the same contrast bar as the rest state. State contrast asks whether the change between states remains visible, not whether the control can be seen while sitting still.

“A little darker” is the usual shortcut: typical acuity on a good display can feel a 4% lightness shift; low vision or glare reads it as no change.

Why it happens

A state change is a transient. Vision uses local difference, not absolute values: a button moving from #2563EB to #1D4ED8 may be a difference only its author can name. If that is the only “hovered here” cue, what fails is perceivable feedback, not polish.

Keyboard focus is stricter. Pointer users still have the cursor as a second channel; keyboard users get “where am I” almost entirely from the focus graphic. A low-contrast focus ring hides the caret. The ring is often drawn on an already-bright or already-dark branded button, so the ring-versus-fill pair and the ring-versus-outer-background pair must be measured separately — either side dissolving means the state never arrived.

Pressed, selected, and expanded indicators that are only an opacity overlay are composited against a neighbour that is no longer the two swatches on the palette; the state delta is eaten further.

Studying it

Build a state-matrix capture: rest / hover / focus / press / selected, in both light and dark appearance. In each cell, sample the pixels that carry the state, not only the rest fill.

Independent variables: lightness delta from rest, focus-ring width and colour, presence of a shape change (outer stroke, underline, shift). Dependent variables: under blur or contrast compression, whether observers can point to the hovered or focused control.

During a keyboard-only walkthrough, have a second person name the focused control from the screen. Each wrong name is a state-contrast miss, not a focus-order miss.

Where it stops holding

Disabled states are often allowed lower contrast because their job is to look weak, not to say “you are here.” Purely decorative hover motion (a card lifting with no information gain) is out of scope; if the lift is the only affordance, it becomes state information again. Touch has no hover, so this claim does not hold for touch users — keyboard focus still does. Forced high contrast can rewrite custom hover colours, stretching or flattening the delta; that mode needs its own pass.

Applying it

• Accept hover, focus, press, and selected — every visual that changes meaning — against the non-text contrast bar. Do not accept the rest state only.
• Do not implement the delta as “same hue, a little less alpha.” Add a stroke, an underline, a shape or a shift so the difference does not depend on a 4% lightness bump.
• Measure both the ring-versus-fill pair and the ring-versus-outer-background pair. Passing only one still lets the other side dissolve.
• How to check: tab the primary path with a low-contrast or blur filter on. Every control whose focus or hover cannot be named is a fail.

Related

• Same group: J2.10.1 Icons, borders and state indicators must meet a contrast threshold too · J2.10.2 Unchecked checkbox and input borders are the most often-missed low-contrast elements · J2.10.4 Contrast cannot be signed off on mockups; it must be verified on rendered pixels
• Nearby: J2.06 Focus Visibility · J2.15 Dark Mode and High Contrast Compatibility · J3.02 Focus Order and Focus Traps
• Search terms: state contrast · focus indicator contrast · hover affordance