This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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. PROPOSAL: 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 (http://dev.w3.org/html5/spec/editing#activation) Add a link on the word 'focuses' to #focus-management (http://dev.w3.org/html5/spec/editing#focus-management ). Optionally: In addition, add a sentence or a note which clarifies it more directly. JUSTIFICATION - AUTHORS: 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> [*] http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0295 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: http://www.w3.org/2004/12/hypermail-w3c-patch/patch/w3c-0.50.patch ) JUSTIFICATION - USER AGENTS: 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. [[ [*] http://dev.w3.org/html5/spec/editing#introduction-6 However, HTML5 spec should spell it out more directly, so that authors as well as implementors do get this important detail right.
mass-moved component to LC1
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: Rejected Change Description: no spec change Rationale: The premise of the bug is false. accesskey="" always has an effect.