Focus traversal

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?