Keyboard equivalents for actions

Checkpoint 1.1: Keyboard equivalents for actions

Provide keyboard equivalents for all actions.


Rationale

Users who are unable to use the mouse or a touch interface need all functions to be available via the keyboard. Users with limited hand use may not have the fine motor control required to position the pointer accurately on objects displayed on the screen. Blind users cannot position the mouse pointer because they can't see the screen. The keyboard provides a precise discrete method of navigating and selecting. Mobility impaired users using the keyboard can precisely navigate and select using the keyboard or technology that emulates the keyboard. Blind users using the keyboard (tab, right arrow, function keys, etc.) can precisely navigate to the elements of the application which their screen reading software will then read to them. In this way, blind users are able to establish a mental model of the application and learn repeatable steps for accomplishing tasks.

Keyboard equivalents benefit all users, providing an alternative to using the mouse which may cause repetitive stress injuries. Good keyboard implementation can also improve user productivity.


Required development techniques


The following techniques are the minimum required to meet Checkpoint 1.1 from the IBM Software Accessibility Checklist:

  1. All functions of the software, that are not inherently mouse or touch interface functions, must be operable using only the keyboard.
  2. Software must be consistent with and support the standard key and key combinations for the platform, including standard shortcut keys as well as navigation.
  3. Provide the ability to select non-static text (text that receives focus) and objects using the keyboard.
  4. Provide a keyboard equivalent for functions that are normally provided through mouse drag and drop operations or touch gestures.
  5. Scrolling must be supported with the keyboard using the standard scrolling keys; page up, page down and tab, to move the viewing area and keyboard focus appropriately.

Examples of required techniques

  1. All functions of the software, that are not inherently mouse functions or touch interface functions, must be operable using the keyboard. Moving the mouse pointer is an example of a mouse function. Direct manipulation features like switching between active windows, or selecting text are not inherently mouse functions. On a touch device, drawing is an inherent touch function. Selection, widget manipulation and switching applications are not inherently touch functions. Each function in the software must have a keyboard equivalent for performing the function. With very few exceptions, software must be completely operable using only the keyboard.

    Example 1

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

    Note: The standard Microsoft Windows toolbar control created by CreateWindowEx requires specific implementation to ensure its accessibility. Create the toolbar with a TBSTYLE_FLAT style to enable hot-tracking and add message handlers for appropriate window messages, i.e. WM_SETFOCUS, WM_KEYDOWN, and WM_CHAR to set the hot-tracked item as the focus item. See Eclipse's win32 version of org.eclipse.swt.widgets.ToolBar.java for details.

    Example 2

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

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

    Example 3

    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, or the plus (+) or minus (-) keys.

  2. Software must be consistent with and support the standard key and key combinations for the platform. This includes standard shortcut keys, navigation, and selection. It also includes standard platform keyboard assignments applicable when assistive technology, such as a screen reader, is running.

    Example 4

    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, Linux/Gnome, and Eclipse.

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

    Example 5

    Within any area of the application where a mouse user can select 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.

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

    Example 6

    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.

  5. Scrolling must be supported with the keyboard using the standard scrolling keys; page up, page down and tab, to move the viewing area and keyboard focus appropriately.

    Example 7

    Scrolling with standard keys must be supported in windows and window areas to move information into the viewable area.


Recommended development techniques

The techniques above are required; the following techniques are recommended to enhance accessibility:

  1. Except when menus are dynamic, each menu item should have a mnemonic, or access key, as in F for File. People with disabilities benefit from mnemonics because they can reduce time-consuming steps that would otherwise be required to activate the feature. Without mnemonics, it takes 5-15 keystrokes to invoke the Print function on the standard File pull-down menu. Users must first use Alt or F10 to move the keyboard focus to the menu, then Enter on the File menu. They must then press the down arrow key 5-10 times to get to the Print option and press Enter. If the mnemonics F for File and P for Print are available, the user presses Alt-F to open the File menu, and then P for Print. Mnemonics for menu items such as F for File are indicated by underlining them and are "self-documenting." It is important to remember that when using Mnemonics one should consider the Globalization issues involved. Like all other translated strings, the mnemonic key should be part of the resource bundle. This will provide the translators with the ability to use the correct letter for each language. For example, Asian characters cannot generally be used for mnemonics, so translators will add an ASCII letter in parentheses to the end of the translated string. e.g. If "File" is "XXX" in Japanese, this might be translated as "XXX(F)" and then F would become the mnemonic for both strings.

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

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

    With Java Foundation Class (JFC), to set a mnemonic, pass a Java virtual key as defined in java.awt.KeyEvent . For more information, see the section on setMnemonics in the Java Accessibility Cookbook.

    Apple OSX menus have a different convention. Keys are either assigned a keyboard shortcut using with one of five modifier keys (Command, Control, Option, Shift, fn) or they are accessed by pressing to Cntl+Fn+F2 then navigating the menus with either arrow keys or typing the first letters of the menu option until the one you want is selected.

    Mobile devices generally do not use menus as such. Mnemonics are not used on mobile devices. Any menus must interact consistently with the widgets used to implement them. For example, a button displays a list of options. (For example, system settings). The button must activate using the keyboard, and the lists of options must be navigable and selected according the keyboard conventions of the platform.

  2. Include shortcut, or accelerator, keys for frequently used functions in the pull-down menus. Frequently used functions can be invoked even faster with shortcut keys than with mnemonics. The decision of what software features need shortcut keys can be made by determining which features are most frequently used. Often, toolbars are designed to contain the most frequently used actions. A good design point is to provide shortcut keys for all items on the toolbar and document them in the pull-down menu. In the previous example, the standard Ctrl+P shortcut key provides instant access to the Print function. To document the shortcut key for Print, add Ctrl+P next to the Print command in the File pull-down menu. See the above user interface style guidelines for specific standard shortcut key combinations. 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')

  3. Shortcuts, accelerators and mnemonics should be unique, and not duplicated. For example, you should not set the mnemonic F for File, and Format within the same menu.

  4. Provide a logical navigation order among items in application windows and dialogs. The navigation order is the order in which the Tab key or Next gesture moves the keyboard focus from one control or item to the next within a dialog box. For Western languages, the navigation order is normally from left to right and top to bottom. If the order does not follow this convention, it can be very confusing to users, especially blind users, who navigate using the keyboard. Users who are blind explore forms and dialog boxes sequentially, using the Tab key, instead of scanning the entire box as sighted users would. Use standard programming practices for specifying the tab index for each control in a dialog. For example, in Microsoft Visual C++ use Layout/Tab Order to view and change tab orders for your dialogs. In Eclipse the default tab order is the order in which the controls are added to the GUI component hierarchy. You can override this by using the org.eclipse.swt.widgets. Composite getTabList() and setTabList() methods for Composite type objects. For Control type objects use the Control.moveAbove() and Control.moveBelow() methods to manipulate the tab order. In mobile applications it is the Next / Previous gesture or keyboard action that navigates between UI elements; on some platforms, the Tab key is not utilized. The principle is the same: navigation should be in a logical order.

  5. In dialogs, allow the user to press the Shift+Tab key combination to move backwards through dialogs. Without this feature, the user will have to cycle all the way through the end of a dialog and back to the beginning in order to back up to a previous control. In mobile apps, ensure the complimentary keystroke (and gesture) to move backwards through the dialog are supported by your application.

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

 

Required test techniques

Test the software to ensure that it complies with accessibility requirements.

Required test software

No additional software is required to test this checkpoint.

Test techniques

The following techniques are required to verify this checkpoint:

Action Result
1. Test with the keyboard to verify keyboard equivalents for all actions. See the user interface style guidelines listed under Required development techniques for standard keys to be tested on each platform.

At a minimum, the following keyboard operations must be tested:
Pass:

The keyboard can be used to access all actions available from the mouse.

Fail:

The mouse is required to access some or all actions.
2. Test with the keyboard to verify unique keyboard support provided by the software. For example, in Lotus Notes, Alt+B is used to access the Bookmark bar and Ctrl+Tab is used to move between open tasks. Pass:

The keyboard can be used to access application specific actions available from the mouse.

Fail:

The mouse is required to access some or all application specific actions.


©2009, 2013 IBM Corporation

Last updated January 28, 2013.