[whatwg] tabindex="" feedback

Thu Apr 24 02:47:24 PDT 2008

I've revamped the spec for tabindex="" based on the feedback below.

On Wed, 21 Mar 2007, Simon Pieters wrote:
> 
> 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).
> [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2006-August/007228.html

Agreed.

> 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.)

While I agree in principle, it's clear that there is a demand for custom 
widgets, and since people are going to do it anyway, we might as well 
allow them to do it in an at least semi-accessible way.

> 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.

Agreed.

> 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.

Indeed.

> 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.

Yup.

> 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 before.

I've allowed positive values, but I've allowed user agents to ignore them 
(supporting them is only a "should").

On Tue, 20 Mar 2007, ddailey wrote:
> 
> In a table, I think I agree. The user should know how to get around via 
> UI conventions. In more abstract structures, the author may be able to 
> provide useful hints through tab order.

That's one reason I didn't outlaw it altogether.

On Tue, 20 Mar 2007, Maciej Stachowiak wrote:
> 
> Arbitrary elements accepting keyboard input (which is what focus is 
> about) is just as important as arbitrary elements receiving mouse input. 
> You even cited one of my examples below: consider a game implemented 
> with <canvas> that uses keyboard controls. Obviously you want to be able 
> to make <canvas> focusable in such cases. There are many analogous use 
> cases, consider building compound controls with XBL that want to have 
> their own keyboard navigation. I don't think there is any need to limit 
> what elements can get keyboard input

This seems reasonable.

> Shift+arrows are a completely separate issue from "tab order".

Indeed.

> HTML5 can also recommend not adding these attributes gratuitously.

We could, I guess. Right now it doesn't give much author advice either 
way.

> Note that UAs do not even agree on what elements are focusable by 
> default. In Safari, links and <input type="button"> controls are not in 
> the tab order, for instance, to match Macintosh UI conventions.

The spec caters for this.

Can <input type="button"> controls be focused at all, on OS X?

On Wed, 21 Mar 2007, Benjamin Hawkes-Lewis wrote:
>
> Dropping tabindex /might/ make sense if HTML5 was to be so feature 
> complete that no-one would ever build a DHTML widget out of generic 
> elements ever again. Is this likely to be the case? Because, if not, 
> tabindex looks like part of a solution:
> 
> http://developer.mozilla.org/en/docs/Key-navigable_custom_DHTML_widgets
> 
> Of course, we might want to try to improve on tabindex and fix the 
> scoping problem. Perhaps:
> 
> <div id="foobar">
> <div tabgroup="foobar" taborder="2"/>
> <div tabgroup="foobar" taborder="1"/>
> </div>

Would it be used often enough to matter?

(XBL has scoping, FWIW.)

On Wed, 21 Mar 2007, Colin Lieberman wrote:
>
> Drop tabindex altogether. It's just not useful.

People seem to disagree. :-)

> See the Web Accessibility Initiative Interest Group discussion on the 
> subject:
> 
> http://www.w3.org/Search/Mail/Public/search?type-index=w3c-wai-ig&index-type=t&keywords=tabindex&search=Search

These comments generally don't seem to cover custom widgets. Did you have 
any specific e-mails in mind?

> Tabindex is not a substitute for poorly organized documents, and at the 
> end of the day, it's up to the UA to give the user final say on tab 
> order.

I agree on the latter point.

On Wed, 21 Mar 2007, Gervase Markham wrote:
> 
> Before doing that, it might make sense to consult the accessibility 
> teams of the UA vendors. In Mozilla's case, that's Aaron Leventhal. I 
> believe that there have been recent changes to this property to better 
> allow keyboard accessibility of DHTML widgets: 
> http://developer.mozilla.org/en/docs/Key-navigable_custom_DHTML_widgets

Aaron has been in the loop of this discussion. :-)

On Wed, 21 Mar 2007, MegaZone wrote:
> 
> The UA could always offer the ability to override/disable tabindex in 
> documents - as they can offer user stylesheets, etc.  People who dislike 
> the tabindex could disable it, and those who prefer to use the pages as 
> the author index them can do the so.

Indeed.

On Thu, 12 Apr 2007, Martijn wrote:
>
> According to:
> http://www.whatwg.org/specs/web-apps/current-work/#negative-tabindex
> "
> A negative integer specifies that the element should be removed from
> the tab order. If the element does normally take focus, it may still
> be focused using other means (e.g. it could be focused by a click).
> "
> 
> That appears not to be true in IE7, see:
> <div tabindex="-1" onfocus="alert('div')">click me</div>
> This triggers the alert in IE7.
> 
> So it seems to me the " If the element does normally take focus,"
> should be removed.

Fixed.

On Thu, 26 Jul 2007, Simon Pieters wrote:
> 
> In Firefox, any element that has a tabindex attribute specified, 
> regardless of its value, receives focus when it is clicked. Is this to 
> be considered a bug in Firefox or should the spec be updated to reflect 
> this?

Invalid values don't have this behaviour for consistency with IE.

On Tue, 22 Apr 2008 sjoerd at w3future.com wrote:
> 
> An incompatibility between the implementation of tabIndex between IE and 
> Firefox caught my attention because Webkit is now implementing tabIndex 
> as well. [1]
> [1] https://bugs.webkit.org/show_bug.cgi?id=7138
> 
> In IE, unfocusable elements with tabIndex="-1" are still not focusable. 
> In Firefox they are focusable. Focusable elements stay focusable with 
> tabIndex="-1" in both browsers.

I don't understand what you mean. Could you elaborate?

> The HTML 5 spec specifies the IE behavior, if I read it correctly. I 
> would prefer the IE implementation as well, simply because that would 
> make the implementations compatible sooner.

I've updated the spec. Is it still what you want?

On Tue, 22 Apr 2008, Aaron Leventhal wrote:
> 
> The WhatWG spec appears to be wrong, in that it says:
> > A negative integer specifies that the element should be removed from 
> > the tab order. If the element does normally take focus, it may still 
> > be focused using other means (e.g. it could be focused by a click).
>
> It should also say that a negative integer makes elements focusable but 
> not tabbable, whether they are normally focusable or not.
> 
> IE certainly does do that -- they just don't show focus visually, which 
> is really a section 508 mistake on their part. The app always needs to 
> show where the focus is. For IE the author's workaround is to put in an 
> onfocus handler and use element.style to show focus.

On Tue, 22 Apr 2008, Aaron Leventhal wrote:
> 
> I checked with Opera and they also do tabindex="-1" makes anything 
> focusable. So the spec is out of line with implementations.

Spec updated.

On Wed, 23 Apr 2008, Anne van Kesteren wrote:
> 
> Note that for
> 
>   http://tc.labs.opera.com/html/global-attributes/tabindex/004.htm
> 
> implementations do differ.
> 
> I think it would make sense for Firefox and Opera (and Safari) to align 
> with Internet Explorer and "ignore" the tabindex attribute when it has 
> an invalid value specified.

Specced thusly.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'