This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
mass-move component to LC1
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?
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?
(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.)
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?