On a web application what should be in tab order?

Question

I see a lot of articles which guide us how to put something in or out of tab order. However, I see no guide on what should be put in tab order.

For example, one of our web app is a list of tasks to perform. On top left corner it shows the overall progress. We have included the tasks in tab order but have left out the overall progress. We have marked overall progress as live region as it is like status and has no actionable item.

However, our QE is of the opinion that that should too fall under tab order. In fact sometimes some people even argue that each head or paragraph tags too should be in tab order.

Where and how do we draw the line?

Answer 1

Summary: Make sure the page can be used with keyboard only.

• the user can scroll everything into view that they want to see
• the user can interact with all elements on the page they need

This usually does not require element without user interaction (such as the overall progress you describe) to be reachable by tab, if it can be scrolled into view by keyboard.

Do not assign a tab order to elements without explicit reason, as this increases keyboard navigation time.

---

Maybe that's the problem: User has focus on input element that handles Page Up / Home differently, so they can't easily scroll to the pveral progress panel.

---

Thoughts leading up to that:

The primary function of keyboard tab order is to assist keyboard-only interaction: filling in forms, playing embedded videos etc. For this, there is no reason to make any no-input / no-interaction element tabbable.

The UX feature is to be able to navigate to and on the web site without ever touching the mouse or the screen. So an - insufficient - rule of thumb would be "anything that responds to clicks".

---

However, tab has an "accidental functionality" of page navigation: the element in focus will be scrolled into view, so navigation can be used (abused) for a "content-specific scroll".

I'm not sure that this would be a valuable feature, if it makes keyboard-only interaction harder (because oyu have to tab more often). At least on pages without horizontal scrolling, Page Up / Page Down are sufficient and familiar.

Answer 2

I think @peterchen's reply needs a little clarification.

"The primary function of keyboard tab order is to assist keyboard-only interaction"

A keyboard-only user is not necessarily a sighted keyboard user. A visually impaired user can only use the keyboard, combined with a screen reader, so they need to be able to interact with the entire page. A completely blind user doesn't care if a page can scroll or not as long as they can get to all the elements. A low vision user does care if things can scroll into view, especially if they're using a magnifier that follows keyboard focus.

there is no reason to make any no-input / no-interaction element tabbable.

That's not quite accurate. A disabled button doesn't allow any input but it can be extremely helpful to allow focus to move to it for the benefit of visually impaired users, namely screen reader users. As a non-sighted user, when going to a new page, it's very helpful to tab through the page to get an idea what's available. If disabled objects are skipped in the tabbing order, the user may never know that some feature is possible because they don't know it's there.

For visual users, you can often infer that a disabled object will become enabled if you perform some other action on the page. A visually impaired user might not get that same hint unless they know the disabled object is there.

Anyway, back to the original question, you should always start by allowing naturally occurring objects to have their native tab behavior. Don't force a button to not be in the natural tab order and don't force a simple paragraph of text to be in the natural tab order. Now, I'm not saying those cases should never occur, but if you start with the premise of allowing natural objects to be in the tab order, you're off to a good start.

In your specific case, about the progress of the task, as you move through the steps of the task, would a non-sighted user understand where they are in the progress? You mentioned a live region, which is good. If I complete a step, hear the progress change announced, step out of the office to get a drink, then come back, is there a way for me to refresh my memory of what step I'm on? The visual user can see it. How would a non-visual user hear it? Tabbing to it is one way, but not the only way. Is the progress marked semantically? Is it a heading (h2, h3, etc)? Is it a landmark (role=navigation, role=complementary, etc)? This semantic info is very helpful for screen readers. I can easily navigate to the next or previous heading using the H key or the next/prev landmark with R (for jaws) or D (for nvda). So if the progress is semantically marked up properly, I could quickly navigate to it with the screen reader and hear where my progress was before I took the break.