Keyboard equivalents for actions

Provide keyboard equivalents for all actions.

Users who are unable to use the mouse 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 mouse 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.

Back to top

The accessibility requirement is for all functions of the software, that are not inherently mouse functions, to be operable using only the keyboard. Moving the mouse pointer or drawing are examples of a functions that are inherently mouse functions. Direct manipulation, such as selecting text, is not inherently a mouse function. 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 Apple Macintosh, Unix, and Eclipse platforms:

• Macintosh Human Interface Guidelines (link resides outside of ibm.com)
• Motif and CDE 2.1 Style Guide (Unix) (link resides outside of ibm.com)
• KDE User Interface Guidelines (link resides outside of ibm.com) (Unix)
• Keyboard Navigation for Gtk+2.0 Draft (link resides outside of ibm.com) (Gnome/Linux)
• Eclipse development resources for accessibility (link resides outside of ibm.com) (Eclipse.org (link resides outside of ibm.com) universal tools platform)
• Eclipse User Interface Guidelines (link resides outside of ibm.com)

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

• Provide the ability to navigate to and select each menu and menu item with standard keys. This includes the menu bar, system menu, and context sensitive menus. For example, use Alt+Spacebar to display the system menu on the title bar in a Windows application, Alt or F10 to move focus to the menu bar in Windows, F10 to move focus to the menu bar on the UNIX platform, and arrow keys to navigate among the menus and menu items. In Eclipse use F10 to move to the main window menu, and Ctrl+F10 to obtain the context menu for a View.
• Provide menu items for all toolbar actions or provide keyboard access to toolbars. Eclipse Plug-ins all items in the toolbar have keyboard access in the main window menu, and the toolbar is directly available using the TAB and arrow keys. The accessible name for these items is the tooltip, therefore a tooltip must be defined for each toolitem on the toolbar. (Note: This is not equivalent to the Standard Widget Toolkit (SWT) toolitems. SWT toolitems are not accessible. While they do support the keyboard interaction the user must hover with the mouse pointer over the toolitem to obtain the accessible name. Because blind users can not position the mouse, this is not accessible.)
• Provide the ability to navigate to every control in the window client area and in dialogs and to operate all controls using the keyboard. For example, use the Tab key to navigate between groups of controls and the arrow keys to navigate between controls within a group. Pressing Enter and Spacebar are conventions for operating the control. In Eclipse use Shift+F10 to bring up the pull down menu for the main View, and A+- will bring up the View menu. F12 will activate an Editor.
• Provide the ability to navigate between sections (or panes) of the application window using the keyboard. For example, F6 will move the focus between panes on many applications. In Eclipse use Ctrl+F7 to switch between Views, TAB and arrow keys within Views. Use Ctrl+F8 to switch Perspectives, use Ctrl+F6 to switch Editors.
• Provide the ability to switch the keyboard focus back and forth between modeless dialogs and the application window. For example, Lotus Notes R5 uses Shift+Tab to move focus between the Properties box and the document.
• Provide the ability to select text and objects using the keyboard. 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.
• 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.

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

• 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." 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).
  
  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?);
• 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');
• 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.
  Provide a logical tab order among items in application windows and dialogs. The tab order is the order in which the Tab key moves the keyboard focus from one control or item to the next within a dialog box. For Western languages, the tab 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 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.
• 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.
• Avoid keystroke sequences that require a key to be pressed and released while a modifier key is being held down such as cycling through the View List in Eclipse. In this example you must:
  • Press the CTRL key, and press the F7 key.
  • Before releasing the CTRL key, press the up and down arrow keys to make a selection.
  • Press Enter to switch to the selected view.
  
  This is inaccessible because it requires a series of keystrokes while a modifier keys to be held down. StickyKeys won't support this type of action, it can only be accomplished using two hands with a real keyboard.

Tools

There are no tools required to test this checkpoint.

Techniques

The following techniques are required to verify this checkpoint: