Design QA
Interactive states
Interactive states are the visual forms a control takes as a person uses it: rest, hover, focus, active, selected, disabled and, for links, visited.
A design is finished only when every state is drawn, and a build only when every state is implemented. WCAG requires a visible focus state and 3:1 contrast on whatever shows a state.
At a glance
| The states | Rest, hover, focus, active (pressed), selected or checked, expanded or collapsed, disabled and, for links, visited (the list WCAG uses in 1.4.11) |
| Focus | Visible to keyboard users (2.4.7, Level AA) and not hidden behind sticky headers or banners (2.4.11, Level AA) |
| State contrast | Whatever shows a state needs 3:1 against the colors next to it (1.4.11, Level AA) |
| Hover | No contrast requirement: the pointer already shows where the person is (1.4.11) |
| Disabled | Exempt from contrast requirements while inactive (1.4.11) |
| Color alone | A state cannot be shown by a color change only (1.4.1, Level A) |
| Detected by | OverlayQA Auto Review |
Why it matters
Every control is designed at rest and used in motion. A keyboard user moves through a page with Tab and can only act on a control they can see is focused, which is why WCAG makes a visible focus indicator a Level AA requirement (2.4.7) and, since version 2.2, stops author content such as a sticky header from hiding the focused item entirely (2.4.11).
A state that exists in the stylesheet still has to be perceivable. WCAG 1.4.11 asks that the visual information showing a state, such as selected or focused, contrast at least 3:1 with adjacent colors, and shows a gray focus ring at 2.3:1 on white as a failing example (W3C, Understanding 1.4.11). A state shown only by a change of color, like the current page in a nav, also fails 1.4.1 Use of Color.
Which states does every control need?
- Rest. The default. Its border or fill already needs 3:1 under 1.4.11, so the control reads as a control.
- Hover. Optional for WCAG, expected by people on a mouse. Most designs shift the background or underline the label.
- Focus. Required. Draw an indicator with at least 3:1 against what it sits on. WCAG 2.2's AAA guidance is an area at least the size of a 2 CSS pixel perimeter, with a 3:1 change between focused and unfocused (2.4.13).
- Active (pressed). Feedback that the click landed. Often the hover style plus a darker fill or a slight scale.
- Selected or checked. Tabs, toggles, checkboxes and radio buttons. The mark that shows the state needs 3:1 (1.4.11).
- Disabled. Exempt from contrast rules, and still distinguishable from rest, or people press a button that will not respond.
- Visited. Links only. WCAG does not require visited links to contrast with unvisited ones (1.4.11).
Examples
| Control | The state that goes missing | How it fails |
|---|---|---|
| Primary button | Focus | Tab lands on the button and nothing changes. The keyboard user has lost their place (2.4.7). |
| Checkbox | Focus indicator contrast | A light gray ring on white. WCAG's own failing example measures 2.3:1 against the 3:1 floor (1.4.11). |
| Link in body text | Any indicator but color | Link and body text share a color and the only difference is an underline under 3:1, WCAG's failing example (1.4.11). |
| Navigation item | Selected (current page) | The current page is shown by a color change alone (1.4.1). |
| Form field | Focus not obscured | The field scrolls into view behind a sticky footer, so the focused control is hidden (2.4.11). |
Common mistakes
- Designing the rest state only. The build then invents the rest, or ships none. Specify every state in the design system once and reuse it.
- Removing the outline with nothing in its place.
outline: noneon:focusdeletes the browser's indicator and fails 2.4.7 unless a visible replacement is drawn. - Styling :hover but not :focus-visible. Mouse users get feedback and keyboard users get nothing.
- Showing a state with color alone. A selected tab that only changes text color fails 1.4.1. Add a bar, a weight change or an icon.
- Covering the focused element. Sticky headers, cookie banners and chat widgets that sit over the focused control fail 2.4.11.
Frequently asked questions
Does WCAG require hover states?
No. WCAG 1.4.11 treats hover styling as supplemental, because the pointer itself shows where the person is. Focus is the required state: 2.4.7 asks for a visible indicator at Level AA.
What contrast does a focus indicator need?
When the author styles it, the indicator needs 3:1 against adjacent colors under 1.4.11. The Level AAA criterion 2.4.13 adds a size floor, an area at least that of a 2 CSS pixel perimeter around the control, and a 3:1 change between the focused and unfocused states.
Do disabled buttons have to meet contrast requirements?
No. WCAG 1.4.11 exempts inactive components, so a disabled control can sit below 3:1. It still has to look different from an active one, or people will try to use it.
Can a state be shown by color alone?
No. WCAG 1.4.1 Use of Color, a Level A criterion, says color cannot be the only visual means of conveying information, so a selected tab or the current page needs a second cue such as an underline, a weight change or an icon.
Sources: WCAG 2.2, 2.4.7 Focus Visible, WCAG 2.2, 2.4.11 Focus Not Obscured (Minimum), WCAG 2.2, 2.4.13 Focus Appearance, WCAG 2.2, 1.4.11 Non-text Contrast, WCAG 2.2, 1.4.1 Use of Color.
Last updated October 22, 2026