Bug 17987 - 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...
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
Depends on:
Reported: 2012-07-18 07:29 UTC by contributor
Modified: 2012-10-11 02:41 UTC (History)
8 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description contributor 2012-07-18 07:29:24 UTC
This was was cloned from bug 16186 as part of operation convergence.
Originally filed: 2012-03-01 19:58:00 +0000
Original reporter: James Craig <jcraig@apple.com>

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

Following a hyperlink:
"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."

"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:
"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.
 #1   Ian 'Hixie' Hickson                             2012-03-02 20:29:57 +0000 
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.
 #2   James Craig                                     2012-03-02 21:03:06 +0000 
If you really believe that, you should take out the requirement to scroll the view, too. Reopening.
 #3   Michael Cooper                                  2012-03-20 15:22:23 +0000 
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.
 #4   Simon Pieters                                   2012-03-20 15:35:15 +0000 
*** Bug 16385 has been marked as a duplicate of this bug. ***
 #5   Simon Pieters                                   2012-03-20 15:38:09 +0000 
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 1 Ian 'Hixie' Hickson 2012-07-20 04:23:14 UTC
The scrolling is not required either. What is required is that the UA "scroll [...] or perform some other action". This is intentionally wide open.

The focus thing is not a script interop issue because scripts can't depend on it happening (it doesn't happen for most people) and they can't depend on it not happening (the user is always free to move the focus around arbitrarily).
Comment 2 James Craig 2012-07-26 08:36:19 UTC
This is a valid accessibility bug. Please stop closing it prematurely.
Comment 3 Ian 'Hixie' Hickson 2012-07-26 23:24:12 UTC
Please do not reopen bugs in this component without including new information that explains why the resolution was incorrect. If the issue is not trivial, I encourage you to instead raise it on the whatwg@whatwg.org mailing list; discussion is generally best kept on the list and the bug system best kept for simple and obvious bugs. Thanks. If you have any questions about this process that are not covered by the WHATWG FAQ, please don't hesitate to e-mail me directly for clarifications.
Comment 4 James Craig 2012-08-27 18:16:57 UTC
Leaving this closed because Bug 16186 covers the original accessibility need for focus. Simon Pieters, if you still need this with regards to your script comment, feel free to reopen, but you may want to change the title too, as it appears Ian is not reading the comments.

Changing resolution from WONT FIX to DUPLICATE of 16186.

*** This bug has been marked as a duplicate of bug 16186 ***
Comment 5 Edward O'Connor 2012-08-27 18:40:29 UTC

The bugs are not duplicates—they are clones that cover two different documents. This bug is on the WHATWG specification, whereas bug 16186 is on the HTML WG's specification.

I've restored Ian's resolution, as he does not plan to address this in the WHATWG document.
Comment 6 Ian 'Hixie' Hickson 2012-10-11 02:41:07 UTC
To be more precise, I think the spec already does address this adequately.