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.