Press Tab on your homepage right now. Watch where the focus indicator goes. Does it move through your navigation links in order? Does it hit the search bar before the footer? Does it skip your call-to-action button entirely because someone set tabindex="-1" on it three redesigns ago?
If you've never done this, you're not alone. Most site owners test with a mouse and call it done. But roughly 8% of web users navigate primarily or exclusively by keyboard, including people with motor disabilities, power users who prefer keyboard shortcuts, and anyone whose trackpad just died on a Tuesday afternoon. When your tab order is broken, these visitors don't file a complaint. They leave.
What makes a tab order "broken"
WCAG 2.1 Success Criterion 2.4.3 (Focus Order) requires that when content can be navigated sequentially, the focus order must preserve meaning and operability. In plain terms: if a sighted user would read items left-to-right and top-to-bottom, the tab order should follow the same flow.
The most common violations aren't dramatic. They're small layout decisions that compound. A CSS grid that visually reorders columns without changing the DOM order. A modal that opens but doesn't trap focus, so pressing Tab sends you behind the overlay into content you can't see. A form where the submit button comes before the last input field in the DOM because a developer moved it with position: absolute. A positive tabindex value (like tabindex="5") that yanks an element to the front of the tab queue, ahead of everything else on the page.
Each of these creates a moment where a keyboard user loses their place. One or two might be tolerable. A page with five or six focus-order problems becomes unusable without a mouse.
The legal and practical stakes
WCAG 2.4.3 is a Level A criterion, the lowest bar in the accessibility standard. It's not aspirational. It's baseline. Under the ADA, courts have consistently held that websites qualify as places of public accommodation, and DOJ guidance explicitly references WCAG 2.1 AA as the standard. The European Accessibility Act (EAA), which takes effect in June 2025, makes WCAG AA compliance a legal requirement for most commercial websites serving EU customers.
Beyond compliance, broken tab order correlates with broken screen reader experiences. Screen readers follow the DOM order, not the visual order. If your DOM order doesn't match your visual layout, both keyboard users and screen reader users get a scrambled experience.
What the Tab Order Audit checks
The Tab Order Audit walks through every focusable element on your page in DOM order and flags three categories of problems.
First, it identifies positive tabindex values. Any element with tabindex="1" or higher gets pulled to the front of the tab sequence regardless of its position in the DOM. This almost always creates confusion. The fix is simple: remove the positive tabindex and let the DOM order do the work, or restructure the DOM so the element appears where it should in the natural flow.
Second, it detects elements that are visually interactive but not keyboard-reachable. A <div> with an onclick handler but no tabindex="0" and no role="button" is invisible to keyboard navigation. The audit flags these so you can either add the appropriate ARIA role and tabindex or replace the div with a native <button>.
Third, it checks for focus traps in modals and overlays. When a modal opens, focus should move into it and cycle within it until the user closes it. If focus escapes the modal and lands on background content, or if there's no way to close the modal with the keyboard at all, the audit reports it.
The results pair well with the WCAG Accessibility Audit for a comprehensive compliance check, and the Form Accessibility Audit for input-specific focus issues.
How to fix the common problems
For positive tabindex values, the fix is almost always deletion. Remove tabindex="5" and let the element sit in its natural DOM position. If that position is wrong, move the element in the HTML rather than forcing it forward with tabindex.
For non-focusable interactive elements, replace <div onclick="doThing()"> with <button type="button">. Native buttons are focusable, have built-in Enter and Space key handling, and announce correctly to screen readers without additional ARIA. If you must use a div (rare), add tabindex="0", role="button", and a keydown handler for Enter and Space.
For focus traps, add a keydown listener on the modal container that catches Tab and Shift+Tab, cycling focus between the first and last focusable element inside the modal. When the modal closes, return focus to the element that triggered it. The <dialog> element handles most of this natively if your browser support allows it.
If you're building a site from scratch, The $97 Launch walks through accessible markup patterns that avoid these problems from the start, so you're not retrofitting tab order after the fact.
Fact-check notes and sources
- WCAG 2.1 SC 2.4.3 Focus Order: W3C Web Content Accessibility Guidelines 2.1, Level A.
- Keyboard-only usage statistics: WebAIM's 2024 Screen Reader User Survey reports 8.1% of respondents use keyboard-only navigation without a screen reader.
- ADA website accessibility: DOJ published guidance in March 2022 confirming that the ADA applies to web content of state and local governments, and rulemaking for Title II was finalized in April 2024 referencing WCAG 2.1 AA.
- European Accessibility Act (EAA): Directive (EU) 2019/882, enforcement begins June 28, 2025.
Related reading
- Why the WCAG audit matters — contrast is the other half of visual accessibility
- Form accessibility patterns — focus order inside complex forms
- Table accessibility done right — another frequently broken keyboard interaction
- Image alt text auditing — the other Level A criterion most sites miss
- The $97 Launch — building accessible sites from day one
This post is informational, not legal or accessibility-consulting advice. Mentions of WCAG, ADA, and the European Accessibility Act are nominative fair use. No affiliation is implied.
