Designing for Keyboard Accessibility: Location, Location, Location

This is part 2 of a series that begins here: Designing for Accessibility

In the previous article in this series, I talked about how designing for universal access up front can improve usability for all users and make it easier to develop software, and I introduced five questions for designers to ask when designing a page. The next few articles explore the first question: how does someone who is not using a pointer device interact with this page?

Why keyboard accessibility is important

The W3C WCAG 2.0 guidelines recommend that all functionality on a page be accessible [operable] from the keyboard.  Keyboard accessibility is one of the most important building blocks for universal access, as it impacts the broadest audience.

There are several reasons why a user might interact with a page using a keyboard:

  • The user may have a vision impairment that prevents them from seeing a pointer on the screen.
  • The user may lack the motor control required to use a pointer device.
  • The user may be in an environment that isn’t conducive to using a pointer device.
  • It’s often more efficient to use a keyboard than it is to use a mouse.

Interactions made available via keyboard are also available to most assistive technologies such as screen readers, alternative keyboards and voice recognition software. Users without disabilities can also benefit — such as a seniors who has difficulty maneuvering a mouse, or someone with a repetitive stress injury.

What keyboard users need

Keyboard users need to be able to:

  • identify where they are on the page
  • navigate efficiently around the page (and around the site)
  • interact with interactive components

Provide visual feedback of the location of current focus

It’s a lot easier to find your way around a page if you can see where you are. Most browsers provide some default visual indication that an element has received focus, such as a black dotted line or a blue drop shadow. (If you’re curious about your browser’s default styles, here’s a focus test page. Tab through to see what happens.)

If web pages always used default styles, figuring out where you are wouldn’t be much of a problem. Of course, the web hasn’t looked like that since the early 1990s. Now, outlines can be lost against the background color or suppressed completely as part of the visual design. Additionally, browsers are inconsistent in how they apply styles.

Take, for example, Google, which sets outline to 0 on its search buttons. This image shows how the Google Search button is displayed when it has focus on three different browsers: Safari, Internet Explorer 8, and Firefox.

Google Search Button as it appears (from left to right) in Safari, IE 8, and Firefox. Only Firefox shows the outline to indicate the button has focus.

This is a simple case, and users might be able to guess where they are based on the proximity of the buttons to where they just tabbed from, but only Firefox users know for sure.

Help keyboard users identify where they are on the page by:

  • applying distinct visual styles to form controls, links and other elements when they have focus
  • indicating in your design deliverables that styles applied when the user hovers over an element must also be applied when the element receives keyboard focus

Don’t rely solely on changing the cursor style, as keyboard users and those accessing the page from mobile devices won’t see it.

Now that we’ve covered how keyboard users can see where they are, the next article will talk about how to get around.

January 16, 2011 · Tags: , ,


  • Sofia Celic-Li says:

    It is important to note that the visual style applied to form controls, links and other elements when they have focus should not be a color change alone. Some visual impairments result in an inability to use the authored color palette at all and some result in an inability to distinguish the slight changes in color that are often used to indicate a focused state. Always include a non-color change as well. The focused state could include a change of font attribute (family, size, weight, style), addition of a border, changing the thickness of the border line, adding an underline, etc.


  • Shannon Hale says:

    Hey Sofia! Thanks for adding this very important point. I didn’t forget, I was going to cover that when I got to visual impairments — but it should be here too. You also made me realize that the way I asked the 5 questions, it seems like I was only planning on covering blind users in question #2, not all vision impairments. I’ll think about how to rephrase it.

RSS feed for comments on this post. TrackBack URL

Leave a Reply