The keyboard:focus-visible rule flags elements that receive keyboard focus without anything visibly changing. Keyboard users lose track of where they are. The fix is a clear focus indicator via :focus-visible – never outline: none without a replacement.
What the rule means
WCAG 2.4.7 requires that any keyboard-operable interface has a mode where the focus indicator is visible. Browsers show a focus ring by default, so the criterion nearly always fails because a site removes or hides it.
2.4.7 sets no minimum size or contrast for the focus indicator; those come with 2.4.13 Focus Appearance at Level AAA. An outline of at least 2px with 3:1 contrast against adjacent colours is still the safe choice, and also satisfies 1.4.11 Non-text Contrast.
Who is affected
Everyone who can see and navigates by keyboard: people with motor disabilities using a keyboard, switch or mouth stick, and people with low vision using a magnifier who only see part of the page. Without a visible focus they press Enter without knowing what they will trigger.
Why the check fails
- CSS resets with
*:focus { outline: none; }oroutline: 0and no replacement. - Removing the "ugly" ring after mouse clicks, which also removes it for keyboard users – exactly what
:focus-visiblenow solves. - Custom components (
<div role="button">, dropdowns, tabs) with no focus style. - Framework overrides, for example
box-shadow: noneon buttons in dialogs.
How to fix it
/* Before – focus is invisible to everyone */
*:focus { outline: none; }/* After – visible for keyboard users, calm on mouse click */
:focus-visible {
outline: 2px solid #005fcc; /* 5.98:1 on white */
outline-offset: 2px;
}
/* On coloured or dark surfaces: a two-tone ring */
.btn-primary:focus-visible {
outline: 2px solid transparent; /* stays visible in Windows contrast themes */
box-shadow: 0 0 0 2px #ffffff, 0 0 0 4px #1a1a1a;
}Three notes:
:focus-visibleshows the ring for keyboard use and usually not when a button is clicked, so there is no reason to remove it globally.box-shadowdisappears in forced-colours mode (Windows contrast themes); the transparentoutlinemakes sure a ring still appears there.- Check sticky headers and cookie banners: a focus indicator hidden behind another element fails 2.4.11 Focus Not Obscured (Minimum).
How to test it manually
- Load the page, click into the address bar and press Tab.
- At every step, can you see immediately where focus is – on light, dark and coloured surfaces?
- Repeat inside open dialogs and menus, and at mobile width.
- In Chrome DevTools › Rendering, emulate "forced-colors: active". Is focus still visible?
Related WCAG criterion
2.4.7 Focus Visible, Level AA. Related: 2.4.11 Focus Not Obscured (Minimum), Level AA, new in WCAG 2.2, and 1.4.11 Non-text Contrast.
How Reviseberg reports it
This rule does not come from axe-core: a rules engine doesn't press keys, so it can't see what happens on focus. Reviseberg's keyboard agent walks the journey you choose with real key presses in Chromium. Before the first key it records how every focusable element is drawn; at each Tab step it compares the focused element – and its ::before, ::after and parent, where design systems often put the ring – against that record: outline, shadow, border, background, text colour and underline. If nothing changes, it reports: "Nothing about this element changes when it takes focus." If nothing changes but the element already draws an outline or a shadow, the agent cannot tell the indicator from the design, and marks the step for a person to look at instead of guessing.
Each finding comes with the selector, its step in the keystroke trail and a cropped screenshot. In the issue list the rule appears with its severity, WCAG 2.4.7, the number of pages and the points a fix gets you back. The agent tests the journey you define; it does not reach elements outside it.