How to Visualize and Fix Keyboard Focus Order (2026)
Keyboard navigation is how many people experience the web — users with motor disabilities, power users who prefer the keyboard, screen reader users, and anyone with a broken mouse. If your page has an illogical tab order, these users cannot efficiently navigate your interface. WCAG 2.4.3 requires that focus order be meaningful and operable.
- Visualize tab order in your HTML to improve keyboard accessibility.
- What Is Focus Order?.
- Which Elements Are Focusable?.
- Covers using tabindex correctly.
- Covers common focus order problems.
What Is Focus Order?
Focus order is the sequence in which interactive elements receive keyboard focus when you press Tab. By default, focus follows the DOM (Document Object Model) order — elements higher in your HTML source code receive focus first.
A logical focus order follows the visual reading order of the page. If your page reads top-to-bottom, left-to-right, the tab order should mirror that flow. Users expect Tab to move forward through the page in a predictable pattern.
When focus order does not match visual order, keyboard users get disoriented. Imagine pressing Tab and having focus jump from the header to the footer, then back to the middle of the page. This is the equivalent of randomly shuffling paragraphs for visual users.
Which Elements Are Focusable?
Natively focusable elements: links (a with href), buttons, form inputs (input, select, textarea), and iframes. These receive focus in DOM order without any additional attributes.
-webkit-backdrop-filter alongside backdrop-filter for Safari support. Without the prefix, the effect is invisible to roughly 25% of mobile users.Custom focusable elements: any element with tabindex="0" joins the natural tab order. Use this for custom interactive components like dropdown menus, tabs, accordions, and modals. The element receives focus in its DOM position.
Programmatically focusable: tabindex="-1" makes an element focusable via JavaScript (element.focus()) but removes it from the Tab sequence. Use this for elements that should receive focus programmatically (like an error message after form submission) but should not be in the normal tab flow.
Using tabindex Correctly
tabindex="0": join the natural tab order. Use this for custom interactive elements that need keyboard access. The element receives focus in its DOM position.
backdrop-filter inside a position: fixed element can cause severe scroll performance issues. Test thoroughly on real iOS devices.tabindex="-1": remove from tab order but allow programmatic focus. Use for elements that should receive focus via JavaScript but not via Tab key (skip links targets, modal content, error messages).
tabindex="1" or higher: avoid these. Positive tabindex values create a separate focus sequence that runs before the natural order, then the natural order resumes. This is almost always confusing and creates maintenance nightmares. If you need to reorder focus, reorder the DOM instead.
Common Focus Order Problems
CSS visual reordering: flexbox order property, CSS Grid placement, and absolute positioning change where elements appear visually but do not change the DOM order. The tab order follows the DOM, creating a mismatch between visual position and focus sequence.
Hidden content receiving focus: off-screen menus, collapsed accordions, and hidden modals can contain focusable elements that receive Tab focus even though they are not visible. Use visibility: hidden or inert attribute to prevent focus on hidden content.
Focus trapping: modals should trap focus within them (Tab cycles through modal elements only). Without focus trapping, Tab moves behind the modal to page elements the user cannot see. Conversely, poorly implemented focus traps can prevent users from closing the modal.
Missing focus indicators: browsers show a default focus ring (outline) on focused elements. Removing it with outline: none without providing a custom alternative makes it impossible for keyboard users to see where focus is. Always replace, never remove.