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 10252 - HTML5 hard-binds "Action" to accesskey key-press
Summary: HTML5 hard-binds "Action" to accesskey key-press
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: LC
Assignee: Charles McCathieNevile
QA Contact: HTML WG Bugzilla archive list
Keywords: a11y, a11ytf, a11y_focus
Depends on:
Reported: 2010-07-28 21:05 UTC by Gregory J. Rosmaita
Modified: 2014-05-01 15:47 UTC (History)
11 users (show)

See Also:


Description Gregory J. Rosmaita 2010-07-28 21:05:32 UTC
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.

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=""
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)

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;
Comment 1 Ian 'Hixie' Hickson 2010-08-18 18:04:34 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: 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.
Comment 2 Michael Cooper 2010-08-31 13:31:23 UTC

The bug triage sub-team recommends the accessibility task force follow this.
Comment 3 Michael Cooper 2011-02-03 16:27:49 UTC
Assign to John to follow with Gregory
Comment 4 Charles McCathieNevile 2012-11-20 23:45:56 UTC
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...)
Comment 5 Mark Sadecki 2013-10-23 19:45:40 UTC
a11ytf decision to move to

New bug: