Focus indicators: visible, high contrast and never hidden

A focus indicator is the visible change, usually an outline or ring, that shows which element has keyboard focus. W3C defines it as the pixels changed to show that a component is in a focused state. Without one, a sighted keyboard user cannot tell what the next keystroke will act on. W3C's Understanding page for 2.4.7 names keyboard users and people with attention, short-term memory or executive function limitations as beneficiaries, and its page for 2.4.11 adds switch and voice input users and people who use screen magnification.

Three Level AA criteria cover focus indicators, and two Level AAA criteria describe the stronger version. This guide covers what each asks, how to style a ring that passes, and how to keep it visible. The full keyboard routine is in our keyboard accessibility test, where focus goes next is in focus order and tabindex, and contrast in general is in the color contrast guide.

What WCAG asks of a focus indicator

Read together, 2.4.7 requires that an indicator exists, 1.4.11 that a custom one can be seen against its surroundings, and 2.4.11 that the focused item is not covered up. W3C says 2.4.7 requires that a visible indicator exists and 2.4.13 defines a minimum level of visibility. It measures the change between the focused and unfocused states, where 1.4.11 measures contrast with the neighbors, so an indicator can pass one and fail the other.

Neither AAA criterion is part of Level AA, and WCAG 2.2 itself says it is not recommended that Level AAA conformance be required as a general policy for entire sites, because some content cannot satisfy every AAA criterion. In GotAlt's reading, 2.4.13 is still a useful design target for an indicator, because it turns "visible" into a size and a ratio (see WCAG conformance levels).

Is the browser's default focus ring enough?

It can be. W3C lists using the platform's default focus indicator (technique G165) as sufficient for 2.4.7. Understanding 1.4.11 exempts a component whose appearance the browser determines and the author has not modified, and 2.4.7 still requires the indicator to be visible. G165 adds a reason to keep it where it works: users can customize the platform's indicator, and that customization carries over only when the page uses the native one.

The default has two weaknesses. W3C's 2.4.13 page says default indicators vary by component, browser and operating system, and can be difficult to see in some browsers. And the 2.4.13 exception for an unmodified default holds only when the author changes neither the indicator nor the background behind it. In GotAlt's reading, test a default ring on any button or panel you have recolored.

Why outline: none breaks keyboard use

The CSS outline property controls the browser's default ring. MDN says a value of 0 or none removes the browser's default focus style, and that an element you can interact with must have a visible focus indicator. WebAIM advises avoiding outline:0, outline:none and other styles that remove or limit the visibility of keyboard focus indicators.

W3C names the removal as failure F78, which applies to 2.4.7, 1.4.11 and 2.4.13. Its examples include a rule that removes the outline, a thin dotted link outline that looks like the focus indicator, and a thick border in the same color. Failure F55 covers a script that calls blur on an element as soon as it receives focus.

/* Fails: the ring is gone and nothing replaces it */
button:focus {
  outline: none;
}

A second trap is the cascade. MDN says each pseudo-class adds 0-1-0 to a selector's specificity, so a:focus (0-1-1) outweighs a site-wide :focus-visible rule (0-1-0), and a reset such as a:focus { outline: none } can cancel the ring you wrote. Search your CSS for outline, then Tab through the page. The MDN specificity page explains the weights.

Style your own ring with :focus-visible

Browsers once keyed focus rings to :focus alone, and, as MDN's :focus-visible page records, some authors removed the rings because of how they looked. The :focus-visible pseudo-class matches a focused element only when the browser decides focus should be made evident: generally after keyboard use, and in a text box too, but not after a mouse click on a button. It changes how the indicator looks without changing when it appears.

:focus-visible {
  outline: 3px solid #1a56db;
  outline-offset: 2px;
}

MDN lists :focus-visible as Baseline widely available, in browsers since March 2022. W3C's technique C45 covers the approach and adds a condition: it is sufficient only if the styles give a visible indicator.

Contrast, thickness and changing backgrounds

3:1 against which colors?

When you style the indicator, 1.4.11 applies, and Understanding 1.4.11 says where to measure. A ring outside the component needs 3:1 against the background the component sits on. A border that changes color needs 3:1 against both adjacent colors. An indicator inside the component is measured against the colors inside it, and for a split indicator either part may contrast. A ring around a button on a colored panel is therefore checked against the panel, not the page.

How thick?

W3C's 2.4.13 page says a solid outline must be at least 2 pixels thick, and that an indicator inset inside the component must be thicker to cover the same area (its example uses 3 pixels). Treat 2 pixels as the floor, and prefer an outline outside the component with a small offset.

One ring for every background

No single color passes everywhere. The table shows contrast ratios computed with GotAlt's contrast checker, using the WCAG formula, for three single-color rings on four backgrounds and the best band of a two-color ring.

W3C's technique C40 gives the rule behind the last row: pair a light and a dark color with at least 9:1 contrast between them, and at least one of the two reaches 3:1 against any solid background. White and #1a1a1a are 17.40:1 apart. C40 builds the indicator from an inner outline and an outer box-shadow, each band 2 CSS pixels thick:

:focus-visible {
  outline: 2px solid #ffffff;
  box-shadow: 0 0 0 4px #1a1a1a;
}

C40 says this holds only over one solid background at a time, not over an image, a gradient or another component. A ring over a photo is the problem our text over images guide describes for text. Check the ring in every theme, including dark mode, and pick its color with your brand palette in mind.

Rings that get cut off or disappear

• Clipping. MDN says overflow: hidden clips content at the element's padding box, so an outside outline at the edge of such a parent can be cut off. A negative outline-offset draws it inside instead. This is GotAlt's practical note, not WCAG text.
• Forced colors. In forced colors mode, of which Windows High Contrast mode is the example, MDN says box-shadow is forced to none and outline-color takes browser-specified values. C40 warns against relying on box-shadow alone for this reason, which is why the example above keeps the outline.
• Timers. W3C's intent text for 2.4.7 says that when keyboard focus is shown, it must remain visible, so an indicator that fades out on a timer is a problem.

Keeping focus from being hidden

Success criterion 2.4.11 is about the focused component, not the ring: it must not be entirely hidden by author-created content. W3C names sticky headers, sticky footers and non-modal dialogs as the usual causes. A sticky element stays in view as the page scrolls. At Level AA, partly covering the component is allowed, though W3C says authors should minimize how much and how often, and covering all of it fails. Failure F110 describes a footer that covers the focused item as the user tabs down and a header that does so as the user tabs back up, so test both directions.

A sticky cookie banner that fully covers a focused component fails, W3C says, and approaches that pass include making the banner modal, using scroll padding, or closing it when it loses focus. Our accessible modals guide covers modals. For scroll padding, technique C43 uses the scroll-padding property to leave room around the scrolling area, so a focused item scrolls clear of a fixed bar:

html {
  scroll-padding-top: 5rem;
  scroll-padding-bottom: 6rem;
}

Set the values to your bars' real heights, and check at narrow widths and at 200% zoom. Content the user opens is treated differently: a menu or tooltip that closes when it is no longer in use does not fail, and a persistent panel such as a chat window may cover the item if the user can reveal it without moving focus. W3C adds that a semi-transparent overlay can pass 2.4.11 but fail 1.4.11 if the indicator is no longer distinguishable through it. Level AAA 2.4.12 allows no part of the component to be hidden.

Which WCAG version covers this?

Criteria 2.4.7 and 1.4.11 are in WCAG 2.1, so standards that name WCAG 2.1 Level AA include them, such as the ADA Title II web rule (see our Title II deadline guide) and EN 301 549 v3.2.1 (see our EN 301 549 page). Criteria 2.4.11 to 2.4.13 arrived in WCAG 2.2, so they apply where a law or contract names 2.2, as GOV.UK's guidance for UK public sector bodies does (see UK accessibility law). See which WCAG version to use and what's new in WCAG 2.2. This page is general information, not legal advice.

Check it yourself

1. Tab through each page template. At every stop, ask whether you can see where focus is, including in dark sections, over photos, in custom widgets and in open dialogs. Our keyboard accessibility test has the full routine.
2. Measure the ring. Enter the ring color and the color next to it in the free contrast checker. A custom ring needs 3:1. For a two-color ring, check that the bands are at least 9:1 apart and that one passes on each background.
3. Force the state. In Chrome DevTools, select an element and use the :hov panel in the Styles tab to switch on :focus or :focus-visible, as Google's DevTools CSS reference describes.
4. Test the sticky content. Tab down and back up near any sticky header, footer or banner, at a narrow width and at 200% zoom.
5. Run the page check. The accessibility bookmarklet reads the rendered page, including pages behind a login, and measures text contrast. It does not check focus indicators, and its limits list says it cannot tell whether a page works with a keyboard, so use it beside the steps above, not instead of them.

The free scan reads the HTML your server sends, and whether a ring is visible depends on computed styles, which a markup parser never produces (what we check explains why), so scanners miss issues like this. To track every Level A and AA criterion, use the WCAG 2.2 checklist.