Focus Appearance
The keyboard focus indicator must meet a measurable visual bar: at least 2 CSS pixels thick around the perimeter, at least 3:1 contrast against its previous unfocused state, and not obscured. New in WCAG 2.2; the most concrete focus-styling rule the spec has ever published.
What it asks
2.4.7 (Focus Visible) says the indicator must exist. 2.4.13 (Focus Appearance) says exactly what it has to look like. To pass, the focus indicator must:
- Have an area at least as large as a 2 CSS-pixel solid perimeter around the focused control, or a 1px thick line of the same total area.
- Reach 3:1 contrast between the focused and unfocused states of the same pixels.
- Not be obscured by other content (which is also 2.4.11 / 2.4.12 territory).
This is the first time WCAG has put numbers on focus styling, and it has reshaped how design systems handle keyboard styles. Expect every accessibility audit in 2026 to call this out by name.
How to meet it
- Use a solid outline at least 2px thick. Common pattern:
outline: 2px solid currentColor; outline-offset: 2px;. - Pick a focus colour that hits 3:1 against the adjacent colour, not just the page background — buttons sit on hover states, gradients, images.
- For dark mode and light mode, ship two focus colours and switch them via
prefers-color-schemeor token theming. - Avoid relying on a glow or
box-shadowring with low contrast; if you usebox-shadow, give it a hard edge and adequate thickness. - Prefer
:focus-visibleso mouse users don’t see the ring, but make sure it activates on every keyboard focus, including programmatic focus.
:focus-visible {
outline: 2px solid #1d4ed8; /* 3:1 against white and grey hovers */
outline-offset: 2px;
border-radius: inherit;
}
Common failures
- 1px focus rings (most browser defaults pre-2023 component libraries).
- Brand-blue focus rings on a brand-blue button hover state — colour identical, contrast 1:1.
- Focus styled only with a soft
box-shadowthat has no defined edge and disappears against patterned backgrounds. - Custom inputs where the focus state changes only the border colour but not the thickness or contrast — too subtle to count.
- “Inset” focus rings on small icon buttons that paint inside the 16×16 hit area and end up invisible behind the icon glyph.
- Components that pass on white backgrounds but fail on the dark-mode variant nobody tested.
Practical contrast checklist
For each interactive component, list every surface state it can sit on (default, hover, pressed, disabled, in a card, in a modal, on a hero image) and verify the focus ring hits 3:1 against each. This is tedious; component libraries that don’t do it ship with hidden failures. Storybook + pa11y or axe-playwright automation pays off here.
Why it matters
2.4.13 closes the most common loophole in 2.4.7: a focus ring that technically exists but is too thin, too low-contrast, or too positionally-clipped to be useful. Low-vision users who depend on the ring to track focus get a measurable, testable guarantee. Designers get a clear rule they can validate before shipping rather than negotiate after.
Even teams formally committing to AA only are widely adopting 2.4.13 as a target because failure modes are easy to spot in audits and easy to weaponise in lawsuits. If you only adopt one AAA SC from WCAG 2.2, this is it.