Designing Visible Focus Indicators That Pass WCAG 2.4.7 and 2.4.11

Success Criterion 2.4.7 Focus Visible (Level AA, in WCAG since 2.0) is short: any keyboard-operable interface must have a mode of operation where the focused element is visibly indicated. It does not prescribe a style. A 2px outline, a background change, an underline, a box-shadow ring all can pass, as long as something perceivable changes when focus lands on an element.

The failure is almost always one of omission. A reset stylesheet or a component library strips the browser default and nothing takes its place. Tab through the page and the focus point simply vanishes you cannot tell whether you are on the search box, a nav link, or the submit button. That is a direct 2.4.7 failure, and it is the most frequent issue surfaced in any keyboard accessibility pass.

Because 2.4.7 is a WCAG 2.2 Level AA criterion, it is in scope for the European Accessibility Act, whose obligations apply from 28 June 2025 with the WCAG 2.2 A and AA baseline enforced through EN 301 549. It is not optional polish.

The instinct to remove the default outline is understandable the browser ring is often unstyled and appears on mouse clicks too. The fix is not to delete it, but to replace it and scope it correctly. Use :focus-visible so the indicator shows for keyboard and assistive-technology users while staying out of the way on pointer interaction:

• Bad: button:focus { outline: none; } removes the indicator with no replacement. Keyboard users are stranded.
• Acceptable: keep :focus for everyone, or use :focus-visible to target keyboard focus specifically.
• Good: button:focus-visible { outline: 2px solid #1a56db; outline-offset: 2px; } a deliberate, contrast-checked ring.

The outline-offset property is your friend: a few pixels of gap lifts the ring off the component edge so it reads cleanly against tight backgrounds. Prefer outline over box-shadow for the indicator itself, because outlines are not clipped by overflow: hidden and remain visible in Windows High Contrast Mode (forced-colors), where box-shadows are dropped entirely. If you need box-shadow for a rounded look, pair it with a transparent outline as a forced-colors fallback.

One more trap: do not rely on color alone changing between states. A link that only shifts hue on focus can fail for users with low color vision. Add a non-color cue thickness, an outline, or an underline alongside any color change.

An indicator you cannot see does not satisfy 2.4.7. The governing contrast rule is SC 1.4.11 Non-text Contrast (Level AA), which requires a 3:1 ratio between the indicator's pixels and what sits next to them either the component's unfocused colors or the background the ring overlaps. A pale gray outline on white fails this even though, technically, an outline exists.

Two practical consequences. First, pick an indicator color with at least 3:1 against every surface it can land on; a focus ring that passes on your white form may fail on a colored card. Second, watch outline-offset interactions if the offset pushes the ring onto a dark hero image, the contrast target changes. Verify the worst case, not the convenient one. Our free contrast checker lets you test indicator-versus-background pairs in seconds, and the color contrast requirements guide explains the 4.5:1 and 3:1 thresholds in full.

WCAG 2.2 also added SC 2.4.13 Focus Appearance at Level AA, which is more specific than 1.4.11: the focus indicator must be at least as large as a 2px-thick perimeter of the focused control (or an equivalent area) and must have at least 3:1 contrast between its focused and unfocused states. Because the EAA and EN 301 549 baseline is WCAG 2.2 AA, 2.4.13 is in scope too a 2px high-contrast outline that fully surrounds the control satisfies it cleanly.

WCAG 2.2 introduced SC 2.4.11 Focus Not Obscured (Minimum) at Level AA. It addresses a different failure: the indicator is fine, but the focused element is hidden behind other content. The minimum version requires that the focused component is not entirely covered by author-created content such as overlays.

The usual culprits are predictable once you know to look. A sticky header with position: sticky covers the element you just tabbed to as you move up a long form. A cookie banner or chat widget pinned to a corner sits on top of the focused control. A persistent footer hides the last row of inputs. In each case the focus ring is rendered but underneath the overlay, where no one can see it.

• Add scroll-margin-top (or scroll-padding-top on the scroll container) equal to your sticky header height, so focused elements scroll clear of it.
• Ensure dismissible overlays cookie consent, chat bubbles can be closed and do not re-cover focus after dismissal.
• Test by tabbing through the page top to bottom and bottom to top; sticky elements obscure focus in one direction more than the other.

Forms are where this bites hardest because they have the most sequential focus stops. If you are building or auditing one, pair this check with the patterns in the accessible forms guide.

• Every interactive element links, buttons, inputs, custom widgets, skip links has a visible focus indicator on keyboard focus.
• No outline: none exists without an equally visible replacement; :focus-visible scopes keyboard-only styling.
• The indicator meets 3:1 contrast (1.4.11) against every background it can appear on, verified at the worst case.
• The indicator uses more than color alone thickness, outline, or underline carries the cue too.
• The indicator is thick and high-contrast enough to satisfy 2.4.13 Focus Appearance (a roughly 2px solid perimeter is a safe target).
• Sticky headers, banners, and chat widgets never fully obscure the focused element (2.4.11); scroll-margin is set.
• The ring survives forced-colors / Windows High Contrast Mode (use outline, not only box-shadow).

Automated tools catch the missing-outline cases quickly; the obscured-focus and contrast cases need a human tabbing through. Run a free scan with AccessScan to flag the structural issues, then keep the manual checklist above for the rest. For the broader program around this, the accessibility checklist puts focus handling in context with the other Level AA criteria.