Understanding Logical Focus Order

April 11, 2021

Logical focus order is a key element of web accessibility and is required by WCAG 2.1 in order to meet Level A standards. Let’s dive into what it is, why it matters, who it benefits, how to test for it, and some common pitfalls to avoid.

In This Article:

What is Logical Focus Order?

Logical focus order is the idea that someone navigating your webpage with a keyboard (i.e. without a mouse) will encounter elements in an order that makes sense.

As someone presses TAB on their keyboard to move through your webpage, focus should go to interactive elements in a logical order. The order should make sense both for the meaning of the content and for how it is visually displayed.

Generally, for a left-to-right language, this means focus should start at the top-left of the page, move left to right across the page, and move from top to bottom. For a right-to-left language, focus should move from right to left, but still from top to bottom. The focus should not skip any interactive elements or visit those elements out of order.

I’ve provided a visual illustration of the expected focus order for a left-to-right language below. The focus should start where I have labelled #1 and proceed through the numbers in order.

Illustration of focus moving from the top left to bottom right of a webpage.

Why Does Logical Focus Order Matter?

It’s confusing when focus order doesn’t make sense!

Logical focus order provides a better user-experience. You will have happier website visitors, tasks will take less time to complete, customers won’t give up on shopping your store because they can’t figure out how to get to the “add to cart” button… the list goes on and on.

Who Does Logical Focus Order Benefit?

Logical focus order is critical for both fully-sighted and visually-impaired folks who use keyboards to access web content. It is also important to anyone who might get disoriented when their focus goes somewhere unexpected.

How to Test for Logical Focus Order

One way to test your webpage’s focus order is to try using only your keyboard to navigate it.

You can use your TAB key on your keyboard to advance through the interactive elements on your page and check for the following:

  • The focus moves from left to right (or right to left for a right-to-left language) and top to bottom.
  • The focus does not skip any interactive elements entirely.
  • The focus visits interactive elements in an order that makes sense given the visual layout.

I’ve provided further tips on getting started testing with a keyboard in my article on manual accessibility testing.

Additionally, Firefox now has a feature that allows you to visually inspect the focus order. You can toggle the Show Tabbing Order checkbox in the Accessibility Inspector to see numbers labeling the tab order of elements on the screen.

Firefox’s Show Tabbing Order can only reflect what is on the page at the time when you check the box, so I would still recommend testing manually as well, especially if you are dynamically adding or removing elements from the page.

What are Some Common Pitfalls and How Can You Fix Them?

Visual Order that Differs from the Source Order

One of the most common focus order issues I have seen stems from a page having a visual order that is different from its source order.

Take the following flex container as an example. In the first case, I have a flex container with flex-direction: row. The two links inside the container are presented visually in the same order they are included in the HTML. If you tab to these two links, the focus order will be logical. The one on the left will get focus first, then the one on the right.

If you resize your browser or are on a mobile device, the two paragraphs will stack. The focus order remains logical, going to the top one first, then the bottom one.

Now, imagine I’m implementing a design where the item on the left moves to the bottom on a mobile device. That is a pretty common pattern to handle sidebars that appear on the left on desktop.

In that case, I might be tempted to apply flex-direction: column-reverse to my flex container. This would accomplish what I need, visually. However, it will cause issues with the logical focus order.

Now, my focus will go to the bottom element before the top one! You can try it yourself here by using your keyboard to tab to the two elements below.

Instead of changing the visual order with CSS, you can maintain a logical focus order by changing the actual the source order, too.

In the example of moving a left sidebar on desktop to the bottom on mobile, you could create two versions of your sidebar—one for mobile and one for desktop—then hide the mobile one on desktop and hide the desktop one on mobile.

Focus Goes to Hidden Elements

If you hide interactive elements, make sure you also remove them from the focus order. It can be confusing and disorienting for focus to go to hidden elements. Plus, someone might be able to interact with functionality in ways you didn’t intend or expect.

If you use display: none or visibility: hidden in your CSS to hide your elements, they should also be hidden from keyboards and screen readers.

However, if you visually hide them some other way, you’ll have to do a bit more work to hide them from assistive technologies.

To remove an element from the focus order, you can add tabindex="-1" to its markup.

You’ll also need to hide that element from screen readers, which you can do by adding aria-hidden="true" to that element.

Adding Elements to the Focus Order

If you add interactive functionality to an element that is not interactive by default, you’ll need to make sure you add it to the focus order of the page. Otherwise, keyboard users won’t be able to access it at all.

The best way to do this is to add tabindex="0" to the element’s markup. This will add the element to the normal flow of the document. (Make sure to add the appropriate keyboard event listeners, too!)

Note: while you can technically use positive values for tabindex to specify an explicit focus order, you almost never should. Check out this article from Deque on avoiding using tabindex with positive numbers for more on why.

Further Reading

Rachel Leggett, is an Ann Arbor-based front-end web developer, accessibility specialist, and knitwear designer. She spins some yarns about web development, web accessibility, and other tech topics in the DevYarns blog.

© Rachel Leggett, Built with Gatsby