Category: Input and Navigation

Focus Visible

Also known as: Visible Focus, Focus Indicator, Keyboard Focus Indicator

Simply put

Focus Visible means that when someone uses a keyboard to move through a web page, they can clearly see which element is currently selected. This visual cue, often a highlight or outline around a link, button, or form field, helps people who navigate without a mouse know where they are on the page.

Formal definition

Focus Visible is WCAG Success Criterion 2.4.7 (Level AA), which requires that any keyboard-operable user interface have a mode of operation in which the keyboard focus indicator is visible. The criterion ensures that a user relying on keyboard navigation can perceive which component currently holds focus. Authors commonly implement or enhance this indicator using CSS, including the :focus and :focus-visible pseudo-classes; :focus-visible allows a visible focus indication to be applied based on user-agent heuristics (for example, when input comes from a keyboard rather than a pointing device). Meeting 2.4.7 addresses the presence of a visible indicator, but related considerations such as the appearance, contrast, and non-obscuring of the focus indicator are governed by other, separate success criteria and should be evaluated distinctly. Conformance with this criterion does not by itself guarantee an accessible or usable focus experience; manual and assistive technology testing is generally required.

Why it matters

For people who navigate the web without a mouse, including many keyboard-only users and people using certain assistive technologies, the visible focus indicator is often the only way to know which element is currently selected. Without a perceptible indicator, a user pressing Tab through links, buttons, and form fields can lose track of their position on the page, making it difficult or impossible to complete tasks such as filling out a form or activating a control. Focus Visible, WCAG Success Criterion 2.4.7 at Level AA, addresses this need by requiring that keyboard-operable interfaces have a mode of operation in which the focus indicator is visible.

Because Level AA is the conformance level most commonly cited as a target in accessibility policies, settlements, and agency guidance, a missing or suppressed focus indicator is a frequently flagged issue during accessibility evaluations. A common cause is CSS that removes default browser outlines (for example, setting an outline to none) without providing a replacement indicator, which can leave keyboard users with no visual cue at all.

It is important to understand what this criterion does and does not cover. Meeting 2.4.7 addresses the presence of a visible indicator, but the appearance, contrast, and whether the indicator is obscured by other content are governed by separate success criteria and should be evaluated distinctly. Conformance with 2.4.7 alone does not guarantee a usable focus experience, and this guidance is not legal advice; requirements evolve through regulation and case law, and organizations should consult qualified counsel and current agency rulemaking where legal obligations are at issue.

Who it's relevant to

Front-end developers

Developers are responsible for ensuring that a visible focus indicator is present on keyboard-operable components and is not removed by CSS without a replacement. Using :focus and :focus-visible appropriately can help present focus styles for keyboard users while reducing indicators some consider obtrusive when a pointing device is used.

UX and visual designers

Designers help define focus indicators that are clearly visible and recognizable so that keyboard users can perceive which element holds focus. Because visible focus signals that something is interactive, designers should generally avoid applying focus styling to static elements such as headings or paragraphs, which can confuse users.

Accessibility testers and QA teams

Testers verify that a visible focus indicator appears as focus moves through interactive elements. Automated tools detect only a portion of issues, so manual keyboard testing and assistive technology testing are generally required to confirm the focus indicator behaves as intended.

Compliance officers and accessibility program owners

Those managing conformance efforts should recognize that Focus Visible is a Level AA criterion, the level most commonly cited as a target, and that related concerns about the indicator's appearance or being obscured fall under separate criteria. This guidance is not legal advice, and applicable obligations should be confirmed with qualified counsel.

Inside Focus Visible

Success Criterion 2.4.7 Focus Visible (Level AA)

A WCAG success criterion, present since WCAG 2.0, requiring that any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. It ensures that users navigating by keyboard can perceive which element currently has focus.

Keyboard focus indicator

The visual signal (such as an outline, border, or highlight) that shows which interactive element currently receives keyboard input. Focus Visible is concerned with whether this indicator can be seen, not with its specific size or contrast.

Scope of applicability

The criterion applies to keyboard-operable interfaces. When focus moves to a component via keyboard, some visible indication of that focus must be available in at least one mode of operation.

Relationship to related criteria

Focus Visible (2.4.7, Level AA) addresses whether focus is visible at all. WCAG 2.2 later introduced additional focus-related criteria that address other aspects: Focus Not Obscured (Minimum) as 2.4.11 (Level AA), Focus Not Obscured (Enhanced) as 2.4.12 (Level AAA), and Focus Appearance as 2.4.13 (Level AAA), which concerns the visual prominence of the indicator.

Common questions

Answers to the questions practitioners most commonly ask about Focus Visible.

Does removing the focus indicator with CSS (such as outline: none) improve my site's appearance without causing accessibility problems?

No. Removing the visible focus indicator commonly creates a barrier for keyboard and switch users who rely on it to track which element currently has focus. WCAG Success Criterion 2.4.7 Focus Visible (Level AA, introduced in WCAG 2.0) requires that any keyboard-operable interface have a mode of operation where the focus indicator is visible. If you suppress the default outline for design reasons, you should replace it with an equally perceivable custom indicator rather than eliminating it. Note that meeting this criterion supports accessibility but does not by itself guarantee full compliance or an accessible experience for all users.

Is Focus Visible (2.4.7) the same requirement as Focus Appearance in WCAG 2.2?

No, they are distinct. Focus Visible (2.4.7) is a Level AA criterion from WCAG 2.0 that requires a visible focus indicator to exist, but it does not specify how prominent or large that indicator must be. WCAG 2.2 later added Success Criterion 2.4.13 Focus Appearance at Level AAA, which addresses the size and contrast of the focus indicator so that it is more clearly perceivable. WCAG 2.2 also added two related criteria not to be confused with these: 2.4.11 Focus Not Obscured (Minimum), Level AA, and 2.4.12 Focus Not Obscured (Enhanced), Level AAA. Because Focus Appearance is Level AAA, it is generally not part of the Level AA conformance target most commonly cited.

How can I provide a visible focus indicator while still customizing my site's design?

Rather than removing the default outline entirely, you can style a custom focus indicator using CSS properties such as outline, box-shadow, or border, and target it with the :focus or :focus-visible pseudo-classes. The :focus-visible pseudo-class allows you to show an indicator for keyboard navigation while suppressing it for mouse clicks where appropriate. The goal is an indicator that remains clearly perceivable against its background. Confirm the result through manual keyboard testing rather than relying on visual design assumptions alone.

How do I test whether my focus indicators meet Focus Visible?

Testing generally requires manual keyboard navigation: use the Tab key (and Shift+Tab) to move through all interactive elements and confirm that a visible indicator appears on each focused control, including links, buttons, form fields, and custom widgets. Automated tools detect only a portion of focus-related issues and often cannot reliably determine whether an indicator is perceivable, so manual and assistive technology testing are needed. Testing across multiple browsers is advisable because default focus styling can vary.

What is the difference between :focus and :focus-visible when implementing focus indicators?

The :focus pseudo-class applies whenever an element receives focus, regardless of input method, while :focus-visible applies when the browser determines that a focus indicator should be shown, typically during keyboard interaction. Using :focus-visible can let you display a prominent indicator for keyboard users without showing it on every mouse click. When relying on :focus-visible, verify that keyboard users consistently receive a visible indicator, and consider fallback behavior in environments where support may differ.

Does Focus Visible apply to custom interactive components such as menus and modal dialogs?

Yes. Any component that is keyboard operable and can receive focus should provide a visible focus indicator, including custom widgets like menus, tabs, modal dialogs, and interactive controls built with scripting. Custom components often lose default focus styling when native elements are replaced or when focus is managed programmatically, so implementers should explicitly ensure a visible indicator is present and verify it through keyboard testing.

Common misconceptions

Meeting Focus Visible (2.4.7) means the focus indicator is guaranteed to be sufficiently prominent or high-contrast.

Focus Visible only requires that a focus indicator be visible in at least one mode of operation. The prominence, size, and contrast of the indicator are addressed separately by Focus Appearance (2.4.13, Level AAA in WCAG 2.2), which is a distinct and higher-level criterion.

Focus Not Obscured is the same requirement as Focus Visible.

These are separate criteria. Focus Visible (2.4.7) concerns whether a focus indicator exists and can be seen, while Focus Not Obscured (Minimum) 2.4.11 and Focus Not Obscured (Enhanced) 2.4.12, both added in WCAG 2.2, concern whether the focused element is hidden by other content such as sticky headers or overlays.

Removing the browser's default focus outline for styling is acceptable as long as the design looks clean.

Suppressing the default focus indicator without providing a visible replacement can cause a failure of Focus Visible. If default styling is removed, an alternative visible focus indicator should generally be provided.

Best practices

Preserve or replace the default keyboard focus indicator so that a visible indicator is present for every keyboard-operable component; avoid removing focus styling without a visible alternative.

Test the entire interface using only a keyboard to confirm that focus can be seen as it moves through interactive elements, since automated tools detect only a portion of focus-related issues.

Distinguish the requirements when planning conformance: target 2.4.7 Focus Visible (Level AA) for baseline visibility, and consider the WCAG 2.2 criteria 2.4.11 Focus Not Obscured (Minimum, Level AA), 2.4.12 Focus Not Obscured (Enhanced, Level AAA), and 2.4.13 Focus Appearance (Level AAA) for enhanced focus handling.

Verify that focused elements are not hidden behind sticky headers, footers, or overlay content, addressing the separate Focus Not Obscured criteria in addition to Focus Visible.

Include testing with assistive technologies and real users where possible, as passing this success criterion does not by itself guarantee a fully usable experience or legal compliance.

Document which WCAG version and conformance level you are targeting, and consult qualified legal counsel and current agency guidance regarding applicable requirements, as obligations vary by jurisdiction and evolve through regulation and case law.