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 16186 - HTML 5 missing explicit directives for support full keyboard access (FKA) when navigating to a fragment identifier
Summary: HTML 5 missing explicit directives for support full keyboard access (FKA) whe...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Charles McCathieNevile
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard: whatwg-resolved
Keywords: a11y, a11ytf, a11y_focus
: 16385 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-03-01 19:58 UTC by James Craig
Modified: 2016-02-26 19:32 UTC (History)
13 users (show)

See Also:

Attachments

Description James Craig 2012-03-01 19:58:45 UTC 
HTML 5 missing explicit directives for support full keyboard access (FKA) when navigating to a fragment identifier:

Following a hyperlink:
http://www.w3.org/TR/html5/links.html#following-hyperlinks
"When a user follows a hyperlink created by an element, the user agent must resolve the URL given by the href attribute of that element, relative to that element, and if that is successful, must navigate a browsing context to the resulting absolute URL."

Navigate:
http://www.w3.org/TR/html5/history.html#navigate
"Fragment identifiers: If the absolute URL of the new resource is the same as the address of the active document of the browsing contextbeing navigated, ignoring any <fragment> components of those URLs, and the new resource is to be fetched using HTTP GET or equivalent, and the absolute URL of the new resource has a <fragment> component (even if it is empty), then navigate to that fragment identifier and abort these steps."

Navigating to a fragment identifier:
http://www.w3.org/TR/html5/history.html#scroll-to-fragid
"When the user agent is required to scroll to the fragment identifier, it must change the scrolling position of the document using the scroll an element into view algorithm defined in the CSSOM View specification, or perform some other action, such that the indicated part of the document is brought to the user's attention."

The phrase "perform some other action such that…[the anchor]…is brought to the user's attention" is vague, but focusing the anchor is clearly the action that should be performed if full keyboard access (FKA) is enabled.

Filing this defect against HTML 5 Accessibility to get the spec to explicitly state the UA must move focus to that element if focusable, and perhaps something about moving the browsing context focus there even if it's not "focusable" and therefore can't provide a DOM focus event. For example, if the linked anchor is a non-focusable heading, pressing Tab should move to the next focusable item past the heading, even if the heading itself was not the focused document.activeElement.

This should also cover the case were a user just loads a URL with a fragID (like the ones above) without actually clicking the link.
Comment 1 Ian 'Hixie' Hickson 2012-03-02 20:29:57 UTC 
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: This is a UI issue, we can't and shouldn't require a particular behaviour. It's up to the UA to do what they think is best for their users.
Comment 2 James Craig 2012-03-02 21:03:06 UTC 
If you really believe that, you should take out the requirement to scroll the view, too. Reopening.
Comment 3 Michael Cooper 2012-03-20 15:22:23 UTC 
Discussed in HTML Accessibility TF bug triage meeting 20 March 2012 http://www.w3.org/2012/03/20-a11y-bugs-minutes.html. We agree with the focus suggestions. We had questions about what truly should be left to the User Agent / User Interface, vs what should spec'd. We see need for UAs to distinguish on UI but setting focus is not a UI thing per se, it's a core accessibility need. How UAs do that specifically can be the UI differentiation. Therefore this is an issue the HTML A11y TF should follow.
Comment 4 Simon Pieters 2012-03-20 15:35:15 UTC 
*** Bug 16385 has been marked as a duplicate of this bug. ***
Comment 5 Simon Pieters 2012-03-20 15:38:09 UTC 
I think this isn't purely UI since focus is exposed to scripts.

(Make sure this works also "If the scrolling fails because the relevant ID has not yet been parsed" if you spec this.)
Comment 6 contributor 2012-07-18 07:29:28 UTC 
This bug was cloned to create bug 17987 as part of operation convergence.
Comment 7 James Craig 2012-08-27 18:16:57 UTC 
*** Bug 17987 has been marked as a duplicate of this bug. ***
Comment 8 Charles McCathieNevile 2014-12-18 15:12:56 UTC 
The current spec has:
1. Let target be the indicated part of the document, as defined below.
2. If target is the top of the document, then scroll to the beginning of the document for the Document, and abort these steps. [CSSOMVIEW]
3. Use the scroll an element into view algorithm to scroll target into view, with the align to top flag set. [CSSOMVIEW]
4. If target is a focusable element, run the focusing steps for that element.

Seems to me that this meets the request. James?
Comment 9 Charles McCathieNevile 2014-12-18 15:13:46 UTC 
Sorry, link for previous statement: http://www.w3.org/TR/html5/browsers.html#scroll-to-fragid
Comment 10 Charles McCathieNevile 2015-06-12 14:25:13 UTC 
If the target isn't a focusable element, focus should go to the first thing after the fragment...
Comment 11 Takeshi Kurosawa 2016-02-24 04:15:51 UTC 
FYI: WHATWG HTML Standard is discussing this issue at
https://github.com/whatwg/html/pull/726
Comment 12 Charles McCathieNevile 2016-02-26 19:32:04 UTC 
Should be fixed by https://github.com/w3c/html/pull/103 (which matches Takeshi's change)