Focus Indicators That Meet WCAG 2.2: A Practical Guide

A focus indicator tells keyboard users which control will receive their next action. If that indicator disappears, blends into the background, or sits behind an overlay, even a correctly implemented button becomes difficult to operate. Focus styling is functional interface information, not optional decoration.

Separate the WCAG requirements

WCAG 2.2 has several related criteria, and they should not be collapsed into one rule. Focus Visible, criterion 2.4.7 at level AA, requires a visible keyboard focus indicator. Focus Not Obscured (Minimum), 2.4.11 at AA, addresses focused components hidden by author-created content.

Use the contrast checker to compare candidate ring colors with the actual surfaces they touch. Record results for light and dark themes. This measures a specific color relationship; it does not establish that the indicator has sufficient area, remains visible during scrolling, or passes every focus-related criterion.

Focus Appearance, criterion 2.4.13, is AAA, not AA. It defines measurable area and contrast-change conditions, with exceptions. Designing toward it can improve consistency, but do not tell teams that a two-pixel perimeter is automatically a universal WCAG 2.2 AA requirement.

The WCAG interface guide offers wider audit context. Keep each criterion separate in your checklist so a passing screenshot for one requirement does not silently stand in for keyboard behavior across the entire product.

Understand contrast and area correctly

Under Focus Appearance guidance, the qualifying indicator area is at least as large as a two CSS pixel thick perimeter of the unfocused component, and that area must have at least 3:1 contrast between the same pixels in focused and unfocused states. The wording matters: this is a change-of-state comparison.

A simple external outline can make this easier to evaluate because its pixels replace the surrounding background. An underline can also work, but a thin short underline may lack the required area. A large filled background change may qualify if the changed area has sufficient contrast; a particular outline style is not mandatory.

Non-text Contrast, criterion 1.4.11 at AA, has its own requirements and exceptions for visual information identifying components and states. Author-styled focus indicators need appropriate consideration under that criterion too. Do not assume the Focus Appearance contrast-change calculation is identical to every adjacent-color test.

Avoid claiming that a single color passes everywhere. A blue ring that works against white may disappear against a blue panel. Evaluate component interiors, outer surfaces, gradients, imagery, and selected states. Prefer a solid local backdrop or a carefully tested two-color treatment when the surrounding surface is unpredictable.

Establish a resilient CSS baseline

Begin with a visible focus rule, then use focus-visible to suppress it only when the browser determines that the interaction does not require a focus indication. This keeps a fallback for browsers that do not support the selector and avoids blanket removal of outlines.

:root {
--focus-ring: #174ea6;
}
button:focus,
a:focus,
input:focus,
select:focus,
textarea:focus {
outline: 3px solid var(--focus-ring);
outline-offset: 3px;
}
@supports selector(:focus-visible) {
:is(button, a, input, select, textarea):focus:not(:focus-visible) {
  outline: none;
}
}
@media (forced-colors: active) {
:is(button, a, input, select, textarea):focus {
  outline-color: Highlight;
}
}

This is a baseline for common elements, not a complete selector for every custom control. Include any additional focusable components in your system. The example color needs testing against your actual surfaces, and the outline can still be clipped by an ancestor even when its nominal dimensions are generous.

Use focus-visible as a browser heuristic, not a synonym for keyboard-only. Text fields may retain focus indicators after pointer interaction because typing is expected. Do not add a global pointer handler that removes all outlines; it can override useful browser decisions and create inconsistent interaction states.

The MDN focus-visible reference explains selector behavior and compatibility. Document your chosen baseline alongside component tokens so downstream teams do not replace it with an untested box shadow merely to match a mockup.

Prevent clipping and obscured focus

An indicator can have excellent contrast and still fail users when overflow clips it. Test controls inside carousels, scrollable tables, cards with overflow hidden, and modal bodies. An inset treatment may help in a constrained container, but check that it remains distinguishable from the component's own border and selected state.

At AA, Focus Not Obscured guidance requires that a focused component not be entirely hidden by author-created content. Partial obstruction is different from full obstruction under this minimum criterion, although avoiding both is better for usability and supports stronger requirements.

Sticky headers, bottom action bars, cookie notices, and floating chat controls are frequent causes. Scroll padding on the appropriate scroll container can reserve space for overlays; scroll margin can help particular targets. Neither is a substitute for testing variable-height headers and nested scrolling regions.

When opening or closing a dialog, verify the focused control is in the visible active interface. A ring behind a modal backdrop is not useful. Correct focus management and correct styling are separate responsibilities that must work together throughout the full interaction.

Validate themes and real keyboard journeys

Create a small test page containing links, text inputs, toggles, buttons, tabs, and error states. Test every theme, then walk through actual workflows rather than stopping at isolated components. Press Tab and Shift+Tab, activate controls, and inspect focus after content appears or disappears.

Test at increased zoom and in forced-colors mode. Shadows may disappear in forced colors, so a real outline is a valuable fallback. Do not disable system color adjustment broadly to preserve brand styling; preserving user-selected contrast can be more important than matching the default palette.

Use measured evidence in reviews: identify the criterion, surface colors, indicator dimensions, viewport, and interaction steps. Integrate that checklist into the development workflow. A screenshot helps demonstrate appearance, but a short reproducible keyboard route is necessary to reveal clipping, scrolling, and unexpected focus movement.

Key takeaways

• Distinguish AA visibility and obscuration requirements from AAA Focus Appearance.
• Measure both color relationships and the relevant indicator area.
• Keep a visible baseline and use focus-visible without overriding browser heuristics.
• Test clipped containers, sticky overlays, themes, zoom, and forced colors.
• Review complete keyboard workflows, not just component screenshots.