← All guides

Keyboard focus order: designing the Tab sequence (WCAG 2.4.3)

What WCAG 2.4.3 asks for, the layouts that break focus order (grids, sidebars, dialogs, CSS reordering), and how to design and test the Tab sequence.

By Alejandro Vasquez · · 6 min

Many people never touch a mouse: keyboard users, screen reader users, people using switch devices, and plenty of power users. They move through a page with Tab and Shift + Tab, and the order of those stops is part of your design, whether you planned it or not.

What WCAG asks for

Success criterion 2.4.3 Focus Order (level A) says that if a page can be navigated in sequence and the order affects meaning or operation, focusable components get focus in an order that preserves meaning and operability. On most screens that simply means: focus follows the visual reading order.

  • 2.4.3 Focus Order (A): the sequence makes sense.
  • 2.4.7 Focus Visible (AA): you can always see where focus is.
  • 2.4.11 Focus Not Obscured (AA, new in WCAG 2.2): sticky headers, chat bubbles and cookie banners don't hide the focused element.
  • 2.1.1 Keyboard (A): everything that works with a mouse works with a keyboard.

Where the order usually breaks

  • Layouts reordered with CSS: order, flex-direction: row-reverse or grid-auto-flow: column change what people see, not where focus goes.
  • Positioned elements: a button that sits at the top of the screen but lives at the end of the HTML.
  • Positive tabindex: tabindex="1" jumps ahead of everything else on the page and is almost never what you want.
  • Dialogs: focus has to move into the dialog when it opens, stay inside while it is open, and go back to the button that opened it when it closes.
  • No skip link: without one, keyboard users tab through the whole navigation on every single page.

Designing the sequence

Focus order is a design decision, so it belongs in the handoff, not only in QA:

  • Number the focus stops on key screens and add them as an annotation layer in Figma.
  • Read the screen like text: top to bottom and left to right (right to left in RTL languages), group by group.
  • Finish a group before moving on: every field of a form row, every link of a menu.
  • Decide where focus lands after an action: after closing a dialog, deleting a row or loading new results.

In code

<!-- The first focusable element on every page -->
<a class="skip-link" href="#main">Skip to content</a>

<!-- tabindex: only 0 and -1 -->
<div role="button" tabindex="0">Custom control</div>
<h2 id="results" tabindex="-1">Results</h2> <!-- focused by script -->

Keep the HTML in reading order and let CSS handle layout without reordering. Native buttons, links and form fields are focusable for free and come with the right keyboard behavior, so reach for them before custom elements.

How to test it

  • Put the mouse away and Tab through the page, then Shift + Tab back.
  • Watch for focus disappearing (an element hidden or off screen) and for jumps that don't match what you see.
  • Open every dialog and menu: focus should go in, stay in, and come back.
  • Repeat at mobile widths: reflowed layouts are where the order breaks most.

Practice

Tab Order gives you five screens to number in Tab order, from a sign-in form to a settings page, and explains the rule behind each one.

Open the tool: Tab Order →

More guides