Designing Better Keyboard Experiences

In our first article on keyboard usability, we discussed why the keyboard is an important (and often overlooked) accessibility element.

In this article, we'll examine four key ways to improve online user experiences for people who don’t use a mouse. Let’s look at each of them in turn.

Make menus, buttons, and links reachable using the keyboard

The first and most fundamental requirement for keyboard usability is that all active controls can be reached, or “focused,” using the keyboard.

The good news is that interactive HTML elements for links and controls, like buttons and drop-down form components, have keyboard support built-in. They are automatically part of the focus order in the browser and have standard keyboard commands associated with their operation.

However, things can get complicated. Many modern web applications use custom controls, such as accordions and custom dialogs. Many of these come from widget toolkits. They are typically coded using static HTML elements, such as divs, that don’t have native keyboard support. Interactive behaviors for custom controls must be added in using scripting, and these scripts usually address mouse operation, but often with no provision for keyboard focus and operation.

The World Wide Web Consortium’s Web Accessibility Initiative’s Accessible Rich Internet Applications specification, or WAI-ARIA for short, was created to address accessibility shortcomings in custom controls. Providing keyboard focus is an important aspect of the standard.

You can make a custom control focusable using the HTML tabindex attribute, which can greatly enhance keyboard usability when used wisely. Giving a control a tabindex value of “0” adds it to the focus order in the order in which it appears in the code. Giving a custom control a tabindex value of “-1” allows for scripting to control when and how the control is focusable. For example, a menu item in a drop-down navigation menu should only receive focus when the menu is expanded, and should receive focus using arrow keys rather than the TAB key.

Use controls that can be operated by the keyboard

Making sure that custom controls receive focus is only half the story---it’s no good reaching a control if you can’t make it work. For keyboard usability, it must be possible to operate controls using the keyboard, with standard commands.

Including custom controls on a website or app requires careful planning and some scripting to add the necessary behavior. For example, a custom button must be scripted to support the standard means of button activation---using the SPACEBAR key. A custom modal dialog must be scripted to close using the ESC key.

Again, WAI-ARIA to the rescue! The WAI-ARIA Best Practices specify standard keyboard behavior for a range of custom widgets and controls you might consider using in a website or app. So when you’re creating or selecting a widget or control for use, be sure to support the keyboard commands as defined in the appropriate WAI-ARIA Design Patterns.

As an example, here is the standard keyboard behavior for a slider widget (excerpted from the WAI-ARIA design patterns document):

• The TAB key moves focus into and out of the slider.
• RIGHT ARROW and UP ARROW increase the value of the slider.
• LEFT ARROW and DOWN ARROW decrease the value of the slider.
• HOME and END move to the minimum and maximum values of the slider.
• PAGE UP and PAGE DOWN optionally increment or decrement the slider by a given amount.

The Vimeo media player below is a good example of these practices in action. The slider can be operated with the keyboard, using the right and left arrow keys to scrub through the video.

Note that all these behaviors must be scripted into the custom control---they do not automatically result from the HTML or WAI-ARIA markup.

In other words, you can’t place the code <div role=”slider”> on a page and expect it to work like a slider, and that the browser will support the expected keyboard commands, as it does with HTML button, link, and input elements. With custom controls, all control information and behaviors must be provided in code, to make the control interactive, accessible, and operable.

For this reason, the best approach is to use native controls wherever possible. Use a custom control only as a last resort, when no native control fits the bill. As an example, an HTML button element supports keyboard usability out of the box. There’s no need to create a custom button.

And also remember: even if it’s possible to make a complex design pattern keyboard-accessible, simplicity of interaction is often the best approach to minimizing errors and maximizing quality of user experience.

Sequence controls so they follow a logical order

Keyboard interaction with complex web applications can be time-consuming, requiring people to move through every active element on a page to reach the one they need. It’s important to pay attention to focus order to improve the experience for keyboard users.

• Make sure that focus order matches visual layout. Pay attention to how controls are sequenced in the underlying code and ensure the code order reflects the visual layout.
• Avoid forcing focus on hidden features such as drop-down menus or expandable content until they have been explicitly exposed. You don’t want to make a keyboard user tab have to through the items in a hidden drop-down menu.

Show which control has focus

A visible focus indicator is one of the simplest ways to improve keyboard usability; unfortunately, it is often neglected. Making the control that currently has focus visually distinct from other controls helps track focus through an interface and helps to reduce the chance of inadvertently activating a control.

While most modern browsers use an obvious focus indicator, the default indicator used by some browsers is a faint gray dotted border, which can be difficult to see. Worse, some websites use CSS that explicitly removes the focus outline, so there is no visual indication at all of which control has keyboard focus. Some commonly used “reset.css” stylesheets set the outline to “0” or “none”.

But you can make sure that there’s visual indication of focus through a single line of CSS. If your design already includes a visual change for mouse hover events, do the same thing for controls when they receive keyboard focus. The following code snippet make links display with a 2-pixel solid blue border when they receive focus:

a:focus {outline: 2px solid blue;}

This approach should apply to all elements that receive focus---including custom controls.

An example

Some browsers (like Firefox shown below) show focus using only a dotted outline. To reinforce the visual indicator, the Pastry Box Project makes its link text change color from black to blue when focused using the keyboard.

The link in focus is given a dotted outline and changes color to blue. In this example, visual indication could be further enhanced by changing the background color of the link text or giving it a solid border.

Checking keyboard usability

Usability best practice is to gather feedback and insights through observed usability evaluations. However, testing keyboard usability is one thing you can do yourself.

Spend a few minutes using the TAB key to move through all active controls in an interface (SHIFT + TAB reverses tab focus order). For each control, check that it receives focus and there’s a visible indication of focus, that it receives focus in a logical sequence, and that it can be operated using standard keyboard commands. When a combo box menu has focus, for example, using the arrow keys should enable navigation through each option in the menu.

Address any problems you find and you’ll go a long way to unlocking the door to a great keyboard user experience.