Skip to main content
Accessibility

Focus Indicator

  • focus
  • keyboard navigation
  • visual design
  • interactive elements
  • usability

When a user presses the Tab key to move through a web page, the browser needs to communicate which element — a link, button, form field, or other interactive control — is currently active and ready to receive input. The focus indicator is the visual cue that accomplishes this. By default, most browsers render a thin dotted or solid outline around the focused element, but these defaults are often removed by CSS resets or overridden by design choices, leaving keyboard users stranded with no way to tell where they are on the page.

Focus indicators are one of the most fundamental requirements for keyboard accessibility. They serve the same purpose as a mouse cursor: without them, sighted keyboard users, people with motor disabilities who rely on switch devices, and anyone temporarily navigating without a pointing device simply cannot use a website effectively.

Why focus indicators matter

Approximately 25% of web users rely on keyboard navigation at least some of the time, whether due to motor impairments, repetitive strain injuries, power-user habits, or assistive technology use. When focus indicators are absent or too subtle, these users face several problems:

  • Lost orientation. Users cannot tell which element will be activated when they press Enter or Space.
  • Increased cognitive load. Without clear visual feedback, users must guess where focus has moved, leading to frustration and errors.
  • Failed compliance. WCAG Success Criterion 2.4.7 (Level AA) requires that any keyboard-operable interface has a mode of operation where the focus indicator is visible. WCAG 2.2 adds SC 2.4.11 (Level AA) requiring a minimum focus appearance area, and SC 2.4.13 (Level AAA) requiring enhanced focus visibility. SC 1.4.11 (Level AA) requires the focus indicator itself to have at least a 3:1 contrast ratio against adjacent colors.

Removing or hiding focus indicators doesn’t just hurt accessibility — it also degrades usability for everyone.

How focus indicators work

Browser defaults

Every major browser ships with a default focus style. Chrome and Edge use a blue or black outline, Firefox uses a dotted border, and Safari uses a blue glow. These defaults satisfy basic visibility requirements, but they may not meet contrast requirements on every background color.

CSS :focus and :focus-visible

The :focus pseudo-class applies styles whenever an element receives focus, regardless of the input method. The :focus-visible pseudo-class applies styles only when the browser determines the user is navigating via the keyboard (or another non-pointer method). This lets designers suppress outlines on mouse clicks while preserving them for keyboard users — the best of both worlds.

Minimum area and contrast

WCAG 2.2 SC 2.4.11 specifies that the focus indicator should have an area at least as large as a 2px solid perimeter around the focused element, and the indicator must have at least a 3:1 contrast ratio between its focused and unfocused states. This means a faint 1px dotted gray line on a white background will typically fail.

Focus within custom components

Custom widgets built with <div> or <span> elements require tabindex="0" to be focusable and need explicit focus styles since they don’t inherit browser defaults for interactive elements. ARIA roles can convey the widget’s purpose, but the visible focus indicator remains a purely visual CSS responsibility.

Code examples

Bad example — focus indicator removed

A common anti-pattern is using a global CSS reset that strips all outlines:

/* Bad: removes focus indicators site-wide */
*:focus {
  outline: none;
}
<a href="/products">Products</a>
<button type="submit">Submit</button>

With this CSS in place, keyboard users see no indication of which element is focused.

Bad example — low-contrast focus indicator

/* Bad: light gray outline on white background fails 3:1 contrast */
a:focus {
  outline: 2px solid #cccccc;
}

Good example — visible focus with :focus-visible

/* Good: high-contrast focus ring shown only for keyboard navigation */
a:focus-visible,
button:focus-visible {
  outline: 3px solid #0054b8;
  outline-offset: 2px;
}

/* Optional: suppress outline for mouse clicks */
a:focus:not(:focus-visible),
button:focus:not(:focus-visible) {
  outline: none;
}
<nav>
  <a href="/products">Products</a>
  <a href="/about">About</a>
</nav>
<button type="submit">Submit</button>

When a keyboard user tabs to any of these elements, a clearly visible 3px blue outline appears with a comfortable offset, easily meeting the 3:1 contrast requirement against a white background.

Good example — custom component with focus indicator

<div
  role="button"
  tabindex="0"
  class="custom-btn"
  aria-label="Toggle menu">
  ☰ Menu
</div>
.custom-btn:focus-visible {
  outline: 3px solid #0054b8;
  outline-offset: 2px;
  border-radius: 4px;
}

Here the custom <div> is made focusable with tabindex="0", given a semantic role and an accessible name with aria-label, and styled with a high-contrast focus indicator that meets WCAG requirements.

Good example — enhanced focus appearance (Level AAA)

For sites targeting SC 2.4.13, a double-ring technique provides maximum visibility:

button:focus-visible {
  outline: 3px solid #0054b8;
  outline-offset: 2px;
  box-shadow: 0 0 0 6px rgba(0, 84, 184, 0.3);
}

This creates a solid inner ring surrounded by a softer outer glow, ensuring the focus indicator is unmistakable on virtually any background.

Focus indicators are a small CSS investment with an outsized impact on usability. The golden rule: never remove outline on :focus unless you replace it with an equally visible — or better — alternative.

Help us improve this glossary term

Was this guide helpful?

Scan your site

Rocket Validator scans thousands of pages in seconds, detecting accessibility and HTML issues across your entire site.

🌍 Trusted by teams worldwide

Validate at scale.
Ship accessible websites, faster.

Automated HTML & accessibility validation for large sites. Check thousands of pages against WCAG guidelines and W3C standards in minutes, not days.

Scheduled Reports
API Access
Open Source Standards
$7 / 7 days

Pro Trial

Full Pro access. Cancel anytime.

Start Pro Trial →

Join teams across 40+ countries