[Bug 16186] New: HTML 5 missing explicit directives for support full keyboard access (FKA) when navigating to a fragment identifier

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16186

           Summary: HTML 5 missing explicit directives for support full
                    keyboard access (FKA) when navigating to a fragment
                    identifier
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: jcraig@apple.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


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.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Thursday, 1 March 2012 20:04:08 UTC