the proposal makes tabindex being a silly name :) it's not backward compatible change and will regress people who doesn't misuse it so perhaps it's safer to introduce new attribute.

As I write above, I don't know of any site which uses tabIndex with a positive integer value correctly. On the contrary, all support/advice inquiries I get have to do with the fact that it is being misused, primarily due to lack of awareness.

(In reply to Marco Zehe from comment #2)
> As I write above, I don't know of any site which uses tabIndex with a
> positive integer value correctly. On the contrary, all support/advice
> inquiries I get have to do with the fact that it is being misused, primarily
> due to lack of awareness.

I will grep some HTML data and see what examples I come up with.

(In reply to alexander surkov from comment #1)
> it's not backward
> compatible change and will regress people who doesn't misuse it so perhaps
> it's safer to introduce new attribute.

(In reply to steve faulkner from comment #3
> (In reply to Marco Zehe from comment #2)
> > As I write above, I don't know of any site which uses tabIndex with a
> > positive integer value correctly. On the contrary, all support/advice
> > inquiries I get have to do with the fact that it is being misused, primarily
> > due to lack of awareness.
> 
> I will grep some HTML data and see what examples I come up with.

Yeah it would help a lot to have some hard data about it, and an analysis of that data.

(In reply to Marco Zehe from comment #2)
> On the contrary, all support/advice
> inquiries I get have to do with the fact that it is being misused, primarily
> due to lack of awareness.

Short of making values other than 0 or -1 invalid, another option for raising awareness would be:

1. In http://www.w3.org/html/wg/drafts/html/master/editing.html#attr-tabindex change the statement about the allowed value of tabindex to read something like, "The tabindex attribute, if specified, should have a value of either 0 or -1. The value must otherwise be a valid integer. However, values other than 0 or -1 are considered _obsolete but conforming_."

2. In http://www.w3.org/html/wg/drafts/html/master/obsolete.html#obsolete-but-conforming-features add the statement, "The tabindex attribute is fully conforming but authors should not specify values for it other than 0 or -1."

3. The validator is updated to emit a warning (not error) message about any tabindex value other than 0 or -1.)

(In reply to Marco Zehe from comment #2)
> As I write above, I don't know of any site which uses tabIndex with a
> positive integer value correctly.

If/when a document was actually using it correctly with values greater than 0, you wouldn't know, right? I mean, in that case, everything would just work.

Given that, it would seem hard to demonstrate that there aren't any/many documents that are using values greater than 0 correctly, because there's no  observable difference in that case -- as opposed to the case where those values are being used incorrectly, which are noticeable.

if possitive tabindex values are the issue then I would deprecate @tabindex and introduced two new attributes @tabable and @focusable, nice and easy, that solves the issue and doesn't have backward compatibility problems.

I agree that simply deprecating/discouraging the use of tabindex values greater 0 is not enough, and I would of course also settle for "warning" instead of "error" in the validator, but something has to be done to try and get rid of this mess that is, in large parts and with probably only a few exceptions, tabindex > 0.

capturing comments from cloned bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27089

 Dirk Schulze 2014-10-17 05:03:48 UTC

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

[reply] [−] Comment 2 Marco Zehe 2014-10-17 08:18:00 UTC

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.

[reply] [−] Comment 3 Dirk Schulze 2014-10-17 08:49:23 UTC

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.

[reply] [−] Comment 4 steve faulkner 2014-10-17 09:16:15 UTC

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

I grepped for tabindex="1|2|3"  in a set of 1000 random website URLs i gathered recently (using http://www.uroulette.com/)

I found approx 120 pages of of 1000.

Here is a zip file containing the HTML of those 120 http://www.html5accessibility.com/HTMLdata/tabindex.zip 

I have started to look at how the tabindex usage in these pages effects logical focus order, will report back when I have some analysis

feel free to dig into the pages yourselves.

I have created a wiki page to capture discussion on issue https://www.w3.org/wiki/HTML/Usage/tabindex ,anybody feel free to edit

(In reply to Marco Zehe from comment #2)
> As I write above, I don't know of any site which uses tabIndex with a
> positive integer value correctly. On the contrary, all support/advice
> inquiries I get have to do with the fact that it is being misused, primarily
> due to lack of awareness.

It's rare I admit, but I've seen a few examples that would be difficult to implement without positive tabindex values. The one that comes to mind was using a generated tabindex on a "Google Maps" section of a non Google page, interspersing the tabindex of the active map flag in between the tabindex values in the list of search results. Since the Google maps markup was very inaccessible, this was the only logical way to skip over the extraneous maps tiles to jump directly from the search result, to the map, and then back to the search result.

I support "discouraging" use of position tabindex values w/o a good reason, but I would stop short of making them invalid.

HTML5.1 Bugzilla Bug Triage: Incubation needed

This idea will need a bit more bake-time before it is ready for consideration in the spec... Sounds like a positive change, but browsers will need to try this out and see how it impacts web compat more than likely...

This bug constitutes a request for a new feature of HTML. The current guidelines [1], rather than track such requests as bugs or issues, please create a proposal outlining the desired behavior, or at least a sketch of what is wanted (much of which is probably contained in this bug), and start the discussion/proposal in the WICG [2]. As your idea gains interest and momentum, it may be brought back into HTML through the Intent to Migrate process [3].
[1] https://github.com/w3c/html#contributing-to-this-repository
[2] https://www.w3.org/community/wicg/
[3] https://wicg.github.io/admin/intent-to-migrate.html