What is Keyboard Navigation Order?

What is keyboard navigation order?

Keyboard navigation order, also called tab order or focus order, is the sequence in which links, buttons and form fields receive focus as a user presses Tab. It should match the meaning and visual flow of the page. WCAG 2.4.3 Focus Order (Level A) requires focusable components to receive focus in an order that preserves meaning and operability.

How it works

By default the order follows the HTML source. Natively focusable elements such as links with an href, buttons, inputs, selects, textareas, iframes and summary elements are visited in the order they appear in the document. Three things change that (see MDN on tabindex):

• tabindex="0" makes an element tabbable in source order.
• tabindex="-1" removes it from the Tab sequence but lets a script focus it, which suits a modal that opens or an error message after a failed submit.
• A positive tabindex jumps the element ahead of everything else. MDN recommends using only 0 and -1, because positive values and CSS that reorders focusable elements make pages hard to navigate for keyboard and assistive technology users.

The trap is that CSS can move things around visually (flexbox order, grid placement, absolute positioning) while focus still follows the source. The result is focus that jumps around the screen.

The WCAG criteria behind it

Keyboard order is part of a small group of criteria in the Web Content Accessibility Guidelines (source: W3C Understanding documents for WCAG 2.2):

• 2.1.1 Keyboard (A): all functionality works through a keyboard interface, with narrow exceptions for path-dependent input such as freehand drawing.
• 2.1.2 No Keyboard Trap (A): if focus can move into a component with the keyboard, it can move out with the keyboard, and the user is told how if it takes more than Tab or arrow keys.
• 2.4.3 Focus Order (A): focus order preserves meaning and operability. It does not have to mirror the visual layout, but it should not jump around randomly.
• 2.4.7 Focus Visible (AA): the keyboard focus indicator is visible.
• 2.4.11 Focus Not Obscured, Minimum (AA, new in WCAG 2.2): a focused component is not entirely hidden by author-created content, such as a sticky header or cookie banner.

Example: a checkout form

A form shows Name, Address and Card number in a column, but a CSS rule places the Pay button visually at the bottom while it sits first in the HTML. A keyboard user tabs from the top and lands on Pay before filling anything. The fix is to put the elements in the HTML in the order people use them, not to add tabindex values. If a sticky header covers the focused field as you tab down, add scroll padding so the field stays visible.

Common mistakes

• Fixing order with positive tabindex. It creates a second, hidden order that breaks as soon as someone adds a field.
• Hiding the focus ring. Removing the outline without a replacement fails Focus Visible.
• Clickable divs. A div with a click handler is not focusable. Use a button or link; ARIA roles do not add keyboard behavior on their own.
• Modals that leak or trap focus. Move focus into a dialog when it opens, keep it inside while open, give a keyboard way to close it and return focus to the trigger afterwards.
• Off-screen content that stays tabbable. Menus and panels that are hidden visually but still focusable make focus disappear.
• Only testing with a mouse. Order problems are invisible until you press Tab.

Keyboard order, testing and monitoring

The test is manual: put the mouse away, press Tab and Shift+Tab through the page, and check that every control is reachable, the focus is always visible and the order makes sense. A screen reader pass adds a second view of the same structure. Automated audits catch missing labels and some focus issues but cannot judge whether the order makes sense; see our post on why performance testing should include accessibility. To keep an eye on regressions, LoadFocus page speed monitoring runs scheduled Lighthouse audits and tracks the Accessibility score alongside performance. Pair that with a manual Tab check on key pages, and read how to build an accessible layout.

FAQ: Keyboard navigation order

What is the default tab order?

The order of focusable elements in the HTML source. The visual position does not matter, which is why CSS reordering can cause confusing focus jumps.

Should I ever use a positive tabindex?

Almost never. MDN recommends only 0 and -1. Rearrange the HTML into a logical order instead.

Which WCAG criteria cover keyboard navigation?

The main ones are 2.1.1 Keyboard, 2.1.2 No Keyboard Trap, 2.4.3 Focus Order, 2.4.7 Focus Visible and, in WCAG 2.2, 2.4.11 Focus Not Obscured (Minimum). The first three are Level A and the last two are Level AA.

What is a keyboard trap?

A component that keyboard focus can enter but cannot leave using only the keyboard, for example a poorly built embedded widget. WCAG 2.1.2 forbids it.

Does focus order have to match the visual order?

Not exactly. WCAG requires an order that preserves meaning and operability, and more than one order can be valid. It should still feel logical and must not jump around.