Skip to main content

Accessibility issue guide · keyboard focus

Make keyboard focus impossible to lose.

Every keyboard-operable control needs a visible focus indicator. ClearSite can find related machine-detectable barriers, but a person must press Tab and confirm the indicator remains visible through the whole task.

Scan the page first No signup. Then complete the Tab-key check.

Visibility, order and operation

A visible ring proves only one part of keyboard access.

WCAG 2.2 Focus Visible requires a visible mode of operation when a keyboard-operable interface has focus. Focus Order is a separate requirement: the sequence must preserve meaning and operation. Keyboard access is broader again: the control must actually work without a pointer.

A strong CSS indicator can repair a hidden state. It cannot prove that a modal returns focus correctly, a menu follows an understandable sequence or a checkout can be completed by keyboard.

Primary guidance: W3C's explanations of Focus Visible, Focus Order and Keyboard.

Controlled browser fixture · Chromium + axe-core 4.11

The scan stayed clean. The Tab key exposed the barrier.

We tested the same “Pay now” button twice. With its focus outline suppressed, axe-core returned zero violations and Chromium moved focus to the button with no rendered outline. With the repair, axe still returned zero violations while Chromium reported a solid 3px outline with a 3px offset.

Before · hidden keyboard focus

A clean automated result did not mean usable focus.

button:focus {
  outline: none;
  box-shadow: none;
}

Observed: button focused; outline style none; zero axe violations.

After · visible keyboard focus

The source now draws an obvious indicator.

button:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 3px;
}

Observed: solid 3px blue outline; 3px offset; zero axe violations.

This is a controlled fixture, not customer evidence or a conformance claim. It demonstrates why focus visibility needs a browser-and-keyboard check alongside automation. See W3C's :focus-visible technique.

Four repair patterns

Make the indicator resilient, not merely present.

Start with the browser indicator

Do not remove the default outline unless the replacement is already present and at least as easy to see.

button:focus {
  /* Do not set outline: none here */
}

Use :focus-visible for keyboard focus

Keep a strong indicator for keyboard-like interaction without forcing the same treatment after every pointer click.

button:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 3px;
}

Survive mixed backgrounds

A two-colour indicator can stay distinct when the component moves between light, dark or image-backed sections.

a:focus-visible {
  outline: 2px solid #fff;
  box-shadow: 0 0 0 4px #005fcc;
}

Do not hide focused content

Sticky headers, cookie banners and clipped containers must not fully cover the item that currently has focus.

*:focus-visible {
  scroll-margin-block: 5rem;
}

For an indicator that must work across uncertain component backgrounds, compare W3C's two-colour focus-indicator technique.

From scan to keyboard proof

Test the journey, not just one button.

  1. 01

    Put the pointer aside

    Load the page at the start, then use Tab and Shift+Tab. A mouse-only check does not exercise keyboard focus.

  2. 02

    Follow every interactive control

    Move through navigation, forms, dialogs, menus, carousels and the primary task. Confirm focus does not disappear or become trapped.

  3. 03

    Inspect the first hidden state

    Use browser developer tools to find the rule suppressing the outline or the component covering the focused element.

  4. 04

    Repair the shared component

    Add the indicator to the button, link, form-control or design-system source rather than patching one page.

  5. 05

    Re-run both checks

    Repeat the keyboard journey, then scan again for related machine-detectable issues. Passing one does not replace the other.

What a scan can narrow

Related machine-detectable keyboard barriers, such as focusable content hidden from assistive technology or scrollable regions without keyboard access.

What source inspection can prove

Whether the focused element receives the intended computed outline or other visible styling after the shared CSS changes.

What still needs a person

Whether focus stays visible, follows a meaningful order, avoids traps and supports the complete task with a keyboard.

Browse the website accessibility issue library, compare the heading-order guide and form-label repair guide, or read the full automated testing workflow and limits.

Scan first. Then finish the journey with Tab.

Use automation to narrow the queue, repair the source and manually prove visible focus from start to finish.

Run the free scan