[whatwg] Drop tabindex=""

Simon Pieters zcorpan at gmail.com
Tue Mar 20 20:16:41 PDT 2007


I think tabindex="" has a number of problems:

1) Lacking a feature to scope tabindexes into local contexts, which I  
proposed[1] a while back, makes the feature rather useless for its  
intended purpose (which, AIUI, was to provide a means for the author to  
suggest a different tab order than the natural one, because he was using,  
say, form controls in a table where the navigation should go down through  
the columns rather than row for row).

2) Using tabindex=0 or -1 to indicate whether an element can have focus is  
arguably bogus IMHO. Whether something is focusable depends on the UA or  
the device. I don't see any reason why apps would use <span tabindex=0  
onclick onkeypress> instead of just using links, form controls, or  
contenteditable="" (depending on what you're doing). (If you'd do this  
because form controls are hard to style, then HTML isn't the place to  
address that problem.)

3) The "tab order" should be up to the user. In Opera you can navigate in  
any direction you want using e.g. Shift+arrows, allowing you to freely  
navigate in tables for instance. The author shouldn't have any say about  
the tab order other than the source order.

 From what I've seen, most authors who use tabindex use it out of a cargo  
cultish habit thinking it would "aid accessibility" because some outdated  
accessibility guidelines told them so. The result mostly being reducing  
keyboard usability by distorting the tab order, because the elements with  
tabindex receive focus before anything else on the page. These authors  
don't realise how tabindex actually works, but they feel good about having  
added it because they comply with the accessibility guidelines, yet they  
don't know that it in fact screws up the tab order because they don't  
browse with the keyboard.

It was pointed out on IRC that there might be valid use-cases for #2, e.g.  
making a <canvas> focusable for games with keyboard controls. Then that's  
ok with me, I don't have strong opinions on this either way, I just think  
existing elements should be used where possible instead of reinventing  
links or checkboxes with <span tabindex> or similar.

However, for positive values of tabindex, I only see problems. The source  
order should be a powerful enough mechanism for authors to suggest a tab  
order of elements. I would love to see browsers treat all positive values  
for tabindex as equivalent to 0 (i.e., just make it focusable but don't  
change the tab order). I would also like to propose that positive values  
for tabindex be disallowed in HTML5 documents. I don't think it's a good  
idea to add a scoped tabindex feature (trying to address #1) as I proposed  


Simon Pieters

More information about the whatwg mailing list