This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23960 - FKA: Need contextual scoping for tabindex
Summary: FKA: Need contextual scoping for tabindex
Status: RESOLVED WONTFIX
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other All
: P3 enhancement
Target Milestone: Needs Impl Interest
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
: 24105 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-12-02 23:23 UTC by Ian 'Hixie' Hickson
Modified: 2017-07-21 10:54 UTC (History)
7 users (show)

See Also:

Attachments

Description Ian 'Hixie' Hickson 2013-12-02 23:23:44 UTC 
Right now, a non-Web-components widget with multiple tab stops can't define its tab order, because to do so it would have to actually manage the tabindex values of all the focusable controls in the page.

Might be interesting to define some sort of scoping mechanism to fix that.

Alternatively, maybe this just gets fixed with Web components and we don't need to actually address it in HTML itself, I don't know.
Comment 1 Ian 'Hixie' Hickson 2013-12-16 21:52:35 UTC 
*** Bug 24105 has been marked as a duplicate of this bug. ***
Comment 2 Silvia Pfeiffer 2014-01-30 23:25:01 UTC 
I think it still makes sense to have a tabindex scope, since not all complex interaction elements on a Web page are implemented as Web-components. Unless the idea is to encourage everyone to do so.
Comment 3 Ian 'Hixie' Hickson 2014-02-07 18:21:23 UTC 
Right now no complex interaction elements on a Web page are implemented as Web components, since they don't exist. But presumably eventually they will.
Comment 4 James Craig 2014-02-10 18:59:17 UTC 
Bradley Meck has some sketched ideas here regarding tabindex scoping (proposed @tabwrap, @tabtarget, @tabwrapper) that could be applied generally and as default values to existing cases like shadow DOM components and frames.

https://github.com/bmeck/fm.js/wiki
Comment 5 James Craig 2014-02-10 19:02:22 UTC 
From the original bug 23871:

There is no contextual scoping for tabindex, so any web app attempting to maintain a non-DOM-ordered tab order has to manage focus for every focusable element in the DOM, when the scoping could behave more like positioning contexts in CSS.

I noticed that Léonie added the accessibility keywords, so I just wanted to clarify that this not an assistive technology issue, as ATs like screen readers have the ability to navigate non-linearly in a variety of ways.

This bug is about the fact that HTML is generally tedious to navigate with a keyboard, and while it's possible to resolve some of these problems in web applications using focus management techniques like "roaming tabindex", it's a non-trivial amount of work. HTML should not require authors to do an exorbitant amount of work to implement a usable keyboard behavior in web applications, regardless if their need is related to accessibility, personal preference, or general usability.
Comment 6 Anne 2017-07-21 10:54:38 UTC 
If this is still desired, please file a new issue at https://github.com/whatwg/html/issues/new.