Updated January 23rd, 2018

Building an accessible website is a holistic endeavor. In order to provide easy access to the information on each page, myriad factors must be considered. One of the chief amongst these is the creation of accessible navigation. Whether considering business logic or a principled perspective on web design, enabling the site user to move within your pages is of key importance. This article will describe the principles of accessible navigation and demonstrate ways to create it using CSS (Cascading Style Sheets) and XHTML (eXtensible HyperText Markup Language - HTML reformulated as XML (eXtensible Markup Language)).

The code snippets provided in this article are intended to be demonstrative of accessible design practice – they are not complete examples of a live CSS menu. There are many other articles on the web which will provide the technical details of building a CSS-based menu.

Understanding an Accessible Menu

What makes a menu accessible?

Any number of circumstances can effect the usability of your navigation. Inaccessibility is present whenever any user, using any device, is unable to take advantage of the information you are offering. A truly accessible menu will have considered all of these possibilities:

  • User agents without Javascript, CSS, or rich media formats (Flash, Java)

    Includes some screen readers, search engine spiders, the Lynx browser, and any modern browser where the user has made this choice.

  • Users with difficulty reading text

    Can include dyslexic or autistic visitors, sometimes deaf visitors, and, always, blind visitors.

  • Users with difficulty seeing low-contrast colors or certain color contrasts

    Color blindness causes a number of contrast problems, as do many other factors as the eye ages.

  • Users with problems seeing small type

    Very common amongst older users or users with degenerative sight syndromes such as Macular Degeneration.

  • Conflicts with user agent defaults

    Use of defined accessibility features such as tabindex or accesskeys can create conflicts with the normal behavior of a visitor’s browser. See Accesskeys: Curse or Blessing?

Most of these issues are accomplished very easily by using a simple list format in HTML (HyperText Markup Language)/XHTML with clear, simple texts. This is the basis of accessible navigation. When all additional tools are stripped away, the menu must remain usable. One part of the art of accessible design is the removal of all barriers to access.


<ul>
<li><a href="/">Home</a></li>
<li><a href="/news.php">News</a></li>
<li><a href="/bio.php">Biography</a></li>
</ul>

This simple markup will be accessible – by itself. However, any menu can be made inaccessible simply by making it difficult to reach. Although visual browsers can easily scan over an entire page and jump directly to navigation, those using screen readers may struggle. Screen readers are a predominantly linear means of accessing information. Although they provide some methods for navigating around a page, it can be helpful to provide your own shortcuts. A designer can not, at this time, depend on the user agent to provide all the tools of accessibility which are needed.

Because of this, it is important to provide two navigation bars on any page. The main navigation can be located any where on the page and anywhere in the code. The secondary navigation must be located very early in the code – preferably, the first element following the <body> tag. This navigation, also using a simple list for markup, needs to provide internal page links. Quick navigation to skip directly to the navigation, content, footer – any discrete division of the page which contains unique information. Keep this navigation short, so as not to waste the visitor’s time spent listening to their screen reader.

Your code now should contain this:


<ul id="skiplinks">
<li><a href="#content">To Content</a></li>
<li><a href="#navigation">To Navigation</a></li>
<li><a href="#footer">To Footer</a></li>
</ul>
...
<ul id="navigation">
<li><a href="/">Home</a></li>
<li><a href="/news.php">News</a></li>
<li><a href="/bio.php">Biography</a></li>
</ul>

At this point, you have created fully accessible navigation. Congratulations! By not using Flash, Javascript, or any styling, you have created a perfectly accessible menu. It is, however, probably not exactly the look you’re searching for.

Styling your Accessible Menu

Cascading style sheets can be a powerful tool to transform your boring accessible navigation into a beautiful navigation menu. They can also be used to transform your boring accessible navigation into a beautiful, inaccessible navigation menu. At this stage, when styling the menu, you need to begin considering your users who will be using visual browsers and navigating by eye. These visitors can be negatively effected by low color contrast, lack of consideration for color blindness, or undersized fonts.

This isn’t really an article about building a navigation menu with CSS. The CSS technique you use to style your menu is not a significant part of what makes the menu accessible. However, since CSS is used to control all of the factors which can have an effect either to enhance or detract from a menu’s accessibility, I will discuss some specific methods which are used.

It’s normal, when creating a navigation menu in CSS, to begin by removing bullets. I’m not aware that this has any impact on accessibility at all, whether you choose to do it or not. Navigation is not expected to be in bulleted list format from a visual perspective, so go right ahead.


#navigation {
list-style: none;
margin: 0;
padding: 0;
}

Color Contrast

It’s the remaining steps which are more important: selection of background colors, whether to underline or not, text colors, any use of symbolic cues. The formulas for calculating color contrast values are complex. It’s not necessary to understand these formulas, thankfully, because other people do, and these people have thoughtfully provided online tools for testing your values. You may wish to test your chosen color values using Gez Lemon’s Colour Contrast Analyser or his Luminosity Contrast Ratio Analyser. The color contrast analyzer is an older tool based on guidelines from the Web Content Accessibility Guidelines 1.0. The luminosity analyzer tests are based on the formula used in WCAG (Web Content Accessibility Guidelines) 2.0.


#navigation a {
display: block;
background: #f5f5f5;
color: #222;
}

This particular combination of colors has a luminosity contrast ratio of 15.61; which passes the guidelines handily. In addition, the colors chosen will provide no conflict for any color blind viewer – this can be tested using Vischeck, a service which will simulate your site as a color blind individual may view it.

However, it is insufficient to select a set of colors for your links and be done with it. Your :hover state must also have sufficient contrast, as must each other state of the link – :active,:focus, and :visited. This can be a challenge – providing states which are unique for each state yet consistent with your color scheme and high contrast. It is not necessary to make certain that every state is different – however, it is important that you define at least three unique states: normal, :hover, and :focus/:active.

It is common to style the :active and :focus states to be identical. The reason for this is that Internet Explorer, demonstrating the infinite wisdom of Microsoft, made the decision to use the Active state in the situations normally reserved for Focus by other browsers. Active styling is intended to come into play while a link is being used. While your mouse button is depressed, this state is triggered. Focus styling should be used while a link is selected, but not activated. This is most commonly seen while navigating through a site using your keyboard, and this is why it’s a particularly crucial to make use of it.

For mouse browsing, the :hover state is sufficient to identify a link. In addition, the mouse cursor itself will clearly indicate to the user where on the page they currently are active. However, a user making use of alternate navigation needs an alternate indicator to indicate their currently selected option. Many browsers default to providing a 1 pixel dotted border to a focused element – if you consider the possibility that a user may also have even a slight visual disability, this is absolutely insufficient.

Underlining

To underline or not to underline, that is the question. There is some debate whether or not underlining a link provides a benefit for users. I think, as with everything, that this is a question of context. If your navigation menu looks much like the rest of your content, which no clear labels or other delineation, you have a usability problem. However, as long as it is clear (and this is a highly subjective question) that your menu is intended for navigation, you should be fine. As with many accessibility issues, this is simply an issue of judgement.

Font Size

What’s most important about your default font-size is that it be flexible. Although I encourage the default size to be reasonably readable, it’s most important that you not prevent the user from changing that size. The use of pixels to control your font size will prevent visitors using Internet Explorer 6 from changing the size of your text. All font-sizes should ideally be expressed either in em units or in percentages. With em‘s, the displayed font-size is based relative to the default font-size of the user agent. This puts your visitor in control.

Other Visual Cues

Above, I mentioned that some users with cognitive disabilities may struggle with written text. Even though a dyslexic or autistic user may be perfectly capable of reading the text, it may be a struggle. Graphical cues can be very helpful. Coming up with logical "signposts" for your links can be a challenge. It’s not necessary to try and invent something, however – it’s best to use standard symbology. For your home page, a small graphic of a house may be useful. For a contact page, perhaps a phone receiver or an envelope. For your page about monkeys; a cartoon graphic of a monkey. These graphics are not a substitute for your text; they act to supplement your text links to make it easier to discern the intended meaning.

This, of course, requires some changes to your nice little navigation code. In order to send unique images to each menu item, you’ll need to provide a style hook to each menu item.


<ul id="skiplinks">
<li><a href="#content">To Content</a></li>
<li><a href="#navigation">To Navigation</a></li>
<li><a href="#footer">To Footer</a></li>
</ul>
...
<ul id="navigation">
<li class="home"><a href="/">Home</a></li>
<li class="news"><a href="/news.php">News</a></li>
<li class="biography"><a href="/bio.php">Biography</a></li>
</ul>

Styling your Skip links

How to style skip links and when they should be visible is commonly debated. It is a complex issue; and I’ve gone both ways in the past. Today, I come down firmly on the side that they should always be visible. Making the links visible provides them with optimal usability, since all visitors may immediately find them. Skip links have predominantly been considered an aid for visually impaired web users, but they also assist people with cognitive or motor difficulties.

Regardless of your choice about constant visibility, you should make your skip links visible when they receive keyboard focus. As with any other focus state, you need to consider the fact that before an element on the page receives focus, the user frequently doesn’t know where that element will be. When you press the tab key, you only know that you will move to the next focusable element; you don’t know where that is actually located on the page. Because of this, focus state needs to be strong. A nominal change significantly hinders the ability of keyboard users to locate their own position on the page.

Accessibility and State

Stateful and Stateless
Stateful and stateless are adjectives that describe whether a computer or computer program is designed to note and remember one or more preceding events in a given sequence of interactions with a user, another computer or program, a device, or other outside element.

"State" is a term used to describe an ability to interact with code such that the code will remember and stick in their existing condition. HTML is, by nature, a stateless technology. A pure CSS and HTML menu can not remember any information about your interaction with it. In accessible navigation, state is important because of mobility problems. This is important when a user must access a menu with drop-down features (like the "articles" section of this site). For a person with average motor control, it is trivial to navigate this menu using a mouse.

However, the menu cannot be accessed using normal keyboard navigation (by use of the tab key), unless the stylesheet has been disabled. Therefore, people with motor control problems will be confined to the use of a mouse. If you have difficult keeping your mouse within a specific path or on a particular patch of monitor space, it will become incredibly difficult to use this kind of menu. Providing state to a menu, accomplishable using JavaScript, can be very helpful, because you can then provide a means to make the menu remain in place after it has been activated, until some additional action changes it’s state again.

Any use of JavaScript must be taken into consideration carefully; be certain that the loss of JavaScript will not prevent your menu from functioning. This additional scripting, like anything, should only add extra functionality. For this site, the dropdown list of articles is merely an alternate access point – all articles can also be accessed by choosing the link to the main articles page.

In Conclusion

All of these recommendations are based in common sense design. Common sense dictates that you use the simplest tools which will maximize the possibility a visitor can successfully use your website. I’ve based this entire article discussing a very simple, one-tiered menu system. At this scale, it is trivial to make your navigation accessible by applying these guidelines. Larger, industrial-scale menus introduce more significant problems. These problems are not technological in nature – it is easy to build a larger-scale CSS based menu to handle hundreds of pages. At a large scale, problems of accessibility are predominantly cognitive. The challenges of designing a extended navigation system which is intuitively usable while managing hundreds or thousands of pages is, perhaps, an issue for a separate article.

In the end, building an accessible menu extends well beyond the practice of valid XHTML. Although a validly written menu will be accessible at some level, it’s critical to consider the ability of users to reach your menu, the variety of ways in which users may look at or hear your menu, and the abilities of those users to process the information you’ve provided in your menu. CSS can be used to maximize usability of your menu in a visual environment; but must be used with care, since poor styling choices can result in a menu with reduced usability, regardless of the quality and consideration you’ve taken in constructing your HTML code.

Further Information and Tools:

Menus with Cascading Style Sheets