Keyboard

Making it possible for people to access and operate a web interface or application using the keyboard alone benefits people who can’t use a mouse due to a visual impairment or mobility impairment.

Provide Logical and Visible Focus Indication

It’s important to enhance keyboard usability by making sure that focus logically moves through the controls on the page and that there is a clear visible indication of which control currently has focus.

  • Make sure that focus order is logical. Focus order usually matches the DOM order, so do what you can to ensure that the desired focus order matches the visual layout of controls. Don’t use the tabindex attribute with any value greater than 0 in an effort to change the focus order of a control; This can lead to unpredictable changes to focus order, such as if additional controls were to be later added to the page.
  • Provide a clear visual indication of focus. Use CSS to provide a clear visual indication of when links, buttons, and other active control receive focus, such as through an outline or significant change in text color or background color. The default browser focus effect may not be visually obvious enough, and sometimes those focus indications can be inadvertently suppressed.
  • Make hidden elements visible when they have focus. Watch out for visually hidden controls that are in the focus order. They can be confusing for sighted keyboard users: If a control isn’t supposed to be active, like a menu item in a dropdown menu that hasn’t been expanded, then it shouldn’t be able to receive focus; hide it from everyone and remove it from the focus order using CSS. But if a control is hidden but available to receive focus, such as a “skip to main content” link, then it should become visible when it receives focus.

 

Testing

Use the Tab key to move through each active element on a page.

  • Is progress through elements logical, without unexpected jumps to different locations on the page?
  • Is there a clear visual indication for each element as it’s focused?

Support Keyboard Interaction

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, some 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 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 custom controls are operable using the keyboard. Ensure that when a control has focus it can be activated using standard keystrokes—for example:

    • A button activated using Enter/Return or the spacebar.
    • A list of menu items traversed using the arrow keys.
    • A dialog dismissed using the Escape key.

    This requires that event-handling scripts listen for keypress events and, where necessary, preventsuppress native keypress behavior, such as spacebar scrolling the page.

  • 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 using 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

Related Techniques

✎ Technique: Character key shortcuts

If keyboard shortcuts are implemented using only a letter (including upper- and lower-case letters), punctuation, number, or symbol characters, provide a way to turn off or remap character key shortcuts.

✎ Technique: Accessible modal dialogs

Modal dialogs can enhance usability by focusing attention on a specific message that requires a user action to continue.

An accessible modal dialog is one where keyboard focus is managed properly, and the correct information is exposed to screen readers.

✎ Technique: Expandable sections

Expandables (sometimes called “collapsible” or “disclosure widgets”) are simple interface patterns that allow you to expand and collapse content.

✎ Technique: Focus order and tabindex

Interactive elements should, under most circumstances, be focusable in the order that they appear in the source code. This helps people who are using the keyboard or alternative input devices to follow focus in a logical order.

✎ Technique: Keyboard operable custom controls

Sometimes, design requirements mean that you need to create a custom interactive element rather than using a native HTML element.

Your element will not be accessible by keyboard unless it is included in focus order and it can be activated using keys.

✎ Technique: Keyboard accessible links

Links ( elements) are focusable by default, so it should normally be possible to activate them using the keyboard. However, under certain circumstances, they are not focusable.