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 10888 - Access Command Requirements for HTML5
Summary: Access Command Requirements for HTML5
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P2 major
Target Milestone: ---
Assignee: Charles McCathieNevile
QA Contact: HTML WG Bugzilla archive list
Keywords: a11y, a11ytf, a11y_focus
Depends on: 10779 10780 10782 11140 23612 23615
Blocks: 10772 10774 10775 10776 10777 10778 10905 10994 23611 23613 23614 23616
  Show dependency treegraph
Reported: 2010-09-30 18:47 UTC by Gregory J. Rosmaita
Modified: 2014-05-01 15:46 UTC (History)
11 users (show)

See Also:


Description Gregory J. Rosmaita 2010-09-30 18:47:05 UTC

The term "access command" is defined as a means of (1) invoking a 
command or function of a web application, or (2) moving focus to 
the element allowing a subsequent gesture to activate that 
element's associated command or function. Furthermore, a set of 
access commands defines a navigational sequence among the command 

Note that "access command" is more general than the legacy concept 
of "accesskey", and emphasizes access to functionality. As such it 
is intended to distance these requirements from the legacy deployment 
and poor reputation of accesskey as defined by HTML 4x.


The WAI Protocols and Formats Working Group has forwarded the following 
requirements for keyboard access functionality in HTML 5 to the HTML 
A11Y Task Force which did not have any objections to these requirements
and which asked that these requirements be logged as a bug. 

Potential Uses of Access Command

The following are potential uses of access command as easy to define 
shortcut keys:

    * Moving keyboard focus to specific form controls or widgets 
      (shortcut key)
          * This is important where someone need to fill out forms 
            on a frequent basis and there are certain controls that 
            the user needs to go to quickly to reduce the time to 
            fill out the form. 
    * Form submission
    * Moving focus to a specific link
    * Activation of a specific link (go to another resource or location 
      in the same resource)
    * Move focus to a nav element or to a link in a nav element
    * Starting and stopping playing audio and video
    * Incrementing the time line of audio and video
    * Incrementing the playback rate of an audio or video resource
    * In drag and drop picking up a specific dragable item
    * In drag and drop moving focus to a specific droppable location 


Requirement 1: A device independent means to activate an access command.

    * Explanatory Note for Requirement 1: @accesskey, today, requires 
      the author to set a pre-defined key yet this key may or may not 
      work on certain browsers, operating systems, and/or devices. 
      Therefore, the ability for the user to request a key mapping, 
      and have the user agent make the assignment, is essential. 

Requirement 2: Ability for an author to define a default access command 
mapping, and for a user to override the default mapping

    * UA implementation note: the default access mapping and user 
      override mapping must be sharable and storable. 

Requirement 3: Access commands should default to focus behaviour;

Explanatory note for Requirement 3: If no user or author behaviour is 
specified, a clear default should be used, in most cases this should 
default to a focus behaviour.

    * UA Implementation Notes
          * user agents must allow users to specify whether the default 
            behaviour focuses or activates the target;

          * the default access mapping and user override mapping must 
            be sharable and storable. 

Requirement 4: Ability for an author to provide a description for an 
access command assignment; the user agent should recognize and describe 
user overrides; 

    * Explanatory note for Requirement 4: This is a glaring omission 
      in @accesskey today. Today, even if the author does assign an 
      accesskey, the user agent has no way of conveying to the user 
      what it is for. Descriptions could be built from the semantics 
      of the elements pointed to. 

    * UA Implementation Note: Such descriptions should be storable and 

Requirement 5: Ability to specify the target elements that will respond 
to an access command, based on their id reference.

    * Explanatory note for Requirement 4: This allows the author to 
      define a set of targets to be navigated to in order. The user 
      agent would be responsible for cycling through these in DOM 

Requirement 6: Ability to specify target elements in terms of their role, 
or implied ARIA semantics for the role if not overridden by ARIA.

    * Explanatory note: This allows the author to define a set of 
      targets to be navigated to in order. The user agent would be 
      responsible for cycling through these in DOM order. References: 
      Annotations for Assistive Technology Products (ARIA) from the 
      HTML5 editor's draft 

Requirement 7: Ability to specify a custom order for cycling through 
multiple objects attached to a single access command.

Requirement 8: As long as the document is loaded in the browser, user 
agents must be able to return the user to their previous place in the 
navigation sequence.

    * Explanatory notes for Requirement 8:As an example, @tabindex is 
      used to define a navigational sequence that allows users to move 
      focus forwards and backwards among a set of elements. 

Requirement 9: Access command mappings should be available at the 
beginning of the document.

    * Explanatory note 1 for Requirement 9: Some DOM based assistive 
      technologies coulg quickly access the mapping shortcuts versus 
      having to walk the DOM. Descriptions could be built from the 
      semantics of the elements pointed to.

    * Explanatory note 2 for Requirement 9: Additionally, a user 
      should be able to designate a specific keyboard layout so that 
      the user agent can respond appropriately to user input 

PF thanks LĂ©onie Watson and Gregory Rosmaita for helping pull these 
requirements together. Thanks to Joseph Scheuhammer for helping us 
clarify our meaning, and Jon R. Gunderson, for providing use cases. 
Thanks also to everyone who participated in our WBS on these 
requirements, and to Richard Schwerdtfeger who created our first 
requirements draft many many months ago. Thanks to the members of 
the User Agent Accessibility working group for reviewing and 
contributing to these requirements on a very tight schedule.
Comment 1 Ian 'Hixie' Hickson 2010-10-11 21:45:47 UTC
Could you clarify exactly what change you are requesting and what problem that change resolves?
Comment 2 Ian 'Hixie' Hickson 2010-10-12 10:40:00 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: see comment 1
Comment 3 Martin Kliehm 2010-10-19 16:07:13 UTC
HTML accessibility TF bug triage sub-team adding a11yTF keyword because we think this should be TF priority, assigning it to Gregory for clarification when the PF has defined the concept.
Comment 4 Greg Lowney 2012-01-16 21:50:32 UTC
I'm assuming this was assigned to the wrong Gregory.
Comment 5 Mark Sadecki 2013-10-23 20:00:00 UTC
a11ytf decision to move to

New bug: