# How to Check Keyboard Focus Order with a Visual Focus Path

Traditional Chinese version: [https://accesserty.com/ai/guides/how-to-check-keyboard-focus-path.md](https://accesserty.com/ai/guides/how-to-check-keyboard-focus-path.md)

Page version: [https://accesserty.com/en/guides/how-to-check-keyboard-focus-path/](https://accesserty.com/en/guides/how-to-check-keyboard-focus-path/)

Last updated: 2026-10-03

Keyboard focus order affects whether people can move through a page predictably. This guide explains common focus path issues, dialogs, responsive states, and how DevCheck can support manual review.

## Summary

- Keyboard testing is not only checking whether Tab moves. The order also needs to make sense for the page and task.
- Focus order can be affected by DOM order, tabindex, dialogs, expanded content, responsive layouts, and dynamic states.
- A visual Focus Path estimates a route to review. Check it with real keyboard use; it is not an automatic WCAG pass or fail.

## Why focus order deserves its own review

Keyboard focus order is one way to navigate controls. Screen readers also offer reading modes and shortcuts for headings or landmarks, so a Tab walkthrough does not cover every reading path. When focus order differs too much from the task or reading context, a control may be reachable but difficult to understand.

That is why focus order review is more than asking whether every control can receive focus. It also asks whether people can complete the task in a predictable way.

## Focus order is not simply visual order

By default, focus order usually follows DOM order, but tabindex, dynamically inserted content, dialogs, menus, expanded regions, and iframes can all change the path a user experiences.

Responsive layouts can make this more visible. A desktop layout may look reasonable, then wrap or reorder at a mobile width. If the DOM order does not match the task context, the keyboard path can become hard to predict.

```html
<label for="task-name">Name</label>
<input id="task-name" name="name" autocomplete="name">
<label for="task-email">Email</label>
<input id="task-email" name="email" type="email"
  autocomplete="email">
<button type="button">Preview</button>
```

Place this snippet on a test page. From Name, Tab should reach Email and then Preview; Shift + Tab should reverse that order. This demonstrates focus order only, not a working preview action. No positive tabindex is needed. If the order is confusing, review DOM and CSS ordering, then retest at a narrow width.

## Before and after: avoid positive tabindex for a simple form

This deliberately incorrect test snippet is not for production. Name comes before Email in the DOM, but positive tabindex sends keyboard focus to Email first.

- Collapsed content is still reached by Tab: check whether only opacity or aria-hidden changed. Remove genuinely collapsed content from interaction, for example with appropriate hidden usage; aria-hidden alone does not prevent keyboard focus. If focus is inside content about to be hidden, return it to the trigger first.
- Focus is lost after closing a dialog: record its opener and the position before closing. Return focus to the remaining trigger or a sensible location for the next task. Actually open, close and Tab again rather than checking only DOM attributes.

```html
<label for="task-name">Name</label>
<input id="task-name" name="name" tabindex="2">
<label for="task-email">Email</label>
<input id="task-email" name="email" type="email" tabindex="1">
<button type="button">Preview</button>
```

From the start of a standalone test page, Tab gives Email → Name → Preview before the fix. Remove both positive tabindex attributes and use the previous native HTML example: Name → Email → Preview, reversed with Shift+Tab. Not every difference from visual order violates WCAG; the sequence must preserve meaning and operation, not match every screen coordinate.

## Common focus path problems

Some focus issues are not errors that automated tools can reliably decide. They need a person to review the page, task, and interaction state. These cases are usually worth checking.

- An element looks interactive, but it cannot receive keyboard focus.
- Focus jumps far away or outside the current viewport.
- Content that appears earlier visually comes much later in the Tab order.
- A dialog opens, but focus still moves into the background page.
- After closing a dialog, menu, or hint, focus does not return to a reasonable place.
- Hidden, invisible, or non-actionable elements still receive focus.
- Focus loops inside a menu, dialog, or component and the user cannot leave.
- A custom control looks interactive, but keyboard focus cannot reach it or the order is unclear.
- The responsive layout changes visual order, while focus order still follows the old desktop context.

## Where traditional review gets difficult

Pressing Tab repeatedly, watching the browser focus outline, and using bookmarklets that number focusable elements are all useful. But real pages are often long, with focusable elements spread across navigation, main content, sidebars, footers, dialogs, and dynamic regions.

When focus jumps far away or outside the viewport, the current screen or a list of numbers may not explain the whole path. It also becomes harder for a team to discuss whether a segment is reasonable or needs adjustment.

## What a visual Focus Path adds

DevCheck Focus Path collects candidate focusable elements and estimates their order from page structure and tabindex, then draws numbered points, connections and a mini map. It does not record where each actual Tab press takes you. The panel shows the mapped path and current viewport to help locate sections worth reviewing.

A point is not necessarily one Tab stop. A native radio group usually has one Tab entry, with arrow keys selecting within it; tabs and menus also have their own keyboard patterns. The map can inspect open shadow roots, but not content inside frames or closed shadow roots. Walk through the task with Tab, Shift + Tab and the relevant arrow keys, and check frame content separately.

Orange segments mean “review this manually.” They are not confirmed errors and not WCAG failure decisions. Whether the order makes sense still depends on page purpose, layout, interaction state, and user task.

## Recommended review workflow

Focus path review works best in the actual page state. Form errors, authenticated content, expanded regions, dialogs, and responsive breakpoints can all change the order a user experiences.

- Open the page or flow state you need to review, not only the empty initial screen.
- Move through the main task with the keyboard first and notice whether the next position is predictable.
- Turn on Focus Path and review the overall path for large jumps or mismatched order.
- Pay attention to orange review-hint segments and decide whether they are reasonable or need adjustment.
- Test dialogs, menus, expanded content, form errors, and authenticated states.
- After changing viewport width or page state, refresh the path and review again.
- Bring suspicious segments to design, QA, engineering, or content maintainers for discussion.

## Who can run this review

Focus path review is not only for engineers. Designers can compare visual order with operation order; QA can add it to test cases; product managers can review whether key flows feel predictable; frontend engineers can adjust DOM order, focus management, or tabindex; content maintainers can check whether new sections disrupted the path.

The goal is not for everyone to replace accessibility specialists. The goal is to help more people see a potential issue, describe it clearly, and bring it to the right person for repair.

## Next steps

- [How to implement accessible names](<https://accesserty.com/en/guides/how-to-implement-accessible-names/>) — Check whether buttons, links, form controls, and interactive components expose understandable names.

- [How to write meaningful image alt text](<https://accesserty.com/en/guides/writing-meaningful-alt-text/>) — Review alt text based on the image purpose in context, not only what appears visually.

## Related pages

- [Accesserty DevCheck](<https://accesserty.com/en/devcheck/>) — Run browser-based checks on local builds, staging pages, authenticated screens, and interactive states.

- [Keyboard accessibility glossary page](<https://accesserty.com/en/glossary/keyboard-accessibility/>)

- [Focus indicator glossary page](<https://accesserty.com/en/glossary/focus-indicator/>)

- [Keyboard accessibility testing guide](<https://accesserty.com/en/guides/keyboard-accessibility-testing/>)

- [Automated accessibility checks limits guide](<https://accesserty.com/en/guides/automated-accessibility-checks-limits/>)

- [Accessibility testing before launch guide](<https://accesserty.com/en/guides/accessibility-testing-before-launch/>)

- [ARIA patterns guide](<https://accesserty.com/en/guides/aria-patterns-for-developers/>)

- [W3C: Understanding Focus Order](<https://www.w3.org/WAI/WCAG22/Understanding/focus-order.html>)

- [Web accessibility checker](<https://accesserty.com/en/web-accessibility-checker/>) — Check real pages, authenticated states, and interactive states before release.

- [Understand WCAG check results](<https://accesserty.com/en/wcag-compliance-tool/>) — Review WCAG A/AA issue clues, severity, affected elements, and remediation hints.

- [Accessibility practice and maintenance guides](<https://accesserty.com/en/guides/>) — Browse guides by practical task: public signals, pre-release checks, post-launch maintenance, and standards limits.