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 10780 - reference to definition of Action insufficient for definition of accesskey
Summary: reference to definition of Action insufficient for definition of accesskey
Status: RESOLVED NEEDSINFO
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: LC
Assignee: Charles McCathieNevile
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, a11y_focus
Depends on:
Blocks: 10888 23613
  Show dependency treegraph
 
Reported: 2010-09-27 18:06 UTC by Gregory J. Rosmaita
Modified: 2013-10-23 19:59 UTC (History)
9 users (show)

See Also:


Attachments

Description Gregory J. Rosmaita 2010-09-27 18:06:38 UTC
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
Comment 1 Ian 'Hixie' Hickson 2010-09-28 07:09:06 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:
   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?
Comment 2 Martin Kliehm 2010-11-09 16:23:17 UTC
The HTML a11y bug triage sub-team thinks Gregory should provide more information. 10888 would be the master bug for all accesskey related issues.
Comment 3 Martin Kliehm 2010-12-21 16:18:52 UTC
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.