Keyboard equivalents for all actions

Provide keyboard equivalents for all actions.

Someone who is unable to use the mouse needs 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. Blind users using the keyboard 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. Drawing is an example of a function that is inherently a mouse function. 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. Consult the Java Foundation Class keyboard assignments for information on keyboard bindings in JFC components. These platform-specific standard keys are normally specified in the platform user interface style guideline document. The following list provides links to style guidelines for Microsoft Windows, Apple Macintosh, and UNIX platforms:

• Microsoft Windows Keyboard Design Guide. (link resides outside of ibm.com)
• Microsoft Windows User Experience Fundamentals of Designing User Interaction (link resides outside of ibm.com)
• Motif and CDE 2.1 Style Guide (link resides outside of ibm.com)
• KDE User Interface Guidelines (Unix) (link resides outside of ibm.com)
• GNOME User Interface Guidelines. (link resides outside of ibm.com)

The following techniques are the minimum required to meet Checkpoint 1.1 from the IBM Java 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 F10 to move focus to the menu bar and arrow keys to navigate among the menus and menu items.
• Provide menu items for all toolbar actions or provide keyboard access to toolbars. The following samples will be useful in illustrating these concepts.
  • JScrollSample
  • JDialogSample
  • JRadioButton
• 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.
• 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.
• 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.

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." To set a mnemonic in JFC, pass a Java virtual key as defined in java.awt.KeyEvent.
  
  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 can't 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.
• 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 interfacestyle guidelines for specific standard shortcut key combinations.
• Provide a logical tab order in application windows and dialogs. The tab order is the order in which the Tab key moves the keyboard focus from one control 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.

  Most component libraries today do not allow the developer to define the logical ordering. Until a better solution is devised, add components to containers in the logical order as they should be read on the screen. For example, if using an AWT border layout, add components as follows:

public class BorderTest extends Frame
implements Accessible{
public BorderTest () {
  AccessiblePanel p = new AccessiblePanel();
  p.setLayout(new BorderLayout();
  p.add(new MyAccessibleButton("Left");
  p.add(new MyAccessibleButton("Bottom");
  p.add(new MyAccessibleButton("Right");
  p.add(new MyAccessibleButton("Top");
  add("North", p);
  }
AccessibleContext getAccesibleContext() {
			   ...
  }
}

Child enumeration in Java enumerates the children in the order they were added. Adding the components in the same order that they would logically be read on the screen enables the assistive technology to read the components in the appropriate 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.

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

Tools

There are no tools required to test this checkpoint.

Techniques