Should tab move through the contents of a tab container before moving between tabs?

Question

I have a question about tabs (like containers, used to group information together) and tab ordering (used when pressing the tab key to move between elements on a page) in terms of accessibility and usability when used on web pages.

Since the browser will generally set the tab order to work through the elements on a page sequentially (unless tabIndex is provided to each element) this causes some oddities in behaviour when the tab container is aligned so that the tabs go across the top of the content.

The tab container implementation is some custom thing used in a CMS package and the tab ordering feels completely unintuitive to me with the particular software I'm using.

Take a look at these crudely drawn images that contain absolutely no Comic Sans whatsoever:

Would you expect that pressing tab would first go through each tab before moving onto the content in the tab as follows:

This is in fact, the way it currently works when the tabs are aligned across the top of the content. This doesn't feel right to be at all.

Alternatively, would you expect that pressing tab would work its way through the contents of the tab before moving onto the header for the next tab, as follows?

What are the merits of both tab orders in terms of both usability and accessibility? Are there any scenarios where one works better than the other or a generally agreed standard on how these are supposed to work?

Answer 1

Windows has a particular behaviour for tabbed dialogs.

Tab moves between the fields on the tab, and after the last item, the tab name gets focus. Using Tab when the tab name has focus moves back to the first field again. It doesn't move on to the next tab.

To move to the next tab, use Tab to move focus to the tab name, then use the arrow keys ←→ to change tabs. Focus moves to the visible tab's name, and Tab then moves between the items on the new tab.

This is reasonably intuitive; at least, it doesn't take much getting used to. Any web app should behave similarly.

If a web app is not to behave similarly, then Tab should treat the entire tabbed dialog as a single collection of fields and should simply cycle through the fields on the first tab and then move on to the second. This behaviour would be easily understood. But it has the major disadvantage that it's not easy to correct a field which has previously been encountered on the visible tab, nor is it necessarily easy to use the keyboard to go back from tab 5 to tab 1 in a few keystrokes.

Answer 2

From a web-accessibility perspective (I'm unsure if your example is a website or not) you really want to keep the tabs as separate navigation items from the content within. A screenreader (and therefore likely a keyboard user) will jump to the navigation or jump to the content in order to access the items. If they've jumped to the navigation (tabs) then they're going to want to use the tabs.

If the user is tabbing through the navigation options and wants to view the content of one tab then they will select it to do so, if they don't want to view the content they will 'tab' onto the next item to hear if that's what they're interested in. If they have to cycle through all the content of each tab just to get to the piece of content they want (and they wouldn't even know if the content they want even exists yet as they wouldn't have had the tab title read out to them by the screenreader until they reach it on the page) then that is not a good user experience.

Also, should they want to jump back to the navigation after reading the content then the navigation is just one item to locate using the relevant screenreader shortcut key. If the tabs are not set as the navigation then it's going to be difficult for them to get back to it.

Keep the tabs as navigation, keep the content as content and then the user can browse the nav or read the content however they choose to do so.

This all gets a bit more complicated if your tabs are javascript-based though. That opens up the whole ARIA-region issues (letting screenreader users know that certain areas of the page have been updated after the page has been loaded) which is something that needs considering (but is a bit too technical for me to go into here - coupled with the fact I don't fully understand how ARIA regions work well enough to explain here!)

Answer 3

As a user what gives me the indication that clicking on the hyperlink will direct me to tab 2 at any given point?

Without understanding the context it's hard to provide a meaningful answer. Generally Tabs are designed to consolidate data, making it easier for users to sift through a page that is content heavy, or break down a process simplifying the user flow.

With that said as soon as user finds the content they need clicking on the hyperlink, they would be taken to the next experience that the hyperlink takes them to.

Hope this helps.

Answer 4

Why not tab (or shift+tab to move backwards) to move between hyperlinks and ctrl+tab to move tabs (ctrl+shift+tab for backwards)? I thought that was more or less the standard...