Not Your Father’s Navigation Strategy: There’s More Than Just the TAB Key

When a sighted person, who has no additional disabilities, visits a website or uses a web application, the layout is usually easily processed. Navigation menus, toolbars, side bars, footers, and other components are, typically, visually independent and readily identified. Owing to the way software used by blind people presents a virtual rendering of screen content to a user, the experience for blind visitors is typically much different, though no less functional.

As a blind screen reader user, and in my career educating designers, developers, and testers on accessibility issues, I have had the opportunity to observe the techniques used by various users to understand the layout and operation of web pages and applications. I have also seen well-intentioned sighted testers believe that components or entire sites are not accessible because they were unfamiliar with the techniques of navigating the web without sight.

In this article, I will walk you through the ways a blind screen reader user can navigate a web page, gather information about its layout and organization, and use that knowledge to efficiently and rapidly navigate a site or application. I hope to convey the importance of using techniques other than the TAB key as a primary means of navigating a website and illustrate the power you provide to a screen reader user by following semantic HTML markup and the principles of the Web Content Accessibility Guidelines.

Important Note

It is important to state that most of the information in this article relates to functionality offered by screen access programs. The navigation techniques discussed are not applicable to sighted users who rely on non-mouse input to interact with the web. These are offered as an understanding of how a proficient screen reader user navigates the web in hopes that it will help the reader be less intimidated by the non-visual interface screen readers offer. Other development practices and testing techniques must still be utilized to ensure full keyboard accessibility for all users.

How Screen Access Software Presents the Web

Before diving into how proficient blind users navigate the web, it is important to have a basic understanding of the differences between navigating the web visually and non-visually. If you are looking at a web page, the orientation of elements is likely clear to you: you may have a sidebar on the left, a main content section in the middle, and above that a header and navigation menu structure. A colleague could tell you to click the button in the bottom left corner, and you would have no difficulty understanding what they meant.

For a user of non-visual screen access software however, top, bottom, left, and right are irrelevant. Screen access software, also called screen readers, create a virtual buffer of the page. This virtual rendering is created by analyzing the source code and presenting it to the user in a linear fashion. Controls and content are presented from top to bottom, in the order they are encountered. This is an important thing to understand, because while your eyes may be easily drawn to a prominently placed piece of text whose size has been increased, bolded or italicized, or had its color altered so it stands out, without the appropriate HTML heading element this text will not stand out in the same way to a screen reader user. It will in fact simply appear as plain text.

This is one reason good accessibility experts emphasize the virtues of semantic HTML vs CSS alone. Proper use of elements has not only an impact on the user’s understanding of a site’s content, but as you will shortly see, will play a direct role in aiding rapid navigation.

“What’s Your Beef with the TAB Key?”

The TAB key does play a useful role in navigating interface components. It will move a user from one form field to the next, a form field to a button, and in fact any element which asserts to the browser that it is focusable.

Many sighted testers, and unfortunately blind people, have been taught only to navigate in this manner. Why is this a problem? You may have noticed a key word when I mentioned to what elements the TAB key moves a user: focusable. This means a potential loss in orientation as elements critical to understanding the page like headings, the beginning and ending of tables, and certain landmarks may not be read. Strictly using the TAB key alone is likely to cause a user to be disoriented and unable to understand how the currently focused element relates to other page elements, or even fully report where they are when asked.

A simple solution would seem to be, make everything focusable, right? Consider the page summary provided by JAWS for the Wikipedia homepage today:

This page contains

  • 327 links,
  • 13 regions,
  • 15 headings,
    • 9 at level 2,
    • 6 at level 3,
  • 3 forms.

Based on the link count alone, you can see there are over three hundred individually focusable elements. Add to that a minimum of one press of the TAB key for each of the seven paragraph elements and that number goes up to 330. I say at least one because if there is a link inside the paragraph, you must make the text before it focusable, and the text after the link as well. Additionally, it took twenty key presses before I reached the featured article content. (Wikipedia’s home page does not have a skip to content link.) Taking these facts into account, it becomes clear that relying on the TAB key alone is likely to result in a slow and inefficient navigation experience.

So then, how should a screen reader user, or tester, examine a web page, learn its structure, and navigate it?

Page Summary

A summary statement, provided by many screen access programs, can offer an overview of the page’s contents immediately after the page completes loading. Typical data in these summaries includes the number of links, number of headings, and number of regions. As demonstrated above, slightly more detail is available if the summary is manually accessed.

This summary often provides the user with ideas on how to go about learning the page’s construction. For example, if a page has no headings, but does have regions, I would know that using techniques to navigate by heading will be useless and instead rely on other elements. A page with more than a thousand links … will be navigable, but terrifying.

Element Lists

All modern screen access packages provide a mechanism to list HTML elements that can be used to move through a page’s content or activate functions. Examples of elements included in various lists include:

  • Headings
  • Links
  • Form fields (including input controls and buttons)
  • Tables

Some screen access programs additionally include landmark elements like articles and regions. Some also provide extremely granular information as with JAWS’s list items list (which, as its name implies, consolidates every <li> element on the page into one master list). Many people find the use of element lists helpful in both learning a page’s structure and finding information. For example, a links list will allow you to quickly find the “Contact Us” link on a company’s website simply by pressing a hotkey and using first letter navigation until you find the link. Pressing ENTER will activate the link, or move you to it, depending on the screen access program and your user settings.

Quick Navigation Keys

Using quick navigation keys enables a user to move immediately to the next or previous element of a given type. For example, pressing the letter h, in JAWS and NVDA, will move the user’s focus to the next heading. Pressing SHIFT+H, will move to the previous heading.

Software offering quick key navigation will often provide keys for the same elements available in the HTML elements lists, and occasionally others. One enhanced feature for heading navigation is often the ability to use the numbers one through six on the number row of your keyboard to move to headings of that specific level.

Quick navigation keys aren’t only useful for finding elements, but they also allow a user to easily exit or skip a large element they would like to move past. In NVDA, pressing the comma , key will bypass the element where the user is focused. This enables the quick skipping of a large table or list of links.

A couple points to keep in mind about when quick navigation keys work, and when they don’t: in order that quick navigation keys will work, your screen access program must be presenting a virtual buffer. That is, you cannot be in forms mode, and you must be navigating HTML content.

Your screen access program must also be set up to use quick navigation keys. JAWS and NVDA offer them by default, but VoiceOver on a Mac requires that you enable the feature in its settings. Likewise, if you are using a Bluetooth keyboard on iOS, you must press the left and right arrow keys simultaneously to enable the quick navigation mode.

Another situation in which quick navigation won’t work is when a web application overrides the keys used for navigation. For example, the Twitter and Facebook web apps use the j and k keys to move to the previous and next tweet or story making them unavailable in JAWS to be used to jump to a line number (j) or move to a user-defined place marker (k). This isn’t necessarily a problem, but it is something to be aware of if the site or application you are testing implements its own single letter hotkeys.

Putting It Together

You now know that screen access software provides page summaries, element lists, and quick navigation keys to aid in user efficiency and understanding. Let’s talk about how to put that all together.

When you first arrive on a page, listen for the screen access program’s quick summary of the page.

  • Does it report headings, links, and regions? If so, try using these elements to understand the layout of the page. Press 1, does it move you to a heading at level 1 where the page’s main content starts? (Or in some cases, the site’s title, and a second press take you to the content’s title.)
  • Can you move to subheadings and sidebars with heading commands? How about moving around by HTML and ARIA regions?
  • If you are trying to navigate to a specific component, can you locate it by navigating to a reasonably close element such as a heading or landmark?

When I first arrive on a page, I usually try to navigate by heading to find a section title that sounds like it’s close to the information I’m seeking. Either a main title, or a subsection of the page. I also try to get a feel for the page by examining how the headings are oriented in relation to each other. I look to see whether there is good heading structure or whether it seems that headings have been weighted for purposes of aesthetic considerations. As I use a site more regularly, I learn how the designers and developers have used various HTML markup, which enables me to move around more efficiently.

When it comes to web applications, landmarks help, but I will also try to determine if the application has any custom keyboard commands. For example, Microsoft Outlook online uses a hotkey to enable a user to move between the folder list, search bar, message list, and the message text itself. If the application properly manages focus, this can make it so finding your place as a blind user is not extra complicated. While it is not necessary, or even a good idea, for informational websites to custom code hotkeys, I offer that example to illustrate another way to enhance a web application.

Conclusion

While use of the TAB key for navigation among web components is appropriate in the right circumstances, it is probably the slowest way to move through the entirety of a web page or application. Effectively utilizing quick navigation keys and element lists can offer greater flexibility for screen access software users. For these features to work properly, it is necessary for developers to utilize semantic HTML elements to communicate necessary information about what a component truly is to the web browser, accessibility API, and screen access programs.

Resources

Rachel Olivero

About Rachel Olivero

Rachel Olivero is the Director of Organizational Technology for the National Federation of the Blind. In her current role, she leads the access an information technology efforts for the nation's oldest and largest consumer organization of blind people. Her previous roles have included coordinating web accessibility efforts for a US fortune 100 insurance company, web accessibility analysis and consulting for the NFB's Access Technology team, and IT consulting for small businesses. She has ten years of professional experience in web accessibility, twenty in information technology, and has been a user of one form of access technology or another since she got her hands on her first computer at the age of four.