This Wiki page is edited by participants of the HTML Accessibility Task Force. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Task Force participants, WAI, or W3C. It may also have some very useful information.
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
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.
- 1 Keyboard Access Requirements Recommendation from PFWG
- 1.1 Potential Uses of Access Command
- 1.2 Explanatory Note
- 1.3 Requirement 1: A device independent means to activate an access command.
- 1.4 Requirement 2: Ability for an author to define a default access command mapping, and for a user to override the default mapping.
- 1.5 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.
- 1.6 Requirement 4: Ability for an author to provide a description for an access command assignment.
- 1.7 Requirement 5: Ability to specify the target elements that will respond to an access command, based on their id reference.
- 1.8 Requirement 6: Ability to specify target elements in terms of their role, or implied ARIA semantics for the role if not overridden by ARIA.
- 1.9 Requirement 7: Ability to specify a custom order for cycling through multiple objects attached to a single access command.
- 1.10 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.
- 1.11 Requirement 9: Access command mappings should be available at the beginning of the document.
Requirement 1: A device independent means to activate an access command.
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.
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.
- This is a glaring omission in
accesskeytoday. 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.
- 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.
- 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.
- As an example,
@tabindexis 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.
- This way, some DOM based assistive technologies can quickly access the mapping shortcuts versus having to walk the DOM.