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 12708 - @accesskey: Clarify what it needs in order to have effect
Summary: @accesskey: Clarify what it needs in order to have effect
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC All
: P3 normal
Target Milestone: ---
Assignee: contributor
QA Contact: HTML WG Bugzilla archive list
Keywords: a11y
Depends on:
Reported: 2011-05-20 02:09 UTC by Leif Halvard Silli
Modified: 2011-12-02 00:45 UTC (History)
6 users (show)

See Also:


Description Leif Halvard Silli 2011-05-20 02:09:50 UTC
ISSUE: In HTML5, @accesskey has become a global attribute - it isn't limited to only interactive elements anymore. Therefore the fact that @accesskey relies on the element being focusable or specially focusable in order to have an effect, should be emphasized.


Inside the second sentence of #the-accesskey-attribute section:
     ]] The accesskey attribute's value is used by the user agent as a guide for creating a keyboard shortcut that activates or focuses the element.[[,

Add a link on the word 'activates' to #activation (
Add a link on the word 'focuses' to #focus-management ( ). 

Optionally: In addition, add a sentence or a note which clarifies it more directly.


  Evidence hints that authors sometimes are confused about what @accesskey needs in order to have any effect. For instance, in W3C's online mailinglist archives, accesskey="j" is attached to an unfocusable anchor element (without @href attribute): [*]
 <a name="start295" accesskey="j" id="start295"></a>

  The intention of the above code is clearly to help readers to  focus on the message body of each message. However, the accesskey has zero effect (in Opera, Firefox and Safari) since the element is unfocusable. Thus, Opera/Firefox/Safari are correctt in not making the above element accessible via accesskey. (If the mailinglist archive software had added @tabindex too, then it would/should have worked - but this apparently wasn't realized when the software was patched: )


   Opera, Safari, Chrome, Internet Explorer and Firefox deviate slightly from one another when it comes to the effect of @acckesskey. Probably because they don't link #focus-management and #activation to @accesskey in the same way. E.g. an element with @accesskey plus @tabindex will, in Opera  (and, with certain add-ons, in Firefox too)  fire @onFocus events and @onClick events  when the accesskey is activated, whereas other UAs do not seem to perform anything. (Firefox with the Pentadactyl add-on works a bit like Opera.)

JUSTIFICATION - SPEC CLARITY:  When read with great attention, the HTML5 does hint that the element has to be able to take focus (or be activated), before @accesskey can be expected have any effect:

]] Each element that can be activated or focused can be assigned a single key combination to activate it, using the accesskey attribute. [[

However,  HTML5 spec should spell it out more directly, so that authors as well as implementors do get this important detail right.
Comment 1 Michael[tm] Smith 2011-08-04 05:06:32 UTC
mass-moved component to LC1
Comment 2 Ian 'Hixie' Hickson 2011-12-02 00:45:30 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:

Status: Rejected
Change Description: no spec change
Rationale: The premise of the bug is false. accesskey="" always has an effect.