10780 2010-09-27 18:06:38 +0000 reference to definition of Action insufficient for definition of accesskey 2013-10-23 19:59:21 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified All All RESOLVED NEEDSINFO a11y, a11y_focus P2 normal LC 10888 23613 1 oedipus chaals ian joshue.oconnor laura.lee.carlson mike oedipus public-html-a11y public-html-admin public-html-wg-issue-tracking w3c public-html-bugzilla oldest_to_newest 39600 0 oedipus 2010-09-27 18:06:38 +0000 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 39685 1 ian 2010-09-28 07:09:06 +0000 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? 42317 2 w3c 2010-11-09 16:23:17 +0000 The HTML a11y bug triage sub-team thinks Gregory should provide more information. 10888 would be the master bug for all accesskey related issues. 43504 3 w3c 2010-12-21 16:18:52 +0000 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.