W3C home > Mailing lists > Public > public-pfwg@w3.org > October 2014

RE: Proposal to change documentation on tabindex to strongly discourage values greater 0

From: Cynthia Shelly <cyns@microsoft.com>
Date: Thu, 23 Oct 2014 13:46:35 +0000
To: James Craig <jcraig@apple.com>, Marco Zehe <mzehe@mozilla.com>
CC: "public-html@w3.org" <public-html@w3.org>, W3C WAI Protocols & Formats <public-pfwg@w3.org>
Message-ID: <2d884403118347fab63fe5f1e9805c18@BLUPR03MB166.namprd03.prod.outlook.com>
In my experience, if you need to use tabindex<1, it's an indication that you've made other mistakes.  Case in point: "Since the Google maps markup was very inaccessible..."

I agree that discouraging it is the right plan, at least in the short term.  I'd like us to try to craft some validator language, or a document of some sort (wcag failure?) describing what the likely underlying issues are and how to approach fixing them over time.

Sent from my Windows Phone
From: James Craig<mailto:jcraig@apple.com>
Sent: 10/23/2014 12:06 AM
To: Marco Zehe<mailto:mzehe@mozilla.com>
Cc: public-html@w3.org<mailto:public-html@w3.org>; W3C WAI Protocols & Formats<mailto:public-pfwg@w3.org>
Subject: Re: Proposal to change documentation on tabindex to strongly discourage values greater 0

On Oct 16, 2014, at 6:09 AM, Marco Zehe <mzehe@mozilla.com<mailto:mzehe@mozilla.com>> wrote:

[CC'ing Public PFWG list for info]

Hello all!

This is a proposal to declare tabIndex values > 0 invalid in the spec and the validator, or at least strongly advise against the use of positive integers values for this attribute.
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. 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.

Proper usage of the third class is 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.

Received on Thursday, 23 October 2014 13:47:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:45:10 UTC