Contradictions in Accessibility – Keyboard Usage and Tabindex

This article is also available in German, translated by Tomas Caspers.

One of the basic tenets of building accessible web sites is designing for device-independence. The most common interpretation of device-independence is to ensure that keyboard functionality is available for all users – both those that must use, and those that choose to use, the keyboard as their primary input device rather than a mouse. Further, many assistive technologies for people with mobility impairments work with the keyboard directly, or through emulating keyboard functionality.

In an effort to make their pages more accessible, many people (not all) attempt to implement both skip to content links along with tabindex.

So, what can happen when these two techniques are combined? Consider a site with a skip nav link with a tabindex of 1. Immediately following the skip nav link is the site’s global navigation: Home, About Us, Services, and Contact with a tabindex of 2,3,4 and 5 respectively.

A keyboard user tabs to the “skip to content” link (tabindex of 1) and activates the link to take them to the main content. Then they press tab again, and are taken to the link with the next tabindex (the home link, with tabindex of 2), placing them back in the site’s navigation bar. In many cases, when tabindex is used on links it effectively renders the skip to content link useless.

Oops.

This behaviour does depend on the user agent being used. Quick tests show that:

• Gecko based browsers display the above mentioned behaviour (both Mac and PC)
• IE 5.1 (Mac) exhibits the behaviour outlined above
• IE 6 and 5.5 (PC) both pick up the next tabindex in the content area.
• Opera 7.x allows you to follow the skip to content link. Tab again, and it places you back on the skip to content link again and then lets you continue from there.
• Netscape 4 (sure, why not…) performs the same as the Gecko browsers

We’ll continue to add to this list as we continue testing.

Web Content Accessibility Guidelines

In this case, authors are simply using two techniques found in the Web Content Accessibility Guidelines.

WCAG Checkpoint 13.6 advises developers to Group related links… until user agents do so, provide a way to bypass the group. This has lead to many sites using “skip navigation” or “skip to content” links, and are usually the first items found in a page. This is a useful feature.

WCAG Checkpoint 9.4 states Create a logical tab order… For example in HTML specify a tab order via the tabindex attribute, or ensure a logical page design.

The problem really occurs when authors implement tabindex in cases where it really isn’t needed. As with most development work, some simple accessibility testing would eliminate this problem almost immediately.

Who is responsible?

As always, we all share responsibility for accessibility. At this point there is no concensus amongst browser vendors in terms of how this should implemented and the User Agent Accessibility Guidelines provide no guidelines on how to implement this functionality.

People also have to make appropriate choices in terms of the browser they use, and they could select one that behaves in an appropriate manner. In this case, it would appear that Internet Explorer is closest to the desired behaviour: activating a same page link (such as a skip to content link) moves the focus to the target, and continues from there, rather than return to the next tabindexed value like a Gecko based browser.

This leaves the authors. The good news is that Checkpoint 9.4 of WCAG says “For example, in HTML, specify tab order via the “tabindex” attribute or ensure a logical page design.”

Now that many developers and designers are moving forward, and producing standards based, tableless layouts, in most cases they are creating pages that have a logical page design with a logical tab order. Generally authors don’t need tabindex with these types of layouts as the technique can cause more problems that it solves.