All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.


Rationale

The purpose of this checkpoint is to ensure that, where possible, content can be accessed with a keyboard or keyboard interface. When interactive content can be operated using a keyboard or alternate keyboard, it is accessible to visually impaired people who cannot use devices, such as a mouse or gesture based devices, that require eye-hand coordination. The content is also available to people who must use alternate keyboards or input devices that act as keyboard emulators. Keyboard emulators include speech input software, sip and puff software, on-screen keyboards, scanning software and a variety of assistive technologies and alternate keyboards. People with low vision also may have trouble tracking a pointer and they can use software much more easily (or only possible) if they can control it from the keyboard.

The phrase "except where the task requires analog, time-dependent input" is used to separate those things that cannot reasonably be controlled from a keyboard. For example, a watercolor application in which the stroke is defined by the movement and speed of movement and/or pressure is not something that can be controlled from a keyboard. Also, the use of MouseKeys would not satisfy this success criterion because it is not a keyboard equivalent to the application; it is a mouse equivalent (i.e. it looks like a mouse to the application).

Rich Internet applications

Rich Internet application keyboard navigation should behave like desktop application keyboard navigation. For example, keyboard users tab to Windows® Explorer and then use the arrow keys to navigate to elements in the tree. WAI-ARIA provides support for arrow key navigation of complex widgets, such as menus, trees and grids, via the tabindex attribute or activedescendant property. For more information on how to implement arrow key navigation, see the Keyboard and Structural Navigation section of the WAI-ARIA Authoring Practices.

Note for iOS platform: For keyboards connected to iOS devices, tab and arrow key navigation is not supported as described in the previous paragraph. Apple has its own set of proprietary keyboard navigation keys which are documented in the Apple Wireless Keyboard/VoiceOver help

.

Required development and unit test techniques


To comply with this checkpoint, you must meet all of the following techniques. These techniques are defined in WCAG 2.0 Level A Success Criterion 2.1.1 (link resides outside of ibm.com).

  1. Keyboard control: Ensure keyboard control of all functionality
  2. Event handlers: Providing keyboard-triggered event handlers

Note: The examples presented in the techniques are not exhaustive. They are meant to illustrate the spirit of this checkpoint.

At this time WAI-ARIA examples are only fully supported in Firefox version 3.6 or later and version JAWS 12 or later. If your product needs to be accessible in Internet Explorer and mobile Safari/VoiceOver, one or more of the required HTML/CSS specific techniques must be implemented, as well as a WAI-ARIA technique. When WAI-ARIA becomes an approved W3C recommendation and Internet Explorer and mobile Safari/VoiceOver fully support it, then WAI-ARIA techniques alone will be sufficient to comply with this checkpoint.

Applications that provide WAI-ARIA must add the following statement to the checkpoint comments column of the Web Accessibility Checklist:

Note: This product uses WAI-ARIA to comply with this checkpoint. WAI-ARIA is supported on Windows using Firefox version 3.6 or later and JAWS version 12 or later, and supported on iOS v5.0 and later using Safari and VoiceOver.

HTML examples

  1. Keyboard control: Ensure keyboard control of all functionality.

    To comply with this technique, you must implement example 1. You must implement example 2 for rich Internet widgets (e.g., trees, menus, etc.).

    HTML example 1

    Ensure keyboard control using HTML form controls and links

    User agents provide the keyboard operation of HTML form controls and links. Therefore, when possible, use standard HTML form controls and link elements. Form controls and link elements can be tabbed to and standard controls can be operated without additional development effort.

    HTML example 2

    WAI-ARIA keyboard navigation

    Rich Internet widget keyboard navigation should behave like desktop widget keyboard navigation. For example, keyboard users tab to Windows Explorer and then use the arrow keys to navigate to elements in the tree. WAI-ARIA provides support for arrow key navigation of complex widgets, such as menus, trees and grids, via the tabindex attribute or aria-activedescendant property (link resides outside of ibm.com).

    If an element contains WAI-ARIA required children and no aria-activedescendant property (link resides outside of ibm.com), at least one of the required children must be focusable and have a keyboard event handler in order to manage keyboard navigation. In the following example, the list element is defined as a treeitem and can receive focus programmatically so that the navKey() function can manage keyboard input. The treeitem role is a required child of the tree role.

    <ul id="tree1" role="tree" tabindex="0">
    <li role="treeitem" tabindex="-1" aria-expanded="true" onkeydown="navKey()">
    Fruits
    </li>
    ...
    </ul>

    WAI-ARIA required child roles are documented in Web checklist checkpoint 4.1b, script example 4.

    For more information on how to implement arrow key navigation, refer to the Keyboard and Structural Navigation section of the WAI-ARIA Authoring Practices (link resides outside of ibm.com) and Keyboard navigable custom JavaScript widgets (link resides outside of ibm.com).

    Refer to the Design Patterns (link resides outside of ibm.com) section of the WAI-ARIA Authoring Practices for a description of the recommended keyboard interaction for specific widgets.

    Note for iOS platform: See the comment in the Rational section regarding iOS devices not supporting tab and arrow key navigation.

    Required unit tests for HTML development technique 1

    Perform the following unit tests.

    • Use available tools to locate areas in the content where mouse events are used and confirm all mouse events are paired with respective keyboard events.
    • Manually ensure that the user can navigate to and operate each control or function in the content with keyboard or keyboard interface "except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints."
  2. Event handlers: Provide keyboard-triggered event handlers.

    There are no specific examples for implementing this technique in HTML.


Script examples

  1. Keyboard control: Ensure keyboard control of all functionality.

    There are no specific examples for implementing this technique with scripts. Use the HTML examples as a guide.

  2. Event handlers: Provide keyboard-triggered event handlers.

    To comply with this technique, you must implement the following example.

    Script example 1

    Provide keyboard-triggered event handlers for a script

    All event handlers executed by non-keyboard UI events, such as a mouse click, should also be triggered by a keyboard-based event. For example, if you use the onmouseover event handlers, you should also add a redundant onclick mechanism, so that a keyboard-only user can perform the action.

    Another example is if you use a drag and drop feature, the user must be given the opportunity to perform the same actions using cut and paste or another keyboard-based approach.For more information, refer to the WCAG 2.0 examples for providing keyboard triggered event handlers (link resides outside of ibm.com).

    Required unit tests for Script development technique 2

    Perform the required unit tests for HTML development technique 1.


Dojo examples

  1. Keyboard control: Ensure keyboard control of all functionality.

    There are no specific examples for implementing this technique in Dojo. Use the HTML examples as a guide.

  2. Event handlers: Provide keyboard-triggered event handlers.

    To comply with this technique, you must implement the following example.

    Dojo example 1

    Provide keyboard-triggered event handlers for Dojo

    • The Dojo Dijit widgets are accessible. If the widgets are modified or extended, it is the developer's responsibility to ensure that they remain accessible. For example, when a Dijit widget is placed on a page it is accessed by tabbing. However, once it receives focus, the widget itself is navigated with arrow keys. The default arrow key navigation should not be modified when extending or modifying a widget.
    • The Dijit Tooltip widget is similar to the HTML title attribute, but it is more flexible. The Tooltip widget supports rendering arbitrary HTML and timing control. In order to activate a tooltip with the keyboard, a trigger element must be capable of receiving focus. If a trigger element isn't focusable by default, include a tabindex=0 attribute to put the element in the page tab order.
    • The Dojo TabContainer widget illustrates how arrow keys are used to navigate among tabs. When a user tabs to the following TabContainer, the active tab (tab two) receives focus, and the left and right arrow keys are used to navigate the tabs.

      Tab 1, Tab 2. Tab 3. Tab 2 content

    The Dojo Book provides keyboard navigation documentation for each of the Dijit widgets. For more information on how to include Dojo in your application, see Dojo Accessibility Overview.

    Required unit test for Dojo development technique 2

    Perform the following unit test.

    Manually ensure that the user can navigate to and operate each control or function in the content with keyboard or keyboard interface "except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints."


Adobe® Flash® examples

  1. Keyboard control: Ensure keyboard control of all functionality.

    There are no specific examples for implementing this technique in Adobe® Flash®. Use the HTML examples as a guide.

  2. Event handlers: Provide keyboard-triggered event handlers.

    To comply with this technique, you must implement the following example.

    Flash example 1

    Provide keyboard-triggered event handlers in Flash

    • Ensure that all elements in the Flash movie are device-independent. Device-independence allows people to navigate the movie using a mouse, keyboard-only, voice-input, or other assistive technologies. For elements that cannot be made device-independent, provide an equivalent function that is device-independent.
    • All controls that can be manipulated with the mouse must also be accessible with a keyboard. The Adobe Flash Player® facilitates keyboard access on its own by automatically making mouse-defined events accessible via the keyboard. In addition, add keyboard shortcuts to facilitate keyboard access in complex applications.

    For more information, visit the Adobe Flash Accessibility Design Guidelines Web site for Keyboard Access.

    Required unit tests for Flash development technique 2

    Perform the following unit tests.

    • Use available tools to identify any Flash in the content.
    • Manually ensure that the user can navigate to and operate each control for the Flash with the keyboard or keyboard interface.

Note for iOS platform: Mobile Safari does not support Java applets, Flash or other third party plugins. Therefore, equivalent content must be presented in a manner that is accessible on iOS devices. Apple recommends using the HTML5 audio and video elements for audio and video content. However, these elements use the browsers' native players, and the controls on the players are not keyboard accessible. Therefore, developers must use the HTML5 audio/video API, JavaScript and CSS to implement keyboard focusable controls. An example implementation of an accessible HTML5 video/audio player can be found in Chapter 6 of Pro HTML5 Accessibility: Building an Inclusive Web.  Use this link to register for access to the Pro HTML5 Accessibility document.


IBM® Lotus® Domino® examples

  1. Keyboard control: Ensure keyboard control of all functionality.

    There are no specific examples for implementing this technique in Lotus Domino. Use the HTML examples as a guide.

  2. Event handlers: Provide keyboard-triggered event handlers.

    To comply with this technique, you must implement the following example.

    Domino example 1

    Provide keyboard-triggered event handlers for Domino

    The objective of this technique is to permit individuals who rely on a keyboard or keyboard interface to access the functionality of the content. To do this, make sure that all of the events used in scripts or other interactive controls on the page are associated with a keyboard-based event or provide redundant keyboard-based mechanisms to accomplish the functionality provided by other device-specific functions.

    Domino supports JavaScript® event handlers on a form, subform, page, field, action, button or action hotspot using the Programmers Pane. Some event handler actions are not accessible via a keyboard. Care should be taken to provide alternate methods, especially when using event handlers, such as onMouseOver , onMouseOut , etc. The onClick event handler is keyboard accessible.

    The following JavaScript events must have alternatives for keyboard accessibility:

    • onDblClick – There is no alternate event that provides keyboard accessibility. Use of onDblClick must be avoided.
    • onMouseMove – There is no alternate event that provides keyboard accessibility. Use of onMouseMove must be avoided.
    • onMouseDown – OnKeyDown may be used to provide keyboard accessibility.
    • onMouseOut – OnBlur may be used to provide keyboard accessibility.
    • onMouseOver – OnFocus may be used to provide keyboard accessibility.
    • onMouseUp – OnKeyUp may be used to provide keyboard accessibility.

    Required unit tests for Domino development technique 2

    Perform the following unit test.

    Follow the required unit tests for HTML development technique 1.


Recommended development techniques

Although you do not have to implement the recommended techniques in order to comply with this checkpoint, you should review them since they can improve the accessibility and usability of the application.

Refer to the WCAG 2.0 Additional Techniques (Advisory) for Success Criterion 2.1.1 (link resides outside of ibm.com) for a list of techniques and examples.


©2013 IBM Corporation

Last updated January 1, 2013.

W3C Recommendation 11 December 2008: http://www.w3.org/TR/WCAG20/ (link resides outside of ibm.com)
Copyright 1994-2009 W3C (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University), All Rights Reserved.