Keyboard Access Requirements Recommendation from PFWG

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

Please note that in addition to the requirements listed below, HTML5 needs to provide mechanisms that enable Principle 4 of the User Agent Accessibility Guidelines, 2.0, a list of which can be found on the discussion page for this wiki document.

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.

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

Explanatory notes:

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

Requirement 3: Access commands should default to focus behaviour, ability for authors to specify whether the default behaviour focuses or activates the target, and for a user to overwrite any author specified or default behaviour.

Explanatory notes for Requirement 3:

• If no user or author behaviour is specified, a clear default should be used, in most cases this would default to a focus behaviour.

Requirement 4: Ability for an author to provide a description for an access command assignment.

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.

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

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.

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:

• This way, some DOM based assistive technologies can quickly access the mapping shortcuts versus having to walk the DOM.