2.4.7 Focus Visible
- Level AA
- Operable
- Since WCAG 2.0
Summary
Sighted keyboard users navigate by watching the focus indicator move from control to control. If that indicator vanishes, the interface becomes a guessing game: the user is somewhere on the page, pressing Enter into the unknown. This criterion, at Level AA since WCAG 2.0, requires that any keyboard operable interface has a mode of operation where the keyboard focus indicator is visible.
The wording matters. "A mode of operation" means at least one visible mode must exist: an interface that shows focus rings only during keyboard use (the modern browser default) passes, because that is a mode where the indicator is visible. The criterion does not prescribe what the indicator looks like or how strong it must be; it asks whether one exists at all.
The overwhelming cause of failures is not exotic. It is outline: none (or outline: 0) applied in a CSS reset or applied to suppress the ring for mouse users, with nothing provided in its place. One line of stylesheet housekeeping silently strips keyboard navigation from an entire site.
Official wording
Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
EN 301 549 mapping
- Web pages
- Clause 9.2.4.7
- Software and native apps
- Clause 11.2.4.7
Clauses 9.2.4.7 (web) and 11.2.4.7 (software) apply this criterion unchanged, so keyboard focus must be visible in native apps just as on the web.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
The test is a keyboard walkthrough. Put the mouse down, press Tab (and Shift+Tab) through every interactive element on the page, and watch for the indicator disappearing. Every focusable stop, including links, buttons, form fields, custom widgets, and anything with tabindex="0", must show some visible change when it receives focus.
Browser default indicators count. The focus ring is user agent behaviour, so an author who never touches focus styling passes automatically. The criterion is failed by subtraction: search the CSS for outline: none and outline: 0, and for each occurrence check whether a replacement indicator (a border change, background change, box-shadow, or custom outline) appears on focus. Suppression without replacement is the classic fail.
Understand :focus-visible versus :focus. Styling only :focus-visible is fine: browsers apply it during keyboard navigation, which is exactly the mode this criterion protects. The dangerous pattern is :focus { outline: none } on its own, which removes the indicator in every mode, including keyboard.
Two subtler patterns to watch for. First, partial coverage: a design system styles focus on buttons and inputs but the team's custom dropdowns, cards, or carousels never received a focus style, so the indicator flickers out mid-page. Second, focus landing on invisible elements: if Tab moves into a closed menu, an offscreen slide, or a hidden modal, the indicator is technically drawn but cannot be seen, which fails just as surely as a missing outline.
iOS
This criterion applies to iOS when a hardware keyboard is connected and Full Keyboard Access is switched on (Settings > Accessibility > Keyboards > Full Keyboard Access). That is the keyboard operable mode of an iOS app, so it is the mode you test.
With Full Keyboard Access enabled, move through the screen with Tab and the arrow keys. Standard UIKit and SwiftUI controls receive the system focus ring automatically, so an app built from standard components normally passes without effort. The failures live in custom controls: a custom view that accepts keyboard focus but draws no ring, suppresses the system focus effect, or paints its own focus state in a colour indistinguishable from its resting state leaves the user lost mid-screen exactly as a missing web outline does.
Test every screen the same way as on the web: keyboard in, pointer down, and confirm a visible indicator on every focusable stop, including cells, chips, toolbar items, and anything custom. Keep the scope to iOS keyboard access; the separate focus-driven interaction model used on Apple's TV platform is not what this criterion covers in an iOS audit.
Android
On Android, keyboard operation means a connected hardware keyboard or d-pad navigation, and both are easy to exercise on an emulator: connect your development machine's keyboard, then Tab and arrow through the screen and watch each control as it takes focus.
Framework widgets show a focus highlight by default. The common failure is a custom view that is marked focusable but defines no visual for the focused state: without a focused state in its state-list drawable (or equivalent custom drawing), the view accepts focus invisibly, and keyboard users lose their place the moment they reach it. Any view added to the tab order needs a corresponding focused appearance.
In Compose, focus visuals come from the indication tied to a component's interaction source. Material components provide one out of the box, but a clickable built without indication, or a custom component that never observes its focused interaction state, produces the same invisible-focus result as a bare focusable view. Grade what you can see in the walkthrough, not what the code promises: if the highlight does not appear on the emulator when the control takes focus, it fails.
Pass and fail examples
Passes:
- A site that leaves the default browser focus outline untouched: user agent indicators satisfy the criterion.
outline: nonepaired with a visible replacement, such as a box-shadow ring or a strong border change on focus: suppressing the default is fine when something visible takes its place.- A skip link that is hidden until it receives focus, then appears at the top of the page: while focused it is visible, which is what the criterion asks.
- Focus styles applied via
:focus-visibleonly, so mouse clicks show no ring but keyboard navigation does: keyboard mode has a visible indicator.
Fails:
- A global reset containing
outline: nonewith no replacement styles: every keyboard stop on the site is invisible. - A custom dropdown whose options can be reached with arrow keys but show no visual change on focus: the component is keyboard operable with no visible indicator.
- Tab order that moves into a closed off-canvas menu: focus sits on elements the user cannot see.
Not a fail under this criterion:
- A focus indicator that is present but faint, for example a pale ring at around 1.2:1 against the background: an indicator exists, so this criterion is met, and the weak contrast is graded under Non-text Contrast instead. This split is the W3C's own: this criterion sets no minimum for the indicator's form, while the understanding material for Non-text Contrast states that in combination with Focus Visible the indicator "must have sufficient contrast against the adjacent background". Only an indicator so faint it cannot be perceived at all should be treated as no visible indicator here.
Commonly confused with
- Non-text Contrast, SC 1.4.11. This criterion asks whether an indicator exists; 1.4.11 asks whether it has at least 3:1 contrast. "The focus ring is there but I can barely see it" is a 1.4.11 finding, not a 2.4.7 finding.
- Focus Not Obscured (Minimum), SC 2.4.11. If the indicator is drawn but the focused element has scrolled behind a sticky header, cookie banner, or floating toolbar, the failure belongs to 2.4.11. Here the author provided an indicator; other content is hiding it.
- Focus Order, SC 2.4.3. Whether focus moves through the page in a sequence that preserves meaning is a separate question. A page can show a beautiful indicator that jumps around illogically (a 2.4.3 fail), or move in perfect order invisibly (a 2.4.7 fail).
- Keyboard, SC 2.1.1. Whether every function can be reached and operated by keyboard at all is 2.1.1. If a control never receives keyboard focus, that is a keyboard access failure; 2.4.7 only grades the controls that do.
How AUDITSU tests this
AUDITSU's audit walkthrough includes a keyboard pass on every screen you review. The walkthrough asks you to put the pointer aside, Tab and arrow through the full screen, and confirm a visible indicator on every focus stop, flagging any control where the indicator disappears, any suppressed outline without a replacement, and any focus movement into hidden content. Each check records a pass, fail, or not applicable result per screen with evidence attached, so a missing indicator lands in your report tied to the exact screen and control.
The criterion applies unchanged to both web content and native apps under EN 301 549, so the same keyboard walkthrough covers your European Accessibility Act evidence across platforms.
For the full guided workflow, see the audit platform.