Designing for Keyboard Accessibility: Getting Around the Page

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

In the previous article in this series, I talked about the importance of keyboard accessibility, what keyboard-only users need from an accessible web page, and covered how to ensure that keyboard — and other — users can determine where they are on the page . This article explores how to design for efficient, logical keyboard navigation around the page.

Most of us can visually scan a page to find content we want to interact with, then move our mouse cursor over it to activate or focus on it. For those who rely on a keyboard to navigate, it’s not always that simple.

Screen reader software has keyboard shortcuts that allow blind users to bring up a list of headings or links, or to move  between headings, table cells, list items and other elements. Keyboard-only users who don’t require a screen reader can use the tab key to move between focusable elements; additionally, Opera offers keyboard shortcuts for heading navigation, and developers have written extensions for browsers like Firefox and Chrome to supply other shortcuts to improve navigation — such as the Heading Navigation Greasemonkey script, which replicates the JAWS keyboard shortcuts for moving between headers.

Skip Links and Landmark Roles

Browsers will tab through focusable elements in the page in the same order that they appear in the code, unless that order is overridden by setting the tabindex attribute. In the early days of accessibility, if your page had a navigation menu at the top, screen readers had to read — and keyboard users had to tab — through the navigation before reaching the main content. Thus was born the concept of the skip link: a link that jumped to the end of a list of repetitive links. If you doubt the importance of this mechanism, try tabbing through a results page on Trulia — 66 tabs just to get to the search box!

Modern screen readers can circumnavigate repetitive blocks by using heading navigation or other keyboard shortcuts, and most other keyboard-only users probably have software or extensions installed that support heading navigation. Both the WCAG 2.0 (guideline 2.4.1) and the US Section 508 standards (provision 1194.22(o)) have provisions for skipping repetitive blocks of content. The WCAG guideline states that one of the sufficient techniques for meeting guideline 2.4.1 is “providing heading elements at the beginning of each section of content.” Section 508 is ambiguous. So it could be argued that skip links are dead.

In addition to heading navigation, WAI ARIA landmark roles are gaining support in screen readers and browsers. These define typical regions of the page — such as banner, main, navigation, complementary, and search — as landmarks that could be navigated using a keyboard. The following image shows the four regions used on this site and their roles:

The four regions are banner (top), main (left), complementary (right), and search (at the top of the complementary region).

Though not yet fully supported, landmark roles are painless to implement and are a big improvement over skip links, so there’s no reason not to add them.

To improve keyboard navigation with skip links and landmark roles:

  • If you use skip links, call out in the design deliverables that a link must be made visible to sighted users when it receives keyboard focus.
  • Consider using skip links from the top of the page to main content and other commonly accessed regions (such as sidebars), and anywhere else where there’s a long list of links that might be useful to skip.
  • Identify which regions of the page should be set up as navigational landmarks, and which landmark role should be used for each.

Tab Order

By default, web browsers set keyboard focus on elements in the same order the elements appear in the code. A typical example of this is the results page for Trulia.

Typical search results page for Trulia, with a banner followed by three columns

Tabbing through this page takes you across the tabs at the top of the page to the search box, then through the filters down the left hand side, then to the For Sale tab at the top of the search results. From there it gets briefly weird, hitting the map on the right before actually going to the first result, but then it follows the middle column down to the bottom, and comes back to hit the ads below the map on the right.

From a content perspective, however, the search results in the middle are most important and should be the first thing in the tab order after the banner. And if you tab through Google search results, which are essentially the same layout — banner on top, filters on left, search results down the middle, and ads on the right — that’s what happens.

Google Search Results page: banner followed by three columns

In both of these cases, the code is written in the same way the tab order flows: Trulia writes the banner and then the left sidebar; Google writes the banner and then search results. Though Trulia could have used the same code and overridden the tab order so it hit the results first, think about  how you’d want to read the page if you turned styles off altogether: what’s the order of importance for each area of content?

Forms are another place where logical ordering is important. For example, here’s the sign in form on Twitter:

A form with the email field on top, password field below, and sign in button (left) and remember me checkbox (right) on the bottom

Though at first glance it looks like the tab order would be Username, Password, Sign in and then Remember me, the Remember me checkbox actually gets keyboard focus before the Sign in button — touching all the inputs before submitting the form.

To improve keyboard navigation using the tab key:

  • Specify in the design deliverables what the order of importance is for content on the page.
  • Indicate places where logical tab order differs from the visible tab order.


Heading navigation is important to screen reader users and other keyboard-only users, but it’s helpful to all users. If you think about heading levels as a table of contents, heading navigation offers a quick overview of the content by jumping from heading to heading.

In order for heading navigation to work well, it requires content to be logically organized. It also relies on semantically correct HTML markup in order to work: a span element styled to look like a heading won’t show up in the list.

Back to Trulia: what content on this page would you expect to be headings?

Typical search results page for Trulia, with a banner followed by three columns

The heading “90210 Real Estate and Homes for Sale,” right? The Trulia logo at the top left? The “Refine Search” label above the filters? The “Search Homes” label? Perhaps the addresses for each of the homes?

Only one of those four items is identified as a heading: the “90210 Real Estate and Homes for Sale” heading above the search results. A keyboard-only user can take advantage of this to skip the hundred-odd tabs it takes to get to the search results. Unfortunately there’s no way to efficiently navigate to the filters: the bold, large text “Refine Search,” which looks like it should be a heading, isn’t.

And back to Google: what are the headings on the Google search results page?

Google Search Results page: banner followed by three columns

The Google logo is a level one heading. There’s a hidden level two heading, “Search Results,” above the search results in the middle column. The link text for each result is a level three heading. “Ads,” in the right-hand column, is a level two heading, and the link text for each ad is a level three heading. There’s another hidden level two heading in the left column, just above where the filters start, titled “Search Options.” And so on.

To improve keyboard navigation using headings:

  • Group content logically under headings, taking reading order into account.
  • Indicate what content on the page should be a heading — regardless of how it’s styled, or if it’s even visible — and what level the heading should be.
  • Specify in the design deliverables that keyboard-only users must be able to navigate by headings.

Now that users can get around your page, the next article will cover the last consideration for keyboard-only users: interacting with interactive components.

January 30, 2011 · Tags: , ,

1 Comment »

RSS feed for comments on this post. TrackBack URL

Leave a Reply