UX Patterns Guide
UI + UX Cross-Device And Physical Interaction standard

Focus traversal

Design focus traversal as a tested interaction path with logical source order, visible focus, clear entry and exit points, predictable Tab and Shift+Tab movement, focus placement after navigation and validation, correct overlay containment, keyboard trap escape, hidden-content removal, and stable recovery after dynamic changes.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A workflow has multiple focusable elements, dynamic content, or overlays that users traverse with keyboard or assistive technology.
  • The product needs predictable entry, exit, and return points after state changes.
  • Sequential navigation affects meaning, task completion, validation, or recovery.

Avoid when

  • The concern is a single command accelerator rather than focus movement.
  • The concern is only bypassing repeated navigation with one jump link.
  • A specific composite widget pattern already defines the internal arrow-key focus model.
  • The surface has no interactive or programmatically focused elements.

Problem it prevents

Users who navigate by keyboard, switch, screen reader, or other sequential focus methods can lose their place when focus order disagrees with reading order, focus indicators are hidden, overlays leave hidden controls in the tab sequence, constrained regions create a keyboard trap, or state changes remove the focused element without a recovery target.

Test the behavior

Open the interactive example when you need it

The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch Focus traversal in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

The page or workflow has links, buttons, form fields, overlays, disclosures, inline validation, repeated navigation, virtualized content, or responsive reflow.

Pattern promise

Design focus traversal as a tested interaction path with logical source order, visible focus, clear entry and exit points, predictable Tab and Shift+Tab movement, focus placement after navigation and validation, correct overlay containment, keyboard trap escape, hidden-content removal, and stable recovery after dynamic changes.

Required state

Initial page focus state after route change or page load.

Recovery path

Focus order jumps across columns, sidebars, footers, and hidden panels in a way that breaks task meaning.

Access contract

Ensure focus order preserves meaning and operability when users navigate sequentially.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A checkout form focuses the page heading after route change, tabs through Contact, Delivery, Payment, Review, and Submit in the same order users read the page, then returns focus to the changed section after editing.
  • A filter drawer moves focus to its heading when opened, traps focus only while modal, removes hidden drawer controls when closed, and returns focus to the Filter button.
  • A keyboard user presses Tab from the skip link to the H1, through visible form controls in reading order, into an opened help popover, then back to the invoker after Escape.
  • A user opens a modal, cycles within it using Tab and Shift+Tab, closes with Escape, and focus returns to the button that opened it.
Weak implementation

Vague, hidden, hard to recover from

  • A two-column form tabs from first name to ZIP code to back link because CSS grid order and DOM order disagree.
  • A hidden menu and collapsed accordion panel still receive focus.
  • A keyboard user tabs into an offscreen drawer and cannot see or escape the focused control.
  • A screen reader user follows an error link, but focus stays on the summary while the visual page scrolls to the field.
UI guidance
  • Render a visible focus path that follows source order and task meaning: skip link, global controls, page heading or first task control, local controls, form fields, inline help, error links, overlays, and next task actions.
  • Show focus indicators, focus-origin context, active step, disabled reasons, hidden-section state, and return targets instead of relying on invisible DOM order or positive tabindex patches.
UX guidance
  • Use focus traversal design when users must move through a page or workflow with Tab and Shift+Tab and understand where focus will go next, where it came from, and how to recover after state changes.
  • Define initial focus, next and previous focus targets, focus return after close or submit, error focus, hidden-content removal, virtualized-content recovery, and modal or composite widget boundaries before implementation.
Implementation contract

What the implementation must handle

States

  • Initial page focus state after route change or page load.
  • Skip link or bypass entry state where repeated blocks are present.
  • Normal forward Tab order state.
  • Reverse Shift+Tab order state.

Interaction

  • The sequential focus path follows DOM and reading order unless a well-tested component-specific model declares a different internal focus contract.
  • Every focusable element is visible, operable, named, and relevant at the moment it receives focus.
  • Tab moves forward to the next logical focus target, and Shift+Tab moves backward without losing focus or entering hidden content.
  • Focus indicators remain visible and meet the visual design's contrast and spacing expectations.

Accessibility

  • Ensure focus order preserves meaning and operability when users navigate sequentially.
  • Keep a visible focus indicator for every keyboard-operable control.
  • Avoid keyboard traps; when focus is intentionally constrained, document and support a keyboard exit.
  • Keep hidden and inert content out of the tab sequence and accessibility tree.

Review

  • What is the first focus target after page load, route change, failed submit, and successful submit?
  • Does forward and reverse Tab order match the user's reading and task order?
  • Which elements are hidden, collapsed, disabled, inert, virtualized, or offscreen, and can any still receive focus?
  • Where does focus go after opening and closing each overlay or disclosure?
Evidence trail

Source-backed claims behind this guidance

Full agent/debug reference

Problem Context

  • The page or workflow has links, buttons, form fields, overlays, disclosures, inline validation, repeated navigation, virtualized content, or responsive reflow.
  • Users move sequentially with Tab, Shift+Tab, screen reader next control commands, switch scanning, hardware keyboards, remote controls, or assistive devices.
  • Opening, closing, submitting, filtering, sorting, expanding, collapsing, routing, or virtualizing content can change which elements exist and where focus should land.
  • The product may also include composite widgets that use roving focus, modal surfaces that contain focus, skip links that bypass blocks, and shortcuts that execute commands.

Selection Rules

  • Choose focus traversal when the design problem is the user's sequential path through focusable elements and dynamic state changes.
  • Use keyboard shortcut when the goal is accelerating one command with a key chord rather than moving focus through the interface.
  • Use skip link when the primary issue is bypassing repeated content before main content or another large repeated block.
  • Use modal dialog when focus should be contained temporarily inside a modal surface and background content should be inert.
  • Use toolbar, menu menubar, listbox, tabs, data grid, or tree grid when a composite widget owns arrow-key or roving-focus behavior inside one logical control.
  • Use in-page anchor navigation when users need visible section jumps, active section state, and URL fragments, not the complete page focus sequence.
  • Preserve DOM order, reading order, visual order, and Tab order alignment wherever possible.
  • Avoid positive tabindex values except for exceptional controlled cases; prefer native order, tabindex 0 for deliberate custom controls, and tabindex -1 for programmatic focus targets.
  • Move focus only when users initiate a navigation, open or close a surface, submit a form, follow an error link, or need confirmation of a meaningful state change.
  • Never leave focus on hidden, removed, disabled, offscreen, inert, or unrelated content.

Required States

  • Initial page focus state after route change or page load.
  • Skip link or bypass entry state where repeated blocks are present.
  • Normal forward Tab order state.
  • Reverse Shift+Tab order state.
  • Visible focus indicator state on every interactive control.
  • Hidden, collapsed, disabled, or inert content removed from sequential focus state.
  • Programmatic focus target state such as heading, status message, or validation summary.
  • Overlay opened state with first focus target and background policy.
  • Overlay closed state with focus return to invoker or next logical task.
  • Validation error state with summary focus and field-link focus movement.
  • Dynamic list update state when focused content is removed, filtered, sorted, or virtualized.
  • Responsive layout state where visual and DOM order remain coherent.
  • Composite widget boundary state where Tab enters and exits while arrows move inside.
  • Keyboard trap escape state for embedded or constrained focus regions.

Interaction Contract

  • The sequential focus path follows DOM and reading order unless a well-tested component-specific model declares a different internal focus contract.
  • Every focusable element is visible, operable, named, and relevant at the moment it receives focus.
  • Tab moves forward to the next logical focus target, and Shift+Tab moves backward without losing focus or entering hidden content.
  • Focus indicators remain visible and meet the visual design's contrast and spacing expectations.
  • Opening a modal, drawer, popover, disclosure, or menu places focus deliberately and defines whether focus is contained, adjacent, or returned to the invoker.
  • Closing a surface returns focus to the invoker when it remains available or to the next logical task target when the invoker no longer exists.
  • Submitting with errors moves focus to the error summary or first invalid field and error links move focus to the matching control.
  • When dynamic content removes the focused item, focus moves to a status message, replacement item, next available result, or stable container with a clear path forward.

Implementation Checklist

  • Map the focus path for load, Tab, Shift+Tab, open, close, submit, validation, route change, filter, sort, pagination, virtualization, and responsive layouts.
  • Keep DOM order aligned with reading and visual order; fix source order before adding tabindex.
  • Use native interactive controls first and add tabindex 0 only to custom controls that are genuinely operable by keyboard.
  • Use tabindex -1 for programmatic focus targets such as headings, status containers, and validation summaries that should not be in normal Tab order.
  • Remove hidden, collapsed, inert, disabled decorative, or offscreen controls from the sequential focus path.
  • Define focus placement and return for dialogs, drawers, sheets, popovers, menus, accordions, route transitions, and async updates.
  • Expose visible focus styles for all interactive controls and verify they are not clipped, covered, or color-only.
  • Test with keyboard only, Shift+Tab, screen readers, switch control, browser zoom, mobile hardware keyboards, responsive breakpoints, virtualization, and JavaScript failure paths.

Common Generated-UI Mistakes

  • Using positive tabindex values to force a visual order instead of fixing DOM order.
  • Suppressing outline or focus ring without an equivalent visible indicator.
  • Leaving hidden drawers, collapsed panels, or inactive tabs in the tab sequence.
  • Moving focus unexpectedly on hover, scroll, animation, autosave, polling, or non-user-initiated updates.
  • Closing overlays without returning focus to the invoker or a meaningful replacement.
  • Scrolling visually to content while keyboard focus remains elsewhere.
  • Placing noninteractive text, cards, status tags, or decorative wrappers in Tab order.
  • Letting virtualized or filtered content remove the focused item without a recovery target.

Critique Questions

  • What is the first focus target after page load, route change, failed submit, and successful submit?
  • Does forward and reverse Tab order match the user's reading and task order?
  • Which elements are hidden, collapsed, disabled, inert, virtualized, or offscreen, and can any still receive focus?
  • Where does focus go after opening and closing each overlay or disclosure?
  • How do error summaries, inline errors, async status messages, and removed results move or preserve focus?
  • Are composite widgets using a declared roving-focus model instead of flooding the page tab sequence?
  • Can users always see focus and escape constrained focus regions with the keyboard?
Accessibility
  • Ensure focus order preserves meaning and operability when users navigate sequentially.
  • Keep a visible focus indicator for every keyboard-operable control.
  • Avoid keyboard traps; when focus is intentionally constrained, document and support a keyboard exit.
  • Keep hidden and inert content out of the tab sequence and accessibility tree.
  • Do not use positive tabindex to patch order; align DOM, visual, and reading order instead.
  • Use headings, landmarks, skip links, and programmatic focus targets to support long-page traversal without replacing normal focus order.
  • Preserve focus or move it deliberately after dynamic updates, never to an arbitrary page start.
  • Test forward and reverse traversal with keyboard, screen readers, switch scanning, high zoom, and responsive layouts.
Keyboard Behavior
  • Tab moves to the next visible, operable, logical focus target.
  • Shift+Tab moves to the previous visible, operable, logical focus target.
  • Enter and Space activate focused controls according to their native semantics.
  • Escape closes overlays or constrained regions where that control owns Escape, then returns focus predictably.
  • Arrow keys move inside composite widgets only when that widget declares and implements a composite focus model.
  • Programmatic focus lands on headings, summaries, dialogs, or replacement content only after user-initiated navigation or meaningful state change.
  • Focus is restored to the invoker after close when possible, or to the next logical target when the invoker is gone.
  • No hidden, removed, disabled, or inert element can be reached with Tab or Shift+Tab.
Variants
  • Page focus order
  • Form focus traversal
  • Overlay focus return
  • Validation focus traversal
  • Responsive focus order
  • Virtualized list focus recovery
  • Programmatic heading focus
  • Composite widget focus boundary
  • Reverse focus traversal
  • Keyboard trap escape

Verification

Source trail checked:

Saved items