WCAG 2.4.7 Focus Visible requires that any keyboard-operable interface has a mode of operation where the keyboard focus indicator is visible. In plain English: as a person presses Tab through your page, they must always be able to see exactly which link, button, or field is currently selected. It is a Level AA criterion.

What 2.4.7 requires (and what it doesn’t)

The official wording from the W3C specification is short: “Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.” That single sentence carries a few important nuances.

  • It is about visibility, not style. WCAG does not require a particular color, thickness, or shape. A browser’s default outline, a custom box-shadow, a background swap, or an underline can all satisfy it — as long as you can see which element has focus.
  • “A mode of operation” is deliberate. Modern browsers using :focus-visible show the indicator during keyboard use and hide it for mouse clicks. That is allowed. The rule only demands that at least one operating mode reveals focus, and the indicator must not vanish on a timer.
  • It does not measure contrast or size. Whether the indicator is strong enough is governed by separate criteria: 1.4.11 Non-text Contrast (the indicator needs 3:1 contrast in WCAG 2.1) and the new 2.4.11 and 2.4.13 added in WCAG 2.2. A faint dotted outline can technically pass 2.4.7 and still fail 1.4.11.

Think of 2.4.7 as the floor: focus has to be visible at all. The contrast and obscuring rules build on top of it.

Who it affects

The focus indicator is, quite literally, the cursor for anyone who cannot use a mouse. Per the W3C Understanding document, the people who depend on it most include:

  • Keyboard-only users — people with motor disabilities (tremor, paralysis, repetitive-strain injury, limb difference) who navigate with Tab, Shift+Tab, arrows, and Enter.
  • Switch and sip-and-puff users, whose assistive hardware drives the same keyboard focus model.
  • Sighted screen-magnifier users, who see only a slice of the page and rely on the ring to find where they are.
  • People with cognitive, attention, or memory disabilities, who lose their place without a clear “you are here” marker.

Crucially, this is the one major accessibility barrier that hurts sighted people. A blind screen-reader user hears the focused element announced; a sighted keyboard user has nothing but the visible ring. Remove it and you lock them out of every link, menu, and checkout button.

The most common failure: outline: none

By far the most frequent way sites break 2.4.7 is the CSS reset that designers paste in to kill the “ugly” default outline. The W3C documents this as failure F78, and it explicitly names outline: none and outline: 0 as failures when no replacement is supplied.

/* FAILS 2.4.7 — removes focus with no replacement */
:focus {
  outline: none;
}
a:focus,
button:focus {
  outline: 0;
}

F78 also covers a subtler trap: an outline that is technically drawn but impossible to perceive, such as a focus style that matches an outline already present in the default state, or a thick border that occludes it. The fix is not to keep the browser default forever — it is to provide a deliberate, visible focus style:

/* PASSES 2.4.7 — visible, intentional focus style */
:focus-visible {
  outline: 3px solid #1b4dff;
  outline-offset: 2px;
  border-radius: 2px;
}

/* Optional: hide the ring for mouse clicks, keep it for keyboard */
:focus:not(:focus-visible) {
  outline: none;
}

Using :focus-visible (W3C technique C45) is the modern best practice: keyboard users get a crisp ring, mouse users don’t see one on click, and both modes are conformant. Other failures the spec calls out include F55 — scripts that blur an element the instant it receives focus, yanking the indicator away before anyone can see it.

A few real-world patterns we see constantly during remediation:

  • Global reset. A *:focus { outline: none } in a normalize file silences focus site-wide.
  • Custom widgets with no focus management. Hand-built dropdowns, tabs, and modals where focus lands somewhere invisible — usually paired with a 2.1.1 Keyboard failure too.
  • Ghost outlines. A faint outline in a near-background color that’s “present” but unseeable — failing F78 and 1.4.11 contrast at once.
  • Clipped rings. Card and image links where the focus ring is cut off by overflow: hidden.

How to test for focus visible

This is a manual test — automated scanners largely cannot judge whether a focus indicator is perceivable, which is exactly why the issue is so widespread. The check takes minutes:

  1. Put your mouse away. Click once in the address bar, then start pressing Tab from the top of the page.
  2. Watch every stop. Tab through every link, button, form field, menu item, and custom control. At each stop, ask: can I instantly tell what is focused? If the answer is ever no, that element fails 2.4.7.
  3. Test interactive widgets. Open menus, modals, date pickers, and carousels. Confirm focus is visible inside them and returns somewhere visible when they close.
  4. Check both directions. Use Shift+Tab to move backward — some sites lose the indicator going in reverse.
  5. Verify your replacement has contrast. Once focus is visible, confirm the indicator hits 3:1 against its background for 1.4.11. Browser DevTools can measure it.

Pair this keyboard walkthrough with the rest of a keyboard navigation review. The WebAIM browser extension and Chrome/Firefox DevTools highlight the focused element, but your own Tab key is the real test instrument here.

Why it matters legally

Keyboard accessibility — including a visible focus indicator — is a recurring theme in U.S. web-accessibility litigation. Plaintiffs filed roughly 4,000 digital accessibility lawsuits in 2024, and filings climbed again in 2025, with UsableNet’s tracking reporting thousands more cases across federal and state courts. Demand letters frequently cite the inability to “navigate the website using a keyboard” — and a missing focus indicator is one of the easiest barriers for a plaintiff’s tester to document, because all it takes is pressing Tab on a recording.

Courts and the U.S. Department of Justice continue to point to WCAG 2.1 Level AA as the practical benchmark for an accessible website under ADA Title III, and 2.4.7 sits squarely inside that bar. The same standard anchors Section 508 and the EU’s EN 301 549. To see how these checkpoints relate, browse the full list of WCAG success criteria.

This is general information, not legal advice. For your specific exposure, consult a qualified attorney.

Fixing it the right way

Restoring visible focus is hands-on CSS work, not a toggle. We remove the offending resets, add a deliberate :focus-visible style that clears 3:1 contrast, and verify focus management inside every custom widget by keyboard. That is the opposite of an accessibility overlay: an overlay’s “keyboard navigation” button can’t reliably repair focus that your own JavaScript and CSS strip away, and it won’t satisfy a skeptical tester — more on why overlays don’t work.

If you’re not sure where focus disappears on your site, the fastest first step is to run a free accessibility scan and then have our team restore visible focus across every interactive element — by hand, in your real code.