This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
+++ This bug was initially created as a clone of Bug #27076 +++ This is a proposal to officially declare tabIndex values > 0 invalid in the spec and the validator. Rationale: The tabIndex attribute is used to make items focusable with the keyboard and programmatically. Currently, it takes three classes of values: * 0: The element is made focusable, and it is integrated into the tab order at its location in the DOM. * -1: The element is made focusable, but is skipped in the tab order, but can still take focus programmatically. * > 0: The items are put in the tab order first, and their order is determined by the actual value. Only if all those elements have been traversed via tab, does the order in the DOM take effect. This third class of values has in the past lead to nothing but frustration among web developers and keyboard users, judging from feedback I get in my day to day accessibility work. Also, personal experience shows that no instance of tabIndex use that involved values greater than 0 have led to better usability. On the contrary, in all my personal experience over the years, I have not come across one site that got this right. Due to author error, which mostly stems from lack of awareness, tab order on many sites that use tabIndex improperly is erratic and not user-friendly. For further reading on this, I suggest a post published on the Paciello Group blog by Léonie Watson in August of 2014: http://www.paciellogroup.com/blog/2014/08/using-the-tabindex-attribute/ Proposed changes: 1. Include explicit text to not use tabIndex with a value greater than 0 in the next version of the documentation of the tabIndex attribute in the HTML spec. 2. Change the W3C validator to spit out an error on tabIndex values other than 0 and -1.
(In reply to Michael[tm] Smith from comment #0) > +++ This bug was initially created as a clone of Bug #27076 +++ > > This is a proposal to officially declare tabIndex values > 0 invalid in the > spec and the validator. > > Rationale: The tabIndex attribute is used to make items focusable with the > keyboard and programmatically. Currently, it takes three classes of values: > > * 0: The element is made focusable, and it is integrated into the tab order > at its location in the DOM. > * -1: The element is made focusable, but is skipped in the tab order, but > can still take focus programmatically. > * > 0: The items are put in the tab order first, and their order is > determined by the actual value. Only if all those elements have been > traversed via tab, does the order in the DOM take effect. > > This third class of values has in the past lead to nothing but frustration > among web developers and keyboard users, judging from feedback I get in my > day to day accessibility work. Also, personal experience shows that no > instance of tabIndex use that involved values greater than 0 have led to > better usability. On the contrary, in all my personal experience over the > years, I have not come across one site that got this right. > > Due to author error, which mostly stems from lack of awareness, tab order on > many sites that use tabIndex improperly is erratic and not user-friendly. > For further reading on this, I suggest a post published on the Paciello > Group blog by Léonie Watson in August of 2014: > http://www.paciellogroup.com/blog/2014/08/using-the-tabindex-attribute/ > > Proposed changes: > > 1. Include explicit text to not use tabIndex with a value greater than 0 in > the next version of the documentation of the tabIndex attribute in the HTML > spec. > 2. Change the W3C validator to spit out an error on tabIndex values other > than 0 and -1. I strongly suggest to rethink this proposal. Very frequently visited websites make use of tabindex and my experience is the opposite of yours on these web sites. While it is for sure a better practice to structure your document in the order you want it to be observed, breaking tabindex will very likely break a tone of web sites that are actually making use of tabindex as intended.
Dirk, got any example that is publicly accessible? Since I only know of totally broken tabindex use (like focusing first user name, then password, but totally forgetting to include the actual Login button), and similar broken patterns, I'd really be curious to see an example that actually uses this thing correctly.
In many states, web sites of public institutions but also companies are forced to follow the WCAG 1.0 which has tabindex listed. So you should be able to find a lot of pages having tabindex. The first two web pages I surfed to were lufthansa.com and bahn.de both use tabindex for tabbing order.
(In reply to Dirk Schulze from comment #3) > In many states, web sites of public institutions but also companies are > forced to follow the WCAG 1.0 which has tabindex listed. So you should be > able to find a lot of pages having tabindex. > > The first two web pages I surfed to were lufthansa.com and bahn.de both use > tabindex for tabbing order. cannot find any tabindex >0 in lufthansa.com home page on bahn.de the focus order is illogical and includes many hidden tab stops - hardly a poster child for tabindex or keyboard accessibility in general. WCAG 1.0 was superseded 6 years ago when WCAG 2.0 became a REC. WCAG 1.0 did not require use of tabindex, but did provide it as an example method to to ensure logical tab order: 9.4 Create a logical tab order through links, form controls, and objects. [Priority 3] For example, in HTML, specify tab order via the "tabindex" attribute or ensure a logical page design. http://www.w3.org/TR/WCAG10/#gl-device-independence Note: this is a priority 3 criteria and most governments when they used WCAG 1.0 requirements only required priority 1 and 2, not priority 3.
have created a wiki page to capture discussion on issue https://www.w3.org/wiki/HTML/Usage/tabindex ,anybody feel free to edit
> This third class of values has in the past lead to nothing but frustration > among web developers and keyboard users, judging from feedback I get in my > day to day accessibility work. To make a decision here, we need to quantify this. I can't really see a way to do that in an automated fashion, though. When tabindex="" is used correctly, nobody will know that it is used at all. Similarly, on pages where it is needed, but isn't used at all, you get a horrible tabbing experience despite it not having been used at all.
https://github.com/whatwg/html/pull/937