Focus indicator not visible
focus-visible
- WCAG success criterion
- 2.4.7 (level AA)
- Outcome class
- Manual. A tool cannot decide this check. The audit only points a person at it; it is never counted as automatically verified.
- Area
- Accessibility, Navigation & Operation
- Default severity
- high
- axe-core rule
focus-visible
Why we flag this
Keyboard users cannot see which element is focused.
CSS outline:none without an alternative.
What the rule checks
Scope. Pages whose accessibility tree has more than five nodes and no focusable or interactive node besides the document root.
Expectation. One needs_review per page (at "root") when the page has content (more than five AX nodes) but no focusable or interactive element: 2.4.7 has nothing to apply to, yet a page without any control is unusual enough that a human should check whether operable content was built from plain elements. A page with focusable elements gets no note from this rule. Never pass or violation.
Why a person has to decide. The accessibility tree carries no focus-indicator data; 2.4.7 itself is decided by focus/outline-removed. This rule can only point a human at a page that exposes no focusable element at all, where controls may be built from plain elements.
Source. WCAG 2.2 SC 2.4.7 Focus Visible (and SC 2.1.1 for the plain-element controls the note points at)
Detection: tree; needs ax_tree.
Failing example
The check flags this for review. Corpus case no_focus_targets. The page may contain further findings for other rules.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Page with no focusable elements and an auto-scrolling marquee</title>
</head>
<body>
<main>
<h1>Announcement</h1>
<p>This page has no links, buttons, or form fields anywhere.</p>
<marquee>Breaking news scrolls here indefinitely</marquee>
<p>Just plain text content beneath the marquee.</p>
</main>
</body>
</html>This page is generated from the rule catalogue and the rule contracts; see therule overview for how the outcome classes are derived.