F44: When Tab Order Betrays the Page

For most users, tabbing through a webpage feels unremarkable — focus moves forward, the page makes sense, nothing surprises. For keyboard-only users and screen reader users, that orderly progression isn't a convenience. It's the entire interface. When tabindex values are assigned carelessly, those users navigate a page that contradicts itself: a list that reads top-to-bottom but tabs bottom-to-top, a form with a field that appears in the middle but behaves like it's at the end.

This is what WCAG 2.2 Failure F44 (opens in new window) documents — and it's one of the more instructive failures in the catalog, because it describes a problem that often starts with good intentions and degrades through neglect.

The Failure

F44 (opens in new window) describes a specific pattern: focusable elements are assigned tabindex values that produce a tab order inconsistent with the logical sequence of the content. The result is a page that fails Success Criterion 2.4.3 Focus Order (opens in new window), which requires that focus move through a page in an order that preserves meaning and operability.

The W3C's own example is stark:

<!-- FAILURE: tabindex creates a tab order that contradicts content order -->
<ol>
  <li><a href="main.html" tabindex="1">Homepage</a></li>
  <li><a href="chapter1.html" tabindex="4">Chapter 1</a></li>
  <li><a href="chapter2.html" tabindex="3">Chapter 2</a></li>
  <li><a href="chapter3.html" tabindex="2">Chapter 3</a></li>
</ol>

Visually, the list reads: Homepage → Chapter 1 → Chapter 2 → Chapter 3. Tab through it, and focus moves: Homepage → Chapter 3 → Chapter 2 → Chapter 1. The DOM order and the interaction order are in direct conflict.

The second scenario the document describes is arguably more common in production environments: a developer adds a new form field in the middle of a page, but forgets to assign it a tabindex. The new field inherits browser-default behavior and lands at the end of the tab sequence — after fields that appear below it in the visual layout. The form looks complete; the tab order tells a different story.

Why This Matters

Keyboard users — including people with motor disabilities who cannot use a mouse, power wheelchair users operating a sip-and-puff device, and screen reader users navigating sequentially — depend on focus order to build a mental model of the page. When that order contradicts the visual or semantic structure, several things break:

Comprehension collapses. A screen reader user tabbing through the navigation example above hears "Homepage," then "Chapter 3," then "Chapter 2." The page communicates a sequence that doesn't exist. The user either assumes the content is structured differently than it is, or spends cognitive effort reconstructing what the actual order should be.

Form completion fails. In the second example, a user filling out a form tabs past what appears to be the next logical field — because that field isn't in the tab sequence where it should be. They may miss required inputs entirely, or submit incomplete data, without understanding why.

Trust erodes. Repeated mismatches between what a page looks like and how it behaves teach keyboard users that this site cannot be trusted to work predictably. That's not a UX problem. That's an access problem.

The populations most affected — people with motor disabilities, blind users, users with cognitive disabilities who rely on consistent patterns — are the same populations who have the fewest alternatives when a digital interface fails them.

The Fix

The cleanest solution is to stop using positive tabindex values altogether. The HTML specification and the ARIA Authoring Practices Guide (opens in new window) both recommend relying on DOM order to control focus sequence. When your HTML is structured logically, the browser's native tab order follows that structure without any tabindex manipulation.

<!-- CORRECT: No positive tabindex. DOM order defines tab order. -->
<ol>
  <li><a href="main.html">Homepage</a></li>
  <li><a href="chapter1.html">Chapter 1</a></li>
  <li><a href="chapter2.html">Chapter 2</a></li>
  <li><a href="chapter3.html">Chapter 3</a></li>
</ol>

For the form field scenario, the fix is structural: insert the new field in the correct position in the DOM, not at the end with a compensating tabindex.

<!-- CORRECT: New field inserted in logical DOM position -->
<form>
  <label for="name">Name</label>
  <input id="name" type="text">
  <!-- New field added here, in correct DOM sequence -->
  <label for="email">Email</label>
  <input id="email" type="email">
  <label for="message">Message</label>
  <textarea id="message"></textarea>
</form>

The legitimate uses of tabindex are narrow: tabindex="0" makes a non-interactive element focusable (necessary for custom widgets); tabindex="-1" removes an element from the tab sequence while keeping it programmatically focusable (useful for modal management). Positive tabindex values — tabindex="1", tabindex="4" — are almost always a sign that the DOM order needs to be fixed, not patched.

Applying This

This failure has a specific detection profile that teams should understand before assuming their tooling will catch it.

Automated testing has real limits here. Tools can flag the presence of positive tabindex values, but they cannot reliably determine whether the resulting tab order preserves meaning — that requires understanding the page's content and intent. Our research on testing methodology documents this gap directly: automated tools catch a fraction of the accessibility failures that manual review surfaces. F44 is a textbook example of a failure that needs human judgment to fully evaluate.

In code review, flag any positive tabindex value as requiring justification. There are almost no valid use cases. If a developer submits a PR with tabindex="2" or tabindex="5", the question isn't "does this work visually?" — it's "why isn't the DOM order correct?"

Keyboard testing is non-negotiable. Tab through every interactive page in your product. Does focus move in an order that matches the logical reading sequence? Does it match what a sighted user would expect? If not, trace back to the DOM structure before reaching for tabindex.

Content management systems are a particular risk. The W3C explicitly notes that editing a page is one of the most common causes of this failure — tabindex values get set, content gets reorganized, and no one updates the attributes. If your CMS allows authors to set tabindex values, that's a governance problem worth addressing at the template level.

For teams navigating multiple compliance frameworks simultaneously, it's worth noting that focus order requirements appear across WCAG 2.1, WCAG 2.2, and Section 508 — the standards fragmentation problem doesn't change the underlying obligation here, but it does mean this failure can appear in audits under different labels.

CORS Perspective

From a community lens, F44 represents something worth naming clearly: the people most harmed by broken tab order are often the people with the fewest workarounds. A sighted mouse user never encounters this failure. A keyboard user with a motor disability encounters it on every tab press after the sequence breaks — and has no alternative path through the interface. Operationally, the fix is genuinely low-cost: restructure the DOM, remove the positive tabindex values, test with a keyboard. The challenge is cultural, not technical. Teams that treat tabindex as a styling tool — something to adjust until the interface looks right — will keep producing this failure. The cautiously optimistic read is that this is exactly the kind of failure that code review policies and linting rules can catch before it ships. The technical barrier to fixing F44 is low. The will to prioritize keyboard users in the development process is what actually determines whether it gets fixed.