WCAG 2.4.7 Focus Visible: Never Hide the Focus

One line of CSS that strands keyboard users

A designer sees a blue ring around a button after clicking it and asks for it to go. A developer adds outline: none to every element. The page looks cleaner, and every keyboard user loses track of where they are. They press Tab and nothing visible happens. They press Enter and something unexpected opens. This single line is behind most of the focus visible failures we find.

What WCAG 2.4.7 requires

Any part of the page that can be used with a keyboard must show a visible focus indicator when it has keyboard focus. W3C words it as "a mode of operation where the keyboard focus indicator is visible" (WCAG 2.2, 2.4.7). A focus indicator is the visual mark, usually an outline, underline, color change or border, that shows which item will respond to the next key press.

2.4.7 itself sets no size or contrast. The browser's default ring passes as long as you do not remove or hide it. The stricter measurements live in other criteria, covered further down.

People who need to see focus

• Sighted keyboard users, including many people with motor disabilities, need the indicator the way mouse users need a pointer.
• Switch and voice users who move step by step through controls watch the indicator to track their position.
• People with low vision need a strong, high contrast indicator to find it at all.
• Anyone with attention or memory difficulties rely on it to resume a task after a break.

Screen reader users who are blind rely on speech rather than the indicator, but many screen reader users have some sight and use both.

Removing the ring versus restyling it

a:focus, button:focus {
  outline: none;
}

:focus-visible {
  outline: 3px solid #1a4fa0;
  outline-offset: 2px;
  box-shadow: 0 0 0 5px #ffffff;
}

The white shadow outside the blue outline keeps the indicator visible on dark areas too. If you change only the background color on focus, check the change is strong enough to notice; a slight shade shift is a common borderline case.

Focus visible wcag failures in real projects

How to test wcag 2.4.7 in five minutes

Automated tools rarely catch this one, because they cannot see whether an outline is visible against a particular background. A person with a keyboard can check a template in minutes.

1. Use the keyboard only. Load the page and press Tab from the very top, without touching the mouse.
2. Find the indicator every time. At each stop, confirm you can see which element has focus within a second or two, without guessing.
3. Cover every kind of control. Check links, buttons, fields, checkboxes, tabs, menu items, cards and controls inside dialogs and embedded widgets.
4. Try different backgrounds. Pay attention where the background changes, such as dark headers, image banners and colored footers, since indicators often vanish there.
5. Search the CSS. Look for outline none or outline 0 rules and confirm each one is paired with a visible replacement style.
6. Check partly hidden focus. Note any focused item hidden behind a fixed banner, consent notice or floating help widget; that is a related 2.4.11 issue.

Focus visible, focus not obscured and focus appearance

WCAG 2.2 added two related rules and kept 2.4.7 at AA, so a full focus review now has several parts.

Read focus not obscured for the sticky header problem and non-text contrast for the 3:1 measurement. Focus order, the sequence of stops, is on its own page. The official text is in Understanding Focus Visible.