Use components the browser highlights on focus
Browsers already highlight standard controls when they take focus. G149 says build with those controls and let the browser do it, which gives keyboard users a focus indicator that behaves the same way everywhere they go. Predictable is the point. This is a sufficient technique for 2.4.7 Focus Visible at Level AA. It has a close relative that is easy to confuse with it. This technique is about which components you choose. The other is about not overriding what those components draw, and a site can get this wrong from either end. Two newer rules go further than either. WCAG 2.2 added a Level AA rule about focus being obscured and a Level AAA rule about how the indicator itself looks, so visible is the floor rather than the finish line.
How we find it in an audit
Our reviewers tab through every page and watch. Custom widgets built from divs are where the indicator disappears, because there is no native control underneath to draw one. We check that focus is visible on every interactive element in turn, including menu items, tabs, and anything inside a modal, and we do it against each background the control appears on.
How affected users experience it
Sighted keyboard users read focus the way everyone else reads a cursor. It is the only thing telling them where they are. When a stylesheet removes it, the interface does not become slightly harder. It becomes a page where pressing Enter is a guess. People with motor disabilities who navigate by keyboard, and people using speech input, all lose their place at once.
Passes vs. fails
Passes
Menu items are real links and buttons, and the browser's own focus ring follows the keyboard through them, unmodified.
Fails
A custom div-based menu suppresses the browser's focus outline and draws nothing in its place, so keyboard focus is invisible.
How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- Element in sequential focus order has visible focusA tool can check this
Other ways to satisfy this rule
9 guides on this site are filed under 2.4.7 Focus Visible. W3C lists this one as sufficient for that rule on its own. Implement it correctly, in a way your readers' software actually supports, and the rule is met.
- C15sufficientStyle the focus indicator instead of removing it
- C40sufficientBuild focus indicators that work on any background
- C45sufficientShow keyboard focus with :focus-visible
- G165sufficientKeep the platform's default focus indicator
- G195sufficientShip a clearly visible custom focus indicator
- SCR31sufficientHighlight the focused element with script
This guide is our interpretation of W3C technique G149: Using user interface components that are highlighted by the user agent when they receive focus. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.