Keyboard access

Defining keyboard accelerators for every action

Since a mouse or other pointing devices may not be used by people with reduced vision, an accessible application must be usable with the keyboard alone. Therefore, all the possible actions that could be triggered by a user must have a keyboard shortcut.

We strongly suggest that you define consistent keyboard shortcuts for all actions through the use of action defaults. Developers can avoid overriding the system default shortcuts by checking the target platform guidelines, especially for system shortcuts that trigger accessible actions (for example, Ctrl-Shift-Enter, which triggers spoken information about the currently selected item). Overriding system shortcuts is generally a bad practice, even for non-accessible applications, although overriding may be unavoidable due to compatibility issues.

Keyboard focus and action views

Generally, keyboard navigation in an application may be easier if you keep the MENU actions in the menu frame; the actions can have the keyboard focus and the user can navigate through them using the up and down arrows.

You can also use a TOPMENU, because you can pull it down with the keyboard (for example, the Alt key on Windows™) and then navigate using arrow keys, but it may be less accessible than the menu panel. You must also be sure that every item of the menu can be activated by a keyboard shortcut. You may use the & (ampersand) in menu items to specify character which letter should be used, to let the front-end automatically create a shortcut to trigger the action with that letter.

Avoid using toolbars only in an accessible application, because toolbars by default are not accessible using the keyboard. Toolbars cannot have the keyboard focus, and there is no way to navigate through all toolbar items or to activate one of them using the keyboard. If you do use toolbars, provide keyboard shortcuts and duplicate them in a topmenu.