WCAG 2.4.7 Focus Visible

What it asks

When someone presses Tab, the browser moves focus to the next control and draws an indicator around it, usually an outline. That indicator is the only way a sighted keyboard user knows where they are and what pressing Enter will do. This rule asks that the indicator is visible on every control that can take keyboard focus.

The common failure is removing it. Designers often dislike the browser’s default outline and add outline: none to every control. If nothing is put in its place, keyboard users are left pressing Tab into a page that shows no change. A near miss is just as bad: a focus ring in a colour that matches the background, a change so faint nobody notices it, or a style that only shows when the mouse is over the control, so it never appears for the keyboard.

The rule asks only that an indicator is visible. It says nothing about how big or how strong. The size and contrast of the indicator are the subject of 2.4.13 Focus Appearance at Level AAA, and the question of whether the focused control is hidden behind sticky content belongs to 2.4.11 Focus Not Obscured (Minimum). This one is Level AA.

Its official name is success criterion 2.4.7 Focus Visible, at Level AA. It was added in WCAG 2.2, under guideline 2.4 Navigable and the principle Operable. The W3C’s normative text says, in part:

“Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.”

From WCAG 2.2, W3C. Full explanation: Understanding 2.4.7 Focus Visible.

Who it helps

Sighted keyboard users, including people with motor disabilities who cannot use a mouse and people who have put the mouse down because of injury. Without a visible indicator they cannot tell which of thirty links will open when they press Enter.

People with attention or memory difficulties, who look away and need to find their place again, and people using switch access or voice control that moves focus, who need to see where it landed.

What passes and what fails

These pass

• The browser’s default focus outline, left in place.
• A custom outline, two pixels thick in a colour that stands out from the page, applied to every focusable control.
• A button that changes its background on focus, clearly enough to be seen at a glance.
• A style using :focus-visible that shows the indicator for keyboard focus while hiding it after a mouse click. Keyboard users still see it, so it passes.
• A custom widget, such as a tab list, whose active tab shows a clear focus style when reached from the keyboard.

These fail

• outline: none on every link and button, with nothing in its place.
• A focus ring in a pale grey on a white background, where the change cannot be seen.
• A custom dropdown or card built from div elements that can take focus but shows no change when it does.
• A focus style attached to :hover only, so it appears for the mouse and never for the keyboard.
• A reset stylesheet that removes outlines site-wide, with a replacement added for buttons but forgotten for links and fields.

How to test it by hand

1. Put the mouse aside. Starting at the top of the page, press Tab through every control.
2. At every stop, check that something visibly changes on the control that now has focus: an outline, a border, a background or an underline.
3. If you cannot tell where focus is, press Enter and see what happens. That control has failed.
4. Open menus, dialogs and custom widgets from the keyboard and repeat inside them.
5. Search the stylesheets for outline: none, outline: 0 and box-shadow: none on focus, and check each has a replacement.
6. Note every control with no visible indicator and the component it belongs to.

What automated testing can decide

What a machine can decide

This is one of the criteria closest to a plain yes or no, but only when the page is actually used. Automated testing can move focus to a control and record whether its appearance changed, and it can read the styles to find where the default indicator was removed and whether anything replaced it. A scan of the code alone cannot do either, because the indicator only exists when focus moves.

What it cannot

Automated testing only sees the controls it reached: the states, menus and screen sizes it tried. Transitions that fade the indicator in, and hover effects that fire at the same moment, can confuse the result, and a change that is technically present but far too faint to see is a question of degree the AAA criterion measures and this one does not.

How Dreven handles it

Dreven looks at every control it reaches on your pages and shows you what each one looked like with and without focus, with the page. A reviewer decides each result from those two views, and the report says how.

A pass covers the pages and states that were audited, not the whole product. The same evidence serves 2.4.11 and 2.4.13, which ask where the focused control sits and how strong the indicator is.

No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.

Related criteria

• 2.4.11 Focus Not Obscured (Minimum) (Level AA). A visible indicator is no use if the focused control is hidden behind a sticky header.
• 2.4.13 Focus Appearance (Level AAA). The AAA rule on how large and how strong the indicator must be.
• 1.4.11 Non-text Contrast (Level AA). Non-text contrast: a focus indicator must stand out from the colours next to it.
• 2.4.3 Focus Order (Level A). Focus must move in an order that makes sense, as well as being visible.
• 2.1.1 Keyboard (Level A). Every control must be reachable from the keyboard in the first place.

Questions people ask

All WCAG 2.2 criteria, in plain words