This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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. Discussion from bug 23366
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 techniques like "roaming tabindex" and other "focus management" techniques, it's a non-trivial amount of work. HTML should not require authors to do an exorbitant amount of work to implement a useable keyboard behavior in web applications, regardless if their need is related to accessibility, personal preference, or general usability.
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
feature request (but one that makes sense)
This should probably be added to the interaction discussion in general that is taking place in WICG: https://discourse.wicg.io/t/user-interaction-with-web-apps/1177/13 since it is a feature request. Not that Shadow DOM looks like it will (have to) permit this locally, which is an alternative solution of sorts.