All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. (Level A)

Rationale

The purpose of this checkpoint is to ensure content can be accessed with a keyboard or keyboard interface. When interactive content is operated using a keyboard or alternate keyboard, it is accessible to visually impaired people who cannot use devices requiring eye-hand coordination (e.g., a mouse or touchscreen). The content must also be available for people who use alternative 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.

Notes:

  1. This checkpoint does not forbid or discourage providing mouse input or other input methods in addition to keyboard operation.
  2. The use of Windows MouseKeys does not satisfy this checkpoint because it is not a keyboard equivalent to the application; it provides a mouse equivalent by using keyboard keys (i.e., it looks like a mouse to the application).
  3. This checkpoint does not imply that software must directly support a keyboard or “keyboard interface." Nor does it imply that software must provide a soft keyboard. Underlying platform software may provide device independent input services to applications that enable operation via a keyboard. Software that supports operation via such platform device independent services would be operable by a keyboard and would comply.
  4. This checkpoint addresses the requirement to provide keyboard operability. Checkpoint 502.2.2 No Disruption of Accessibility Features addresses the software requirement to not disrupt or override platform accessibility options, including the keyboard commands to control these options. For web applications, the need to document non-standard keyboard operation is covered under Checkpoint 602.2 Accessibility and Compatibility Features.

Exception: This checkpoint does not apply where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. A watercolor painting program is an example of an exception because the brush strokes vary depending on the speed and duration of the movements.

Refer to Understanding SC 2.1.1 for more information (external link to WCAG).

Development Techniques

Review the General techniques as well as other tabs applicable to your technology.  Prioritize the use of technology-specific techniques, and implement the General techniques as needed. You are always required to find, understand and implement accessible code techniques to meet the checkpoint. The documented techniques and supplements are not exhaustive; they illustrate acceptable ways to achieve the spirit of the checkpoint. If numbered, techniques are in order of preference, with recommended techniques listed first. Where used, IBM information that complements the WCAG techniques is indicated as supplemental.

General techniques

Items in this section represent techniques deemed sufficient where applicable. Ensure you review WCAG Common Failures to avoid development mistakes.

Web (HTML, ARIA, CSS) techniques

In addition to the General Techniques, the Web techniques in this section are deemed sufficient .

Meet G202: Ensuring keyboard control for all functionality with:

Meet G90: Providing keyboard-triggered event handlers with:

Web Supplements

Matching established desktop keyboard interactions for widgets in web applications

Ensure that rich Internet application keyboard navigation behaves 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 and guidance for arrow key navigation of complex widgets, such as menus, trees and grids, via the tabindex attribute or aria-activedescendant property.

For more information on how to implement keyboard navigation, see WAI-ARIA Best Practices design patterns and Keyboard navigable JavaScript widgets.

If an element contains WAI-ARIA required children and no aria-activedescendant property, 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 Checkpoint 4.1.2 - Name, Role, Value.

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

SCR20: Using both keyboard and other device-specific functions

In the following example, the developer wants additional text to be displayed when a user with a mouse puts the cursor over the image (onMouseOver). To make this type of functionality accessible, onFocus and onBlur must also be used. In addition, because this is essentially an "image-swap", alt text must be added to the image, so that visually impaired users have access to the content as well. The image-swap below can be executed with a mouse or with a keyboard.

Accessibility - The quality of being accessible, or of admitting approach; receptibility.

Figure 1: Example of text to be displayed onMouseOver.

 The code for the preceding example is as follows:

<a href="webscripts_eventhandlers.html#imageswap" onmouseover="document.images['ex1pic2'].src = ex1on.gif';"
onfocus="document.images['ex1pic2'].src = 'ex1on.gif';"
onmouseout="document.images['ex1pic2'].src = 'ex1off.gif';"
onblur="document.images['ex1pic2'].src = 'ex1off.gif';"><img src="ex1off.gif" width="289" height="79" id="ex1pic2"
alt="Accessibility - The quality of being accessible, or of admitting approach; receptibility." /></a>

 

Making JavaScript actions keyboard accessible

Typically, only links and form controls are in the keyboard tab order. However, complex widgets, such as trees, menus and grids, should also receive focus via tabbing and arrow key navigation should be supported for navigating elements within these widgets. For more information on how to implement arrow key navigation for complex widgets, see Keyboard and Structural Navigation in the WAI-ARIA Best Practices and Keyboard navigable JavaScript widgets.

In addition, browsers will sometimes map the pressing of the keyboard Enter key to mouse events. Therefore, device-dependent event triggers must be tested to determine if the browser simulates the event with the keyboard as a redundant input mechanism. If it does, then specifying the mouse event is sufficient. Two events might cause a problem when only one is expected. For example, onKeyDown should not be specified with onMouseDown because doing so will cause two browser events: one for the onKeyDown event because the user pressed down the Enter key and the other for a simulated mouse click provided by the browser for onMouseDown.

If the browser does not simulate the mouse event when the keyboard is used, then the keyboard event must also be specified.

OnClick is an example of an event handler that sometimes behaves as a device-independent handler and in other cases as a device-dependent handler. Specifying the event handler OnClick on a link or form element should cause the browser to evoke the event if either the mouse or the Enter key is used to select it. In this case, OnClick acts in a device-independent manner, and is therefore directly accessible because the same action takes place when the link is clicked or the Enter key is pressed. In other words, for a link that uses OnClick, if tabbing to a link and pressing the Enter key will cause the OnClick event to occur, then the script functionality can be operated via the keyboard without requiring the developer to code the second redundant onKeyPress event for the same element.

The example below uses OnClick as a device-independent link, which is executed when the Enter Key is used to select the element:

<a href="webscripts.html#postexample" onclick="return confirm('Clicking OK will take you to the next paragraph');">View this device-independent onClick example</a>

When the OnClick event is used with elements that are not links or form controls, OnClick is device-dependent, therefore you must provide a redundant device-independent event handler (onKeyPress) or an equivalent alternative. In order to gain focus on the text, you will need to implement the tabindex attribute. Once that is done, you can use the onKeyPress event handler to provide an alternative to OnClick.

The example of code below presents a <div> element with a tabindex=0 to make it focusable. In order to make user input is device-independent, the <div> element contains both the OnClick and onKeyPress event handlers. The OnClick and onKeyPress event handlers enable mouse and keyboard-only users to operate the widget.

<div id="widget_id" tabindex="0" onClick="return confirm('Clicking OK will take you to the next paragraph');" onKeyPress="return confirm('Clicking OK will take you to the next paragraph');"></div>

Note that complex widgets, such as trees, menus and grids, have a different navigation paradigm. Complex widgets should receive focus via tabbing and arrow key navigation should be supported for navigating elements within the widgets. For more information on how to implement arrow key navigation for complex widgets, refer to WAI-ARIA Best Practices and Keyboard-navigable custom JavaScript widgets.

The following examples illustrate some other key considerations for making javascript actions keyboard accessible.

Do not write event handlers that use double-clicking (onDblClick)

There is no keyboard equivalent specified in HTML 4.01. Instead, use one of the keyboard accessible handlers.

Do not write event handlers that rely on mouse coordinates

There is no keyboard-equivalent way to perform this function. An example of a script that relies on mouse coordinates is a server-side image map, which uses javascript:onmouseover as a precursor to performing an action.

Do not use scripts to remove focus when focus is received

The system focus indicator is an important part of accessibility for keyboard users. When focus is removed from a control via script on content that normally receives focus when the content is accessed can interfere with the focus cycle and prohibit a user's ability to interact with the control using the keyboard.

The following example is a failure of this checkpoint:

<input type="submit" onFocus="this.blur();">
 
Use document.write correctly

When using document.write, the content should be written to the same page or the user must be notified if document.write creates content in new page/window and then focus must be set to the new window.

Ensuring tooltips are keyboard accessible

Additional information is often provided to users in the form of a tooltip -- text revealed when a user hovers over an element with a mouse. A common tooltip method is using the HTML title attribute, which can be used on many HTML elements and is revealed by the browser. However, without enhancements, the text revealed when hovering with a mouse is not normally keyboard accessible. To ensure such tooltips are keyboard accessible, two things must occur: 1) the trigger element must be capable of receiving keyboard focus; 2) a keyboard-triggered event handler must be provided. The trigger can be the result of a key-pressed event (i.e., the application puts a listener on a key like F1). The trigger could also be keyboard events such as onfocus and onblur that provide redundancy for a mouse event handler like onmouseover. Several javascript libraries offer the latter functionality, including this IBM internal only bootstrap demonstration. For other considerations for tooltips, please refer to the ARIA Design pattern for Tooltip.

Providing 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

Mobile Native (iOS) techniques

Instructions: In addition to the General techniques, the Native iOS techniques in this section represent a technique or combination of techniques deemed sufficient for meeting this checkpoint.

Meet G202: Ensuring keyboard control for all functionality with the following:

Follow Apple’s proprietary keyboard navigation for iOS

In order to provide a keyboard equivalent for all gestures, iOS requires that the VoiceOver screen reader be activated and used with a wireless keyboard. Apple has its own set of proprietary keyboard navigation keys, documented in the Apple Wireless Keyboard/VoiceOver help.

Set the accessibility attribute of the control

When using the standard iOS controls, developers must set the accessibility attribute of the control. In Interface Builder, this is done by setting the Accessibility checkbox to  Enabled. This is found on the Identity Inspector tab. This also can be done programmatically with the setIsAccessibilityElement and setAccessibilityLabel methods:

self.myButton setIsAccessibilityElement:YES];
[self.myButton setAccessibilityLabel: @"label text for button"];

 

 

Support the UI Accessibility Protocol

Software that creates custom controls must support the UI Accessibility Protocol to expose the object label, focus location, accessibility enabled status, value, traits (roles), and status changes. One of these traits is Keyboard Key. Developers should refer to the Accessibility Programming Guide for iOS.

Use the UIKeyCommand class

Ensure that all gesture-based functions are accessible with a Bluetooth keyboard. For iOS 7 and later, this can be accomplished using the UIKeyCommand class.  Refer to the example under the heading “Keyboard Support” in the article iOS 7: Hidden Gems and Workarounds.

Eclipse techniques

Instructions: In addition to the General techniques, the Eclipse techniques in this section represent a technique or combination of techniques deemed sufficient for meeting this checkpoint (2.1.1).

Common user interfaces must be accessible through the keyboard

Common user interface components must be accessible through the keyboard. This includes:

  • Menu bar, menus, system menu, and context menus. For example, in Microsoft Windows Alt or F10 will move the focus to the menu bar. Shift+F10 will display the shortcut, or context menu for the active, selected object.
  • Toolbar items must be accessible using the keyboard, or the functions must be made available through an alternative interface, for example a menu item.
  • Widgets such as sliders, selectors, calendars, etc.

Provide navigation between panes and windows

Software must provide the ability to navigate to every control within a window or window area (pane), and between windows or applications.

  • Windows are often divided into areas or panes. Software must provide the ability to navigate between these areas. For example, F6 will move the focus between panes on many applications. In Eclipse, use Ctrl+F7 to switch between Views and the Tab and arrow keys to move within Views. Use Ctrl+F8 to switch Perspectives, use Ctrl+F6 to switch Editors. See Navigating the user interface using the keyboard in Eclipse help for full details.
  • Provide the ability to switch the keyboard focus back and forth between modeless dialogs and the application window. For example, in IBM Notes, Alt+Enter opens the Properties box and gives it focus while Esc closes the Properties box and returns focus to the application.
  • In dialog windows, software must provide the ability to navigate to each active control, or group of controls. For example, the Tab key is used to navigate between groups of controls and the arrow keys to navigate between controls within a group.
  • When information is required for the operation of the software, it must be available to assistive technology to be read to the user. In the dialog box in Figure 1 the top portion of the dialog contains information required for operation and must be in the tab sequence. On the other hand, the help icon in the lower left corner of the dialog box is not required in the tab order. The help icon is not required because there is a standard method to access help from all dialogs using the F1 key.
Dialog box with a top portion containing information required for operation and a help icon in the lower left corner

Figure 1: Dialog box with a top portion containing information required for operation and a help icon in the lower left corner

 

Enable the activation of all controls using the keyboard

Software must enable the user to operate all controls using the keyboard. Pressing Enter and Spacebar are conventions for operating the most commonly used controls, such as menus, push button and radio buttons. A slider control used to indicate a range is operable using the arrow keys.

Support standard keys and key combinations of the platform

For a particular software platform, there are standard keys and key combinations for doing common things. These standard keys are normally specified in the platform user interface style guideline document. The following list provides links to style guidelines for Microsoft Windows and Eclipse.

Provide the ability to select non-static text (text that receives focus) and objects using the keyboard

Within any area of the application where a mouse user can select non-static text by dragging the mouse across the text or selecting with touch, the same ability must be provided to keyboard users.

For example, Shift+Arrow keys in Windows will select text starting at the cursor location.

Provide a keyboard equivalent for functions that are normally provided through mouse drag and drop operations

The equivalent does NOT have to be a keyboard equivalent that "performs" the drag and drop. It just has to provide the same result. For example, to size images in a Web authoring tool, the user can select it with the mouse and stretch it by dragging a corner to the desired size. A keyboard equivalent to accomplish the task can be provided by making the image selectable using the keyboard and providing a menu item that displays a properties sheet for the image. The image size is one of the attributes that can be modified in the properties sheet. Another example is using Cut and Paste instead of drag and drop to move an object.

Support scrolling via the keyboard

Scrolling must be supported with the keyboard using the standard scrolling keys; for example, Page Up, Page Down, Ctrl+Home, Ctrl+End, Tab and arrow keys, to move information into the viewable area and to move keyboard focus appropriately.

Create a mnemonic, or access key, for each menu item (except in dynamic menus)

In Eclipse, mnemonics are easy to define for text items like Labels and MenuItems. Just place an ampersand (&) before the mnemonic character (such as Name) as shown in the sample below.

Label labelField = new Label(workArea, SWT.NOTE); LabelField.setText(?&Name?)

Include shortcut, or accelerator, keys for frequently used functions in pull-down menus

In Eclipse, accelerators can be defined for MenuItems using the setAccelerator() method. The following example creates a menu item, with text and adds an accelerator.

MenuItem item = new MenuItem (submenu, SWT.PUSH);
item.setText ("Select &All\tCtrl+A");
item.setAccelerator (SWT.CTRL + 'A')

Notes:

  • Frequently used functions can be invoked even faster with shortcut keys than with mnemonics. Determine what software features need shortcut keys by calculating those most frequently used.
  • Shortcuts, accelerators and mnemonics should be unique, and not duplicated. For example, you should not set the mnemonic F for File and Format in the same menu.

Windows-based (MSAA+IA2) techniques

Instructions: In addition to the General techniques, the Windows-based (MSAA+IA2) techniques in this section represent a technique or combination of techniques deemed sufficient for meeting this checkpoint (2.1.1).

Common user interfaces must be accessible through the keyboard

Common user interface components must be accessible through the keyboard. This includes:

  • Menu bar, menus, system menu, and context menus. For example, in Microsoft Windows Alt or F10 will move the focus to the menu bar. Shift+F10 will display the shortcut, or context menu for the active, selected object.
  • Toolbar items must be accessible using the keyboard, or the functions must be made available through an alternative interface, for example a menu item.
  • Widgets such as sliders, selectors, calendars, etc.

Provide navigation between panes and windows

  • Windows are often divided into areas or panes. Software must provide the ability to navigate between these areas. For example, F6 will move the focus between panes on many applications as outlined in the Windows Keyboard shortcuts  page in MSDN.
  • Provide the ability to switch the keyboard focus back and forth between modeless dialogs and the application window. For example, in IBM Notes, Alt+Enter opens the Properties box and gives it focus while Esc closes the Properties box and returns focus to the application.
  • In dialog windows, software must provide the ability to navigate to each active control, or group of controls. For example, the Tab key is used to navigate between groups of controls and the arrow keys to navigate between controls within a group.
  • When information is required for the operation of the software, it must be available to assistive technology to be read to the user. In the dialog box in Figure 1 the top portion of the dialog contains information required for operation and must be in the tab sequence. On the other hand, the help icon in the lower left corner of the dialog box is not required in the tab order. The help icon is not required because there is a standard method to access help from all dialogs using the F1 key.
Dialog box with a top portion containing information required for operation and a help icon in the lower left corner

Figure 1: Dialog box with a top portion containing information required for operation and a help icon in the lower left corner

Enable the activation of all controls using the keyboard

Software must enable the user to operate all controls using the keyboard. Pressing Enter and Spacebar are conventions for operating the most commonly used controls, such as menus, push button and radio buttons. A slider control used to indicate a range is operable using the arrow keys.

Support standard keys and key combinations of the platform

For a particular software platform, there are standard keys and key combinations for doing common things. These standard keys are normally specified in the platform user interface style guideline document. The following list provides links to style guidelines for Microsoft Windows and industry standards.

Provide the ability to select non-static text (text that receives focus) and objects using the keyboard

Within any area of the application where a mouse user can select non-static text by dragging the mouse across the text or selecting with touch, the same ability must be provided to keyboard users.

For example, Shift+Arrow keys in Windows will select text starting at the cursor location.

Provide a keyboard equivalent for functions that are normally provided through mouse drag and drop operations

The equivalent does NOT have to be a keyboard equivalent that "performs" the drag and drop. It just has to provide the same result. For example, to size images in a Web authoring tool, the user can select it with the mouse and stretch it by dragging a corner to the desired size. A keyboard equivalent to accomplish the task can be provided by making the image selectable using the keyboard and providing a menu item that displays a properties sheet for the image. The image size is one of the attributes that can be modified in the properties sheet. Another example is using Cut and Paste instead of drag and drop to move an object.

Support scrolling via the keyboard

Scrolling must be supported with the keyboard using the standard scrolling keys; Page Up, Page Down, Ctrl+Home, Ctrl+End, Tab and arrow keys to move information into the viewable area and to move keyboard focus appropriately.

Create a mnemonic, or access key, for each menu item (except in dynamic menus)

 Using Visual Studio, mnemonics are easy to define for controls that have on-screen labels. Just place an ampersand (&) before the letter that is to become the access key in the Caption property for the control. For controls that have no on-screen label, a Caption property can be added using a Static Text control. See Defining Mnemonics in MSDN.

Include shortcut, or accelerator, keys for frequently used functions in pull-down menus

See the Keyboard Accelerators page in MSDN for full details on adding keyboard accelerators to a Windows application. Additionally, Guidelines for Keyboard User Interface Design outlines best practices when designing a keyboard user interface including what to consider when adding shortcut keys to an application.

Notes:

  • Frequently used functions can be invoked even faster with shortcut keys than with mnemonics. Determine what software features need shortcut keys by calculating those most frequently used.
  • Shortcuts, accelerators and mnemonics should be unique, and not duplicated. For example, you should not set the mnemonic F for File and Format in the same menu.
  • Windows software that normally hides some keyboard user interface elements or omits some keyboard mechanisms altogether should present these mechanisms when the Keyboard Preference flag is set. This flag, which is set by the user in the Control Panel (Accessibility Options - Keyboard - Show extra keyboard help in programs), advises an application that the user relies on the keyboard rather than a pointing device, so additional support should be provided where appropriate. An application can test for this flag by calling the SystemParametersInfo function with the SPI_GETKEYBOARDPREF value.

Most links in this checklist reside outside ibm.com at the Web Content Accessibility Guidelines (WCAG) 2.0. W3C Recommendation 11 December 2008: http://www.w3.org/TR/WCAG20/

Copyright © 1994-2017 World Wide Web Consortium, (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University, Beihang University). All Rights Reserved.

Copyright © 2001, 2017 IBM Corporation