Not only must assistive technology users be able to perceive web content, they also have to be able to get to it in an efficient manner. Reading straight through a document top to bottom is a scenario that rarely happens, for any user. How, then, do assistive technology (AT) users get around on a web page? The answer is mostly by tabbing, search, and, in the case of screen readers, using lists of headings and links to jump to the relevant parts of the web page or website. Try navigating through a web page using just your keyboard—you will experience navigating the web in a new way. How long does it take you to reach the main content? Can you operate the main menu with just the tab and arrow keys? Can you see everything that receives keyboard focus? The following coding practices will make it easier for AT users to navigate your pages.

Skip-navigation links

Skip-navigation links are not just for screen reader users. They also allow those who cannot use a mouse to circumvent cumbersome navigation menus and side bars, which can render a page functionally inaccessible. Consider a fly-out or drop down menu with a total of around 100 items (not unusual). Someone relying on keyboard navigation will usually have to tab through all of the navigation items to reach the main content on the page. If that person were using a screen reader, they could jump to the first <h1> tag get to the page content (if the page has headings). Otherwise, it would be a slog to reach the content. The skip-navigation link should be visible on keyboard focus so that a sighted keyboard user will know it is there. View the WebAIM article on coding skip-navigation links for more information.

The main navigation on your site needs to be visible to assistive technology and operable using the keyboard only. Most CSS menus are technically accessible, although sighted keyboard users will not see submenu items when tabbing through a CSS menu, and fly-out and drop-down menus are not activated on keyboard focus. Navigation menus based on DHTML or Flash are rarely accessible. Workarounds must be used with DHTML, and Flash requires expertise to make it accessible. If you do decide to code advanced menu features, use progressive enhancement in designing your menus, which in a nutshell entails making the menu work for the most basic browser configurations while allowing for more complicated interaction that is supported by external CSS and javascript files. The Yahoo! Finance page is a good example of a navigation bar that works well with the keyboard, employing a full-tab approach.

View more information on accessible dynamic menus»

One aspect of CSS rollover menus that should be emphasized is that a screen reader user may, depending on how the menus are coded, access all of the nested items in the unordered list, not just the top-level items. Depending how “heavy” the fly-outs or drop-downs are, the total number of links on a page could become onerous. Consider using fewer menu picks and a slightly “deeper” site organization. It is better to engineer two easy clicks to get to a destination than one arduous click with a lot of “cognitive overhead.”

Also, complex drop-down or fly-out menus, e.g., with multiple columns, not only can have unfortunate consequences for screen reader users, they also can have a negative impact on those with cognitive, low vision, and dexterity impairments. Multicolumn menus hold a great attraction when designing sites with complex information architectures, but they introduce significant accessibility and usability issues.

back to top

Proper headings

A primary navigational aid on a web page for a screen reader is the <h1> header, which should both uniquely identify the page in the website and should be placed directly in front of the main content of the page. The <h1> header should also match at least a subset of the the page <title>. Screen readers can produce a list of headings on a page, from which the user can select and jump to that location on the page. So, a correctly positioned <h1> tag allows an assistive tech user to get right to the business end of the page. Note that this technique provides similar functionality to the “skip nav” link for a screen reader user (but not a sighted user, unless s/he is using Opera keyboard navigation). Do not simply format text as large and bold to make a heading.

It is also important to make sure that your headings are properly nested, i.e., the <h2> tags follow the <h1> tag, the <h3> tags follow the <h2> tags, etc. Don’t select heading levels for their default size—use CSS to style your headings. Properly nesting your headings will convey the page organization to the assistive tech user. The following is an example of proper nesting:

  • <h1>
    • <h2>
    • <h2>
      • <h3>
      • <h3>
    • <h2>

back to top

An exception can be made in the case of using headings, visible or off-page, to indicate a navigation menu. Use <h2>s for these headings. Don’t worry if they precede the first <h1>, as they commonly do in the coding order.

Neutered Links

It is possible to code a link using javascript and event handlers and omit the href attribute (i.e., neuter the link). Unfortunately this practice has negative consequences for keyboard-only and other assistive tech users. Neutered links do not receive keyboard focus unless you add a tabindex attribute, and even with a tabindex, the link will not be able to receive a click event from the keyboard.

There are two solutions to this problem:

  1. Use a <button> instead of an <a>:
    <a class="btn" href="#" role="button">Link with role="button"</a>
  2. Add the href and optional role="button" attributes:
    <a class="btn" href="#" role="button">Link with role="button"</a>

Screen readers can produce a list of links found on a web page, in similar fashion to providing a list of headings. This can be a useful way to navigate a webpage—as long as the descriptions for the links are meaningful. If a page is littered with “click here” and “more” links, the screen reader user will have no clue what these links mean when they are presented in a list of links or when the user tabs through site from link to link. Likewise, using a URL as a link description can baffle a screen reader user because the screen reader will attempt to pronounce the URL as if it were a word and the description will sound like gibberish.

Document landmark roles

Document landmark roles are an ARIA specification that alert a screen reader user to the overall geographic regions on a web page:

  • Banner
  • Navigation
  • Search
  • Main content
  • Auxiliary content
  • Posted content
  • Footer information

The code for landmark roles is easy to add to your web page—simply add a role attribute to a <div> tag (e.g., <div id="maincontent" role="main"></div>). Note that at this time the W3C validator will not recognize the role attribute, but using this attribute will not adversely affect your code in any way, and landmark roles are of great benefit to screenreader users. See more information about landmark roles »

back to top