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 27020 - Sequential focus navigation algorithm should include non-focusable elements
Summary: Sequential focus navigation algorithm should include non-focusable elements
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P1 enhancement
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-10 20:15 UTC by rob
Modified: 2016-04-20 21:31 UTC (History)
6 users (show)

See Also:


Attachments

Description rob 2014-10-10 20:15:07 UTC
The sequential focus navigation algorithm [SFN] only specifies the behavior for focusable elements. This should be extended with non-focusable elements.

This is in particularly relevant for reference fragment navigations. E.g. when the user visits page.html#refid (<h3 id=refid>), then the SFN should select the next focusable element *after the refid anchor*, instead of the top of the document. Most implementations (except Firefox) currently jump to the top of the page. This is unnatural, and Chrome wants to implement something like what I described (https://crbug.com/262171).

See https://www.w3.org/Bugs/Public/show_bug.cgi?id=26907 and the bottom of https://crbug.com/417636#c3 for more context and test cases.

When non-focusable elements are included, other situations need to be accounted for as well, such as:
- Element removal (should the SFN continue at the nearest non-disconnected ancestor node, or should the SFN continue at the top of the document?)
- Focusing steps (should the node.focus() method affect SFN?)
- Change of focusability (e.g. removing the tabindex attribute)


[SFN] https://html.spec.whatwg.org/multipage/interaction.html#sequential-focus-navigation
Comment 1 Michael[tm] Smith 2015-06-16 11:35:35 UTC
Raising priority and noting as requiring a minor "feature tweak" to an existing feature.
Comment 2 Arron Eicholz 2016-04-20 21:25:06 UTC
HTML5.1 Bugzilla Bug Triage: 

This bug constitutes a request for a new feature of HTML. Our current guidelines, rather than track such requests as bugs or issues, is to create a proposal for 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 (https://www.w3.org/community/wicg/). As your idea gains interest and momentum, it may be brought back into HTML through the Intent to Migrate process (https://wicg.github.io/admin/intent-to-migrate.html).
Comment 3 Domenic Denicola 2016-04-20 21:31:56 UTC
This is fixed in the HTML Standard, FYI: https://github.com/whatwg/html/commit/b466ad7ce49676873ddade4c473b7c983803bfd4 (https://github.com/whatwg/html/pull/732)