Make sure that controls can be operated using the keyboard. Native interactive HTML elements, such as links and form controls, support keyboard accessibility by default, and these should be used wherever possible. However, many custom controls and widgets use elements such as div, span, and li, which do not by default provide keyboard support. In this case, keyboard support must be supplied by the developer, using HTML and JavaScript.
- Make sure every active control is in focus order. Ensure that custom controls can receive keyboard focus, by giving the control’s container element a tabindex attribute with the value of “0”.
- Make sure currently inactive controls are not in focus order. If a control should not be in focus order initially but may become active, such as a dropdown menu item, it should have a tabindex value of “-1”, which can be changed using scripting.
- Make sure that active controls are operable using the keyboard. Ensure that when a control has focus it can be activated using standard keystrokes—for example, a button can be pressed using the spacebar, a list of menu items can be traversed using the arrow keys, and a dialog can be dismissed using the Escape key. This requires that event-handling scripts listen for keypress events and, where necessary, suppress native keypress behavior.
- Make sure that content that appears/disappears, is designed such that users can perceive the additional content and dismiss it without disrupting the page experience. When dynamically adding content, be certain that users can move the pointer over the additional content to keep it visible, that the content remains open as long as it's relevant and as long as the user is interacting with it, and that the additional content is dismissable from the keyboard without moving focus/hover. In this context, custom tooltips, sub-menus, and other nonmodal popups that display on hover and focus are examples of additional content.
- Make certain that users are able to turn off or reconfigure keyboard shortcuts. Character key shortcuts are frustrating for speech input users, who are accustomed to use strings of characters for input, and for any keyboard user who is prone to accidentally hitting keys. For these reasons, if a keyboard shortcut is implemented, users must be able to either turn the shortcut off, remap the shortcut to one or more non-printable characters (e.g., Alt, Ctrl), or the keyboard shortcut is only active when a user interface component has focus.
Testing
Use the keyboard to tab through every element on a page. For each element, check that the answer to the following questions is “yes”:
- Does it receive keyboard focus?
- If so, when it has focus, can it be activated using standard keys?
- Can dynamically added content that appears/disappears, be perceived and controlled by assistive technology users, including the ability to dismiss the additional content without disrupting the page experience?
- Can a keyboard shortcut be turned off or reconfigured by the user?
More information
- Understanding SC 1.4.13—Content on Hover or Focus (WAI)
- Understanding SC 2.1.1—Keyboard (WAI)
- Understanding SC 2.1.4—Character Key Shortcuts (WAI)
- Providing Keyboard Navigation for Widgets (WAI-ARIA)
- Design Patterns (including recommended keyboard behavior) (WAI-ARIA)
- Why Keyboard Usability Is More Important Than You Think and Designing Better Keyboard Experiences