Apply a logical tabbing order to your HTML document
Duplicate tabindex attribute values in HTML are allowed on certain elements to control navigation.
An IRC (mainly #CSS on EFnet) colleague of mine nicknamed taare brought a pretty interesting find into perspective, contrary to what I believed to be true with regards to tabindexing in HTML documents.
I've always used unique tabindex values in my HTML documents, to not confuse any tabbing order. I can't recall if this originated from my practices in (X)HTML documents, in any case, I believed only unique values may be used (no duplicates). As he points out (after my comment on his site), in his tabindex exposed article, identical tabindex values may be used (reference: Tabbing navigation).
... Elements that have identical tabindex values should be navigated in the order they appear in the character stream.
I humbly stood corrected.
After a little mind boggling on this, I started to do a small test case, and noted the following:
The behaviour of elements that have identical tabindex values act differently across UAs (namely Lynx, Opera, IE and Firefox); perhaps this is expected, regardless of the W3C HTML specification. Though this finding was a moot point as the W3C tabbing navigation also states the following, regardless of unique or identical values:
Tabbing keys. The actual key sequence that causes tabbing navigation or element activation depends on the configuration of the user agent (e.g., the "tab" key is used for navigation and the "enter" key is used to activate a selected element).
taare was also right on his research, where there was no indication at the WCAG about this. I looked it up myself for amusement, and could only note a vague statement as the following:
9.4 Create a logical tab order through links, form controls, and objects.
I suppose in there somewhere, they meant to say that the logical tab order among a group of tabable elements. I'll get to this shortly as to why iterating through the tabindex values, is a bad idea - especially if there is a grouped elements in picture.
I can see how using the same tabindex values can be beneficial in situations where there is a (for the lack of the term) group of tabable elements, i.e. site navigation, forms etc.. Having all of the 'grouped' tabindex values can save a lot of time during development, as the order of the links may change in menu for instance, but the tabindex values don't effect anything as they are all the same, and can be tabbed in the order they appear in the HTML document.
However, even in this case the tabindex values should be in sequential order for the overall document (regardless of repetition) and the group of tabable elements should not be cut by a different value, unless it is absolutely necessary.
Consider this case:
<a hre="" tabindex="2"> .. </a> .. <form> .. <input.. tabindex="1"> .. <input.. tabindex="2"> .. <input.. tabindex="3"> .. .. </form>
The first tabbing will get to desired location on the form, however the next tabbing will move back to top anchor, and the following tab will move back down to the 2nd input. On another note, the iteration for the 2nd round starts back from the top of the document. Still with me?
Hence, there is no need to introduce confusion by breaking this schema by allowing a different tabindex value within a group of tabindex values. Obviously this is because it could cause the tabbing to go back and forth.
Preferred method should be the following in my opinion:
<a hre="" tabindex="2"> .. </a> .. <form> .. <input.. tabindex="1"> .. <input.. tabindex="1"> .. <input.. tabindex="1"> .. .. </form>
When tabindex 1 iteration is complete, it will then escape from this group and move to the 2nd tabable element. This seems to be the effective and usable way of doing duplicate tabindex values in an HTML document.
What we can also conclude is that, in the production phase, either method; groups or independents work fine. If grouped (duplicate values) then careful consideration should be given. Considering the difference in UAs when tabbing, it can be a scary thought to bring it into our documents. Instead of being helpful, it could be quite harmful with respect to usability.
On a final note; a well structured and organized HTML document essentially require no tabindexing.
Hi, nice article Sarven. A little more in depth than mine. I'll admitt I didn't know about the diffrence across browsers concering tabindexes, I'll look closer into that. As for the final note, I believe that most people would want to see the main content(eg. an article) when they first access the document, but they also want the navigation links to be easy accessible.
So from that, I figured that navigation links should have a higher tabindex than the main content. In addition, I didn't want skip to links to be above the h1(I really don't see why people are doing this) but I wanted them to be tabbed to before the h1 link, so I've used tabindexes in such cases too.
It's funny that I happened across this post because just this past Friday a coder that I work with asked me what tab indexes were and if he could have more than one with the same number.
I figured that navigation links should have a higher tabindex than the main content. In addition, I didn't want skip to links to be above the h1(I really don't see why people are doing this) but I wanted them to be tabbed to before the h1 link, so I've used tabindexes in such cases too.
nice article, I've always wanted to use identical values but wasn't sure if it was valid or supported by browsers.
It's really useful if you have different HTML coming in from different PHP includes to be able to say that the form elements you're working on should go first and go in order (not jump down to others included from other template files) by setting them to tab index 1 ...