What 2.4.7 requires
Any keyboard-operable user interface must have a mode of operation where the keyboard focus indicator is visible. In practice, when someone Tabs to a link, button or field, they can see which one it is. This is a plain-language summary. The normative text, including every exception, is in the W3C Recommendation, with the W3C's explanation in Understanding 2.4.7 (opens in a new tab) [1][2].
Exceptions and scope:
- None listed. WCAG 2.2 adds related requirements: 2.4.11 Focus Not Obscured (Minimum, AA), that the focused element isn't entirely hidden by things like sticky headers, and 2.4.13 Focus Appearance (AAA), on the indicator's size and contrast.
Why it matters
Without a visible focus indicator, a sighted keyboard user is navigating blind: they press Tab and have no idea where they are. The most common cause is a single line of CSS (outline: none) added to remove the browser's default ring for mouse users.
Common failures
Outline removed with nothing to replace it
/* Fails */
*:focus { outline: none; }
/* Better */
:focus-visible { outline: 3px solid #1a5fd0; outline-offset: 2px; }Indicator too faint to see
A 1px pale outline or a slight color change on a light background.
/* Fails */
a:focus { outline: 1px solid #eee }
/* Better */
a:focus-visible { outline: 3px solid currentColor }Custom controls with no focus style
Focus goes to a styled div or a custom checkbox with no visible change.
/* Fails */
.toggle:focus {}
/* Better */
.toggle:focus-visible { box-shadow: 0 0 0 3px #1a5fd0 }Focus hidden behind sticky UI (2.4.11)
The focused element scrolls under a sticky header or cookie banner.
/* Fails */
header { position: sticky }
/* Better */
html { scroll-padding-top: 5rem }Can automated testing check 2.4.7?
Mostly no. Whether focus is visible depends on rendered styles at the moment of focus, which a static rule check doesn't evaluate.
| axe-core 4.13.0 rule | What it checks |
|---|---|
| (none mapped) | axe-core maps no rules to 2.4.7 |
What automation can't decide: Whether a focus style exists and is perceivable, whether it disappears on certain components, and whether the focused element is covered by other content.
A clean automated result is never proof that 2.4.7 is met. See why sites pass axe-core but fail real screen reader users.
How to test it by hand
- Tab through the whole page. At every stop, can you see where focus is without hunting?
- Pay special attention to custom controls, cards, menus and anything inside dialogs.
- Check focus on both light and dark backgrounds, and in dark mode if it's supported.
- Scroll so sticky headers or banners are in play and check focused elements aren't hidden behind them (2.4.11).
New to screen readers? Start with how to test a website with a screen reader and how to test keyboard-only navigation.
How Accessible helps (and where it stops)
Real-user monitoring includes an observer for invisible focus in real sessions. Journeys list "a focus indicator that disappears" (2.4.7) among the keyboard failures they look for while operating the controls a task needs.
Where it stops: Whether an indicator is clearly visible to a person is ultimately a visual judgment. Treat automated signals as a prompt to look, not a verdict. No automated tool, ours included, can certify that a criterion is met.
Related criteria
Sources
- Understanding Success Criterion 2.4.7: Focus Visible (opens in a new tab). W3C Web Accessibility Initiative. Accessed October 18, 2026.
- Web Content Accessibility Guidelines (WCAG) 2.2, Success Criterion 2.4.7 (opens in a new tab). W3C Recommendation. Accessed October 18, 2026.
- axe-core rule descriptions (opens in a new tab). Deque Systems, axe-core 4.13.0. Accessed October 18, 2026.
Meeting a success criterion is not the same as legal compliance, which depends on the rules that apply to you. No automated tool can certify conformance.