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 13579 - Clarify behavior of accesskey on static content elements
Summary: Clarify behavior of accesskey on static content elements
Status: CLOSED NEEDSINFO
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Greg Lowney
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, a11y_ua
Depends on: 13555
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-03 05:46 UTC by Greg Lowney
Modified: 2014-02-26 18:55 UTC (History)
10 users (show)

See Also:


Attachments

Description Greg Lowney 2011-08-03 05:46:02 UTC
It is extremely useful to be able to define keyboard shortcuts for the sole purpose of navigation, rather than activation, and without visible links. HTML5 allows accesskey elements, even if they are not focusable and have no associated action, which would trigger a click event to the element (per 4.11.5.8 Using the accesskey attribute to define a command on other elements). However, the spec should more clearly state that when the users presses the accesskey they should effectively navigate to the element. If the element is not focusable, it should still be scrolled into view, any future sequential navigation or search would start at this location, etc.

Use case: Jeanine is creating a web page, and wants to define a shortcut that would assist users with disabilities by moving the keyboard focus and point of regard to a specific heading in the page. However, she doesn't want to have a link to that location be visible on the page, so she merely assigns an accesskey attribute to the heading. The documentation tells users that they can press that accesskey to navigate to the appropriate section of the document.
Comment 1 Michael[tm] Smith 2011-08-04 05:15:03 UTC
mass-move component to LC1
Comment 2 Joshue O Connor 2011-08-07 08:21:08 UTC
I am curious as how the suggested @accesskey mappings would work in conjunction with the new HTML 5 elements that define web page functionality? Are we in danger of element bloat and how will Assistive Technologies harmonise these new elements in HTML 5 with existing user functions like skipping headings by pressing the 'H' key, 'on top' of more author defined accesskeys?

We are yet to see support for many of the new HTML 5 elements in AT, will resurrecting accesskeys make implementation of the spec more complex and prone to error?
Comment 3 Michael[tm] Smith 2011-11-20 15:21:32 UTC
Greg, this bug is waiting on your response to comment #2:
> I am curious as how the suggested @accesskey mappings would work in conjunction
> with the new HTML 5 elements that define web page functionality? Are we in
> danger of element bloat and how will Assistive Technologies harmonise these new
> elements in HTML 5 with existing user functions like skipping headings by
> pressing the 'H' key, 'on top' of more author defined accesskeys?
> 
> We are yet to see support for many of the new HTML 5 elements in AT, will
> resurrecting accesskeys make implementation of the spec more complex and prone
> to error?
Comment 4 Leif Halvard Silli 2011-11-22 04:14:08 UTC
(In reply to comment #0)

Do you suggest:

   a)  that elements with the accesskey should be focusable in AT by default, inline with what HTML5's section on 'Focus management' says about how different UAs can make different elements focusable: """An element is focusable if the user agent's default behavior allows it to be focusable""" ?
   b) or do you - as I am more inclined to think - simply suggest that if we have the element
      <div id=foo accesskey=a >Foo text.</div>
then, activation of the accesskey should have the same effect as clicking the link
      <a href=#foo>Go to foo text.</a>
       ?
  c)  or do you mean a third thing - like what I think Joshue talks about?

The thing I wonder about the most is your following statement:

> any future sequential navigation or search would 
> start at this location, etc.

Fact is that, if we consider the effect of following a *link* to fragment #foo, then "navigation or search" does *not* start from this location. But perhaps, in AT - at least some AT - this is different? I wish "normal" browsers *did* behave like you say. But tend to not do that.

Btw, in bug 12709, I propose that accesskeys on unfocusable elements, should default to be hidden from the user so as not to confuse him or her with accesskeys that do work. And this bug, seems to support what I propose in 12709 - as you suggest that the accesskeys on non-focusable elements should only be revealed to AT.

Btw: How does your proposal fit with an element that has been made focusable e.g. via an onClick() event , but which doesn't have @accesskey ? E.g. what if a script "suddenly" makes the element focusable? (The same question could probably be asked about bug 12709.)
Comment 5 Ian 'Hixie' Hickson 2011-11-24 02:50:27 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: Did Not Understand Request
Change Description: no spec change
Rationale: I don't understand. Can you be more specific about what in the spec needs changing here?