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 23613 - Access Command Requirements for HTML5
Summary: Access Command Requirements for HTML5
Alias: None
Classification: Unclassified
Component: default (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Charles McCathieNevile
QA Contact: HTML WG Bugzilla archive list
Keywords: a11y, a11ytf, a11y_focus
Depends on: 10779 10780 10782 10888 11140 23612 23615
Blocks: 10772 10774 10775 10776 10777 10778 10905 10994 23611 23614 23616
  Show dependency treegraph
Reported: 2013-10-23 19:59 UTC by Mark Sadecki
Modified: 2016-06-01 10:23 UTC (History)
11 users (show)

See Also:


Description Mark Sadecki 2013-10-23 19:59:21 UTC
+++ This bug was initially created as a clone of Bug #10888 +++


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 Charles McCathieNevile 2016-02-23 12:51:09 UTC
This is covered by the WICG request to make keyboard shortcuts configurable [1], the proposal to sort out user interaction[2], and the various smaller bugs on HTML that are related.

Comment 2 Simon Pieters 2016-02-24 15:02:09 UTC
Moved to where?
Comment 3 Charles McCathieNevile 2016-06-01 10:23:00 UTC
Moved to WICG as noted in comment 1