This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
QUOTE cite="http://dev.w3.org/html5/spec/editing.html#the-accesskey-attribute" When the user presses the key combination corresponding to the assigned access key [1] for an element, if the element defines a command [2], and the command's Hidden State facet [3] is false (visible), and the command's Disabled State facet [4] is also false (enabled), then the user agent must trigger the Action [5] of the command. User agents may expose elements that have an accesskey [6] attribute in other ways as well, e.g. in a menu displayed in response to a specific key combination. The accessKey IDL attribute must [7]reflect the [8]accesskey content attribute. UNQUOTE note: "reflect" is defined as: QUOTE cite="http://dev.w3.org/html5/spec/common-dom-interfaces.html#reflect" Some IDL attributes are defined to reflect a particular content attribute. This means that on getting, the IDL attribute returns the current value of the content attribute, and on setting, the IDL attribute changes the value of the content attribute to the given value. UNQUOTE note: "Action" is defined as: QUOTE cite="http://dev.w3.org/html5/spec/commands.html#command-facet-action" The actual effect that triggering the command will have. This could be a scripted event handler, a URL to which to navigate, or a form submission UNQUOTE PROBLEM: the user MUST be able to control whether the Action taken is to move focus to the element for which the accesskey has been defined or to activate that element. this is a basic requirement in order for accesskey to use for the class of users who use them primarily to navigate elements and those who use them primarily to activate elements; currently the HTML5 spec does not address this directly in its definition of the accesskey attribute, and the pointer to the definition of "Action" as quoted above does not make it clear that the Action that results from an accesskey+modifier keypress may be to activate the element or to move focus to the element, in observance of user settings; if the user has not set a modifier key to use to activate an accesskey, a user agent may assign one, provided that it notifies the user which modifier key or keys have been assigned by the user agent. References 1. http://dev.w3.org/html5/spec/editing.html#assigned-access-key 2. http://dev.w3.org/html5/spec/commands.html#concept-command 3. http://dev.w3.org/html5/spec/commands.html#command-facet-hiddenstate 4. http://dev.w3.org/html5/spec/commands.html#command-facet-disabledstate 5. http://dev.w3.org/html5/spec/commands.html#command-facet-action 6. http://dev.w3.org/html5/spec/editing.html#the-accesskey-attribute 7. http://dev.w3.org/html5/spec/common-dom-interfaces.html#reflect 8. http://dev.w3.org/html5/spec/editing.html#the-accesskey-attribute
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: There's no reason to believe the element in question would be focusable. For example, <command> elements aren't even normally visible, let alone focusable. What should happen in that case?
The HTML a11y bug triage sub-team thinks Gregory should provide more information. 10888 would be the master bug for all accesskey related issues.
The accessibility TF bug-triage sub-team thinks this bug is handled well by Gregory and it doesn't require the attention of the whole TF.