When navigated sequentially using the ‘Tab’ key, interactive elements should receive focus in a predictable, natural reading order (from left to right and top to bottom, in most cases).
The easiest way to avoid focus order issues is to make sure that elements are laid on screen in the same order as they appear in the Document Object Model (HTML document).
Manage keyboard focus manually when needed to make the interface easy to use for screen reader, Switch control and keyboard-only users.
For example, if pressing a button triggers a modal dialog, keyboard focus should move to that dialog and stay within (rather than going back to elements behind the dialog), until the user closes the dialog.
Why?
Keyboard users and screen reader users use the ‘Tab’ key to navigate between the focusable (interactive) elements on a page.
If that navigation doesn’t happen in a logical way, it’s difficult to understand:
which element on the page currently has the keyboard focus;
where they are on the page;
how to reach a specific element on the page.
How does this work?
The order in which elements are laid out on screen should match the order in which they’re defined in the Document Object Model (HTML document).
But some (discouraged) CSS and HTML techniques can create a mismatch here. We shouldn’t use those techniques.
See Rob Dodson explain ‘Focus order’ in this short video:
Guidance for Design
When you provide different mockups for different screen sizes (such as desktop, mobile, and for different break points), make sure that all interactive elements appear in the same order across on the different mockups.
If you really can’t do that, call it out to developers and ask them to reorder the elements across different breakpoints in the HTML code itself, rather than using CSS.
On the designs that you give to developers, and in conversations with them, indicate what the ‘keyboard focus order’ should be for interactive elements.
Also indicate when actioning a button should move the keyboard focus somewhere else.
In particular:
When activating a button makes a modal dialog appear, which interactive element within the modal should receive focus? (Usually it should be the first one).
When closing a modal dialog, which interactive element should the keyboard focus move to? (Usually it should be the button that triggered the modal).
When activating a button that disappears right after being activated, where should the keyboard focus move to?
A common design mistake
The order of interactive elements is not consistent across designs for different screen sizes.
For example, imagine that you’ve designed a modal dialog with two buttons: ‘Cancel’ and ‘OK’:
On the design for large screens, the ‘Cancel’ button is positioned to the left of the ‘OK’ button. (‘Cancel’ comes before ‘OK’ in the reading order).
But on the design for small screens, the ‘Cancel’ button is positioned to the bottom of the ‘OK’ button. (‘Cancel’ now comes after ‘OK’ in the reading order).
Be careful how you order elements in the DOM is it impacts user experience
Place interactive elements in the Document Object Model in an order that makes sense for users who navigate interactive elements sequentially, like screen reader, Switch control and keyboard users
Manage keyboard focus when needed to make the interface easy to operate
Manage keyboard focus manually when needed to make the interface easy to use for screen reader, Switch control and keyboard-only users.
Look at the keyboard support and focus management guidance in the ARIA Authoring Practices Guide, which covers many common user interface design patterns.
Do not use positive values with tabindex
Do not use positive values with tabindex.
Example
<h1tabindex="-1">I'm the heading for a modal dialog</h1>
...
<divtab-index="0"class="fake_button"aria-role="button">Button Label</div>
Be careful when using CSS Float, Flexbox, Grid and position
With CSS Flexbox, don’t use the order property or flex-direction: reverse;;
With CSS Grid, be careful with manual placement of items on the grid;
When using positionabsolute, fixed or sticky, be careful to not detach the visual order of elements from the order in which they appear in the DOM;
Make new content appear in the DOM right after the element that triggers it
If a button triggers extra content to appear (like a menu), make sure that that extra content appears next to the button in both the DOM order and visual order.
How to test whether elements appear in a logical reading order in the DOM
Use the ‘Tab’ key to go through interactive elements on a page. Check that interactive elements receive keyboard focus in an order that makes sense and makes the interface easy to operate.
Alternatively, turn off CSS on the page to see elements laid out on screen in the order in which they appear in the Document Object Model.
Common mistakes
The DOM order does not match the visual order because CSS properties like flexbox and grid-layout have been used to alter the visual presentation;
The DOM order does not match the visual order because tabindex has been used with a value other than -1 or 0.
A ‘Agree to cookies’ dialog that’s positioned last in the DOM but appears at the top of the screen, without being implemented as modal (with the inert attribute)
When CSS styles are disabled, the focus order is meaningless;
Using dialogs or menus that are not adjacent to their trigger control in the sequential navigation order.
Official wording in the Web Content Accessibility Guidelines
2.4.3 Focus Order: If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. (Level A)