Focus order bugs: small issue, big user impact

Focus order is one of those defects that's invisible in a screenshot and obvious the moment you press Tab. It rarely throws an error, rarely fails an automated scan, and almost never shows up unless someone tests the way affected users actually work. That combination — low visibility, high impact — is exactly why it survives to production so often.

What focus order actually is

When a keyboard user presses Tab, focus moves from one interactive element to the next in a defined sequence. By default that sequence follows the DOM order — the order elements appear in the HTML, not the order they appear on screen. Most of the time those match. The bugs happen when they don't.

The test is the simplest one in accessibility: put the mouse down, press Tab repeatedly from the top of the page, and watch where the focus ring goes. If the path is logical — top to bottom, left to right, matching the visual reading order — you're fine. If it jumps around, you have a focus order bug. This is the natural next step after a basic keyboard pass.

The four bugs you'll actually find

Visual order doesn't match DOM order. CSS — flex-direction: row-reverse, order, absolute positioning, grid placement — moved things on screen without moving them in the HTML. A user sees a form laid out top-to-bottom but tabs through it in a scrambled sequence. The fix is to reorder the DOM, not patch it with tabindex.

Positive tabindex. Someone wrote tabindex="3" to "fix" an order. Positive tabindex values hijack the entire tab sequence — every positive-tabindex element jumps to the front, ahead of everything natural, in numeric order. It almost always creates a worse problem than it solved. The only values you want are 0 (in natural order) and -1 (focusable by script, not by Tab).

Focus trapped or lost. Open a modal and focus stays on the page behind it; or close the modal and focus vanishes to the top of the document instead of returning to the button that opened it. Keyboard users lose their place entirely. A modal should trap focus inside itself while open and return it on close.

Hidden things still in the tab order. An off-screen menu, a display-toggled drawer, or a visibility:hidden element that's still focusable. The user tabs into empty space — the focus ring disappears off-screen and they're stuck pressing Tab with nothing visibly happening.

Focus order test pass

• Tab from the top of the page; confirm the path matches the visual reading order
• Watch for the focus ring jumping backward or skipping regions
• Grep the codebase / inspect for any positive tabindex (greater than 0) — flag every one
• Open each modal/dropdown: focus moves into it, is trapped while open, returns on close
• Tab through hidden/collapsed UI — confirm nothing off-screen is still focusable
• Confirm every focused element has a visible focus indicator (no outline: none without a replacement)

Why it matters more than it looks

A scrambled tab order doesn't just annoy — it disorients. A sighted keyboard user (RSI, motor impairment, power user) loses the thread of the page; a screen reader user, who experiences the page largely as its focus and reading order, can be left unable to understand or complete the flow. And because the page renders perfectly and usually passes an automated axe scan — focus order is mostly not machine-detectable — it sails through every check except the one that matters. This is the same blind spot behind the dropdown nobody noticed with a mouse: the visual layer was complete and the interaction layer was broken.

The good news is that the test costs nothing. Tab through the page before every release on anything with a form, a modal, or a custom layout. The bug that's invisible to your eyes is the first thing a keyboard user hits.