Access Command (Access-asterisk) Requirements for HTML5

The WAI Protocols and Formats Working Group is forwarding the following requirements for keyboard access functionality in HTML 5 to the HTML A11Y Task Force. These requirements were unanimously adopted by PF at its regular weekly teleconference on Wednesday 21 July 2010 (member-confidential link).

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.

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

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.

Proposed Revisions to the 9 PFWG Access Command Requirements

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

Explanatory Notes 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; such descriptions should be storable and sharable;

Explanatory notes:

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

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

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.

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 notes:

• 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:

• 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 notes:

• 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.
• Additionally, a user should be able to designate a specific keyboard layout so that the user agent can respond appropriately to user input