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 to check
Tab through every focusable element on the page in DOM order. Three categories of problem show up.
First, 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, 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. Either add the appropriate ARIA role and tabindex, or replace the div with a native <button>.
Third, focus traps in modals and overlays. When a modal opens, focus should move into it and cycle within it until the user closes it. Focus escaping to background content, or a modal with no keyboard route out of it, is the failure.
The WCAG Accessibility Audit catches the second category automatically under success criterion 2.1.1, as part of a full WCAG 2.1 / 2.2 AA sweep. The first and third are a manual tab through the page.
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.
