EXPLANATORY NOTE:

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 
elements.

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.


BACKGROUND:

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 


ACCESS COMMAND REQUIREMENTS

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 
      sharable;


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 
      order. 


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.