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 src="http://dev.w3.org/html5/spec/commands.html#command-facet-action" When the user presses the key combination corresponding to the assigned access key for an element, if the element defines a command, and the command's Hidden State facet is false (visible), and the command's Disabled State facet is also false (enabled), then the user agent must trigger the Action of the command. UNQUOTE PROBLEM 1. this is at variance with the User Agent Accessibility Guidelines -- the solution provided by the Access Module/Element's architecture, is a boolean attribute "activate" which allows an author to set the AccessKeyPress to either move focus to the object for which the accesskey is defined (activate="no") or whether the AccessKeyPress results in the activation of the element to which the accesskey has been assigned (activate="yes") PROBLEM 2. the Access Module/Element's "activate" attribute also provides the following, which is lacking in the HTML5 draft: QUOTE src="http://www.w3.org/TR/xhtml-access/#sec_3.1.1." User agents MUST provide mechanisms for overriding the author setting with user-specified settings in order to ensure that the act of moving content focus does not cause the user agent to take any further action (as per Checkpoint 9.5 of UAAG 1.0) UNQUOTE REQUIREMENT: the user MUST be able to toggle between accesskey moves focus to associated element, or to have that element activated, in accordance with a user setting; NOTE: this implies strongly that focus/activate SHOULD: a) provide a toggle as to default action; b) provide an extra modifier (for example, ModifierKey1+Accesskey to focus and ModifierKey2+Accesskey to activate, or ModifierKey1+Accesskey to focus and ModifierKey2+ModifierKey1+Accesskey to activate;
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. Could you elaborate? What are the reasons for these requests, other than this being how other specs are written? If you reopen this bug, please select a single issue to reopen this bug for, and file new bugs for other issues. Ideally, please just open new bugs for each issue and don't reopen this one.
http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0013.html The bug triage sub-team recommends the accessibility task force follow this.
Assign to John to follow with Gregory http://www.w3.org/2011/02/03-html-a11y-minutes.html#item01
I think the bug here is that the spec is very prescriptive about how user interaction should be handled. When a user triggers an accesskey, it makes perfect sense for the author to suggest whether it is more logical to focus some control, or actually activate it. But the spec is IMHO, too prescriptive. It takes what should be a hint - what the author thinks is going to happen - and requires that this is exactly what happen. User agents should enable users to do things like focus on the thing the accesskey applies to, and then try to inspect it, or conversely to directly activate it. Default behaviour is likely to be what the author expected, and in "normal" circumstances probably should. But there are circumstances where this is insufficient. (Beyond this, the idea that there is a key combination to trigger an accesskey is far too narrow an understanding of how actual user agents work...)
a11ytf decision to move to HTML.next: http://www.w3.org/2013/10/17-html-a11y-minutes.html#item04 New bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23611