Understanding Keyboard Focus

Keyboard focus identifies which interactive element is currently ready to receive input from the keyboard.

As visitors navigate a webpage with the keyboard, focus moves between links, buttons, form controls, and other focusable elements. Accessible focus management keeps this movement logical and predictable, provides a clearly visible focus indicator, and moves focus intentionally when an interface changes in a way that requires it.

What Is Keyboard Focus?

Only one element normally has keyboard focus at a time. When an element has focus, keyboard input can interact with that element according to its behavior.

For example, pressing Enter while a link has focus can activate the link, while typing when a text field has focus enters text into that field.

Keyboard users commonly use Tab to move focus forward through interactive elements and Shift+Tab to move backward. The element receiving focus should always be identifiable and its position should make sense within the page.

Focusable HTML Elements

Many native HTML elements are focusable automatically when they are interactive. Using these elements provides expected focus and keyboard behavior without requiring developers to recreate it.

Element Typical Focus Behavior
<a href="..."> Receives focus as a navigational link.
<button> Receives focus as an interactive button.
<input> Receives focus when the control is available for interaction.
<select> Receives focus so an option can be selected.
<textarea> Receives focus for multiline text entry.

Ordinary elements such as <p>, <div>, and <span> are not normally part of the keyboard focus order because they are not interactive controls.

Maintain a Logical Focus Order

Focus should generally move through interactive elements in an order that follows the meaning and organization of the page. Native HTML controls normally follow their document source order.

<label for="name">Name</label>
<input type="text" id="name" name="name">

<label for="email">Email Address</label>
<input type="email" id="email" name="email">

<button type="submit">Send Message</button>

In this example, keyboard focus moves from the Name field to the Email Address field and then to the Send Message button. The sequence matches the visual and logical order of the form.

CSS layouts should not rearrange content in a way that causes the visible order and keyboard focus order to become confusingly different.

Keep Focus Visible

A visible focus indicator shows keyboard users which element currently has focus. Browsers provide default focus styles, and these should not be removed unless they are replaced with another clearly visible indicator.

Avoid removing the outline without providing a replacement:

/* Avoid this */
:focus {
  outline: none;
}

A custom focus indicator can instead reinforce the focused element:

:focus {
  outline: 3px solid currentColor;
  outline-offset: 3px;
}

The indicator should be easy to distinguish from the element's normal appearance and remain visible against the surrounding background.

Using :focus-visible

The CSS :focus-visible pseudo-class allows browsers to apply a focus style when a visible focus indicator is appropriate, particularly during keyboard interaction.

:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 3px;
}

This can provide a strong keyboard focus indicator without necessarily displaying the same indicator for every pointer interaction.

Do not use :focus-visible as a reason to hide focus when a visible indication is needed. The goal is to ensure that visitors who need to see focus can always identify it.

Managing Focus with tabindex

The tabindex attribute can change how an element participates in keyboard focus. The most commonly useful values are 0 and -1.

Value Effect
tabindex="0" Adds an element to the normal keyboard focus order according to its document position.
tabindex="-1" Keeps an element out of the normal Tab sequence while allowing it to receive focus programmatically.
Positive values Create a custom tab order and should generally be avoided.

Do not add tabindex="0" to ordinary text simply to make it keyboard focusable. Focus should normally be reserved for elements visitors can interact with or locations that intentionally need to receive programmatic focus.

Moving Focus Programmatically

JavaScript can move keyboard focus when an interface changes and the visitor needs to continue interacting from a new location. Programmatic focus should be used intentionally rather than moving focus unexpectedly.

<main id="main-content" tabindex="-1">
  <h1>Garden Center</h1>
</main>

An element with tabindex="-1" can receive focus through JavaScript without becoming part of the normal Tab sequence.

document.getElementById('main-content').focus();

Moving focus can be useful after certain interface changes, but unnecessary focus changes can disorient visitors by unexpectedly moving their position on the page.

Focus and Dialogs

Dialogs are a common example of an interface where focus management matters. When a modal dialog opens, keyboard interaction should move into the dialog so the visitor can interact with its contents.

While a modal dialog is open, focus should remain within the active dialog rather than moving into content behind it. The dialog must also provide a keyboard-accessible way to close it.

When the dialog closes, focus should generally return to the control that opened it or another logical location so the visitor does not lose their place.

<button type="button" id="open-dialog">Open Garden Tips</button>

<dialog id="garden-dialog">
  <h2>Garden Tips</h2>
  <p>Water plants early in the morning when possible.</p>
  <button type="button" id="close-dialog">Close</button>
</dialog>

The native <dialog> element provides useful built-in behavior, but the complete interaction should still be tested with the keyboard.

Focus and Dynamic Content

Webpages can change without loading a new document. Forms may display errors, sections may appear or disappear, and JavaScript may replace portions of the interface.

Not every change requires focus to move. If new information appears without changing what the visitor is currently doing, leaving focus in place may provide the most predictable experience.

When an interaction creates a new task or context that requires immediate attention, moving focus to an appropriate location may be helpful. The important principle is that focus changes should support the visitor's next action rather than occur simply because content changed.

Testing Keyboard Focus

Keyboard focus can be tested by navigating through a webpage without using the mouse. Start near the beginning of the page and use Tab and Shift+Tab to move between interactive elements.

Watch the focus indicator as you move through the page. Every focused control should be clearly visible, the sequence should make sense, and focus should not unexpectedly disappear or jump to an unrelated part of the page.

Also test components that change the interface, including dialogs, menus, disclosure widgets, validation messages, and dynamically displayed content. Make sure visitors can understand where focus moved and can continue navigating normally.

Keyboard Focus Example

The following example provides several native interactive elements with a clearly visible focus indicator. It can be tested directly using Tab and Shift+Tab.

<a href="/gardening-guide.html">Gardening Guide</a>

<label for="email">Email Address</label>
<input type="email" id="email" name="email">

<button type="button">Subscribe</button>
Play in Editor

Open the example and use only the keyboard. Watch how focus moves through the link, form field, and button, then experiment with the focus CSS to see how the indicator affects usability.

Best Practices

  • Use native interactive HTML elements so expected focus behavior is available automatically.
  • Keep keyboard focus order logical and consistent with the content structure.
  • Always provide a clearly visible focus indicator.
  • Do not remove browser focus outlines unless an accessible replacement is provided.
  • Use tabindex="0" and tabindex="-1" only when their focus behavior is genuinely needed.
  • Avoid positive tabindex values that create a custom tab sequence.
  • Move focus programmatically only when doing so helps visitors continue the current task.
  • Manage focus carefully when dialogs and other temporary interfaces open and close.
  • Do not move focus automatically for every dynamic content change.
  • Test focus behavior using only the keyboard.

Summary

Keyboard focus tells visitors which interactive element is ready to receive keyboard input. Accessible webpages maintain a logical focus order and provide a clearly visible indication of the currently focused element.

Native HTML provides a strong foundation for focus behavior. Use tabindex carefully, move focus only when there is a meaningful reason, and pay particular attention to dialogs and dynamic interfaces where a visitor's position can otherwise become unclear.