Skip to main content
Beta: Front-End Checklist is currently in beta. Some issues are still being fixed. Thanks for your patience.

Ensure logical focus order

Tab focus order follows the visual layout and logical reading sequence of the page.

Utilities
Quick take
Typical fix time 20 min
  • Tab order should match visual reading order (left-to-right, top-to-bottom)
  • DOM order determines tab order—arrange HTML to match visual layout
  • Never use positive tabindex values (1, 2, 3)—they break natural flow
  • Use CSS for visual positioning, not DOM reordering
Why it matters: When focus jumps unexpectedly, keyboard users get disoriented and can't find content—mismatched visual and focus order makes navigation impossible.

Rule Details

Focus order must follow the visual layout so keyboard users can navigate predictably.

Code Example

<!-- ❌ Bad: Positive tabindex breaks natural order -->
<button tabindex="3">Third</button>
<button tabindex="1">First</button>
<button tabindex="2">Second</button>
<!-- Focus goes: First → Second → Third (confusing!) -->
 
<!-- ✅ Good: DOM order matches visual order -->
<button>First</button>
<button>Second</button>
<button>Third</button>
<!-- Focus goes: First → Second → Third (predictable) -->

Why It Matters

When focus jumps unexpectedly, keyboard users get disoriented and can't find content—mismatched visual and focus order makes navigation impossible.

Focus Order Principles

PrincipleDescription
Visual matchingTab order follows visual reading order
DOM-basedFocus order comes from DOM position
Logical flowRelated elements group together
No surprisesFocus doesn't jump unexpectedly

CSS Visual Reordering Issues

<!-- ❌ Bad: CSS order doesn't change focus order -->
<style>
  .container { display: flex; }
  .first { order: 3; }
  .second { order: 1; }
  .third { order: 2; }
</style>
 
<div class="container">
  <button class="first">Visually Third</button>
  <button class="second">Visually First</button>
  <button class="third">Visually Second</button>
</div>
<!-- Focus: First → Second → Third (doesn't match visual!) -->
 
<!-- ✅ Good: DOM order matches intended visual order -->
<div class="container">
  <button>First</button>
  <button>Second</button>
  <button>Third</button>
</div>

Tabindex Values

<!-- tabindex="0": Add to tab order in DOM position -->
<div role="button" tabindex="0">Custom button</div>
 
<!-- tabindex="-1": Focusable by script only -->
<div id="modal" tabindex="-1">Focus target for JS</div>
 
<!-- tabindex="1+": NEVER use - breaks natural order -->
<button tabindex="1">Don't do this</button>

Form Field Order

<!-- ❌ Bad: Visual columns, wrong tab order -->
<div class="two-column">
  <div class="left">
    <input name="first">
    <input name="city">
  </div>
  <div class="right">
    <input name="last">
    <input name="state">
  </div>
</div>
<!-- Tab: first → city → last → state (skips between columns) -->
 
<!-- ✅ Good: Single column or proper row grouping -->
<div class="form-row">
  <input name="first">
  <input name="last">
</div>
<div class="form-row">
  <input name="city">
  <input name="state">
</div>
<!-- Tab: first → last → city → state (left-to-right by row) -->

React Layout Example

// ✅ Good: DOM order matches visual order
function Header() {
  return (
    <header>
      <a href="/" className="logo">Logo</a>
      <nav>
        <a href="/products">Products</a>
        <a href="/about">About</a>
        <a href="/contact">Contact</a>
      </nav>
      <button className="menu-toggle">Menu</button>
    </header>
  )
}
 
// CSS positions elements visually
// .logo { order: 1; }
// nav { order: 2; }
// .menu-toggle { order: 3; }

Exceptions

  • Temporary or intentionally inert UI can be removed from the focus order, but only when the same state is also communicated clearly to assistive technology users.
  • A focus-management issue should be evaluated in the rendered interaction, not only from static markup, because route changes, overlays, and JS timing can change the real behavior.
  • If a component is both unlabeled and focus-broken, fix the stronger user-facing orientation problem first rather than reporting multiple secondary symptoms.

Standards

  • Align the implementation with W3C WAI: WCAG Overview and verify the rendered experience, not only the source code.
  • Align the implementation with MDN: Accessibility and verify the rendered experience, not only the source code.

Verification

Automated Checks

  • Use browser accessibility tooling, axe, Lighthouse, or equivalent automated checks against a representative rendered state.

Manual Checks

  • Tab through entire page with keyboard only
  • Verify focus moves in expected visual order
  • Check that focus never jumps unexpectedly
  • Confirm all interactive elements are reachable

Use with AI

Copy these prompts to use with your AI assistant, or install the MCP server to use directly from Claude, Cursor, or Windsurf.

Check

Verify implementation

Tab through the page and verify focus moves in a logical sequence matching visual layout. Check that modals trap focus appropriately, and focus returns to triggering elements when dialogs close.

Fix

Auto-fix issues

Order DOM elements to match visual layout. Avoid positive tabindex values which override natural order. Use tabindex='0' for custom interactive elements and tabindex='-1' for programmatic focus management.

Explain

Learn more

Explain how keyboard users rely on predictable tab order to navigate efficiently, and why mismatched visual and focus order creates confusion and reduces usability for assistive technology users.

Review

Code review

Review the rendered markup and interactive states that affect Ensure logical focus order. Flag exact elements, roles, labels, focus behavior, or keyboard interactions that violate the rule, and note how to verify the fix with browser accessibility tooling or assistive tech.

Sources

References used to support the guidance in this rule.

Further Reading

Tools and supplementary material for exploring the topic in more depth.

axe DevTools
deque.comTool

Rules that often go hand-in-hand with this one.

Enable keyboard navigation for all elements

All interactive elements are accessible via keyboard with logical focus order and hidden elements excluded from tab sequence.

Accessibility
Manage focus during dynamic interactions

Focus is programmatically managed during dynamic interactions like modals, page transitions, and content updates.

Accessibility
Avoid autofocus on form fields

Form fields do not use the autofocus attribute which can disorient screen reader users and cause unexpected page behavior.

Accessibility
Include a skip navigation link

A skip navigation link is provided to allow keyboard users to bypass repetitive content and navigate directly to main content.

Accessibility

Was this rule helpful?

Your feedback helps improve rule quality. This stays internal for now.

Loading feedback...
0 / 385