Navigation Accessibility: Menus and Links

Once again, even thought this was published in 2004 everything in this post is worthy the analysis. Enjoy.
Roger Hudson, August 2004


The Web is a navigation environment, where travellers move around in a virtual world by activating hypertext links. Successful Websites have logical navigation systems that mirror real world navigational expectations and experiences and have been built to meet the needs of the site user.

There are many good books and Websites with information about designing usable navigation systems. Rather than going over well-travelled ground, this document is the first of two that will consider the accessibility implications of Website navigation and how access to site content for people with disabilities might be enhanced.

“Provide clear and consistent navigation mechanisms – orientation information, navigation bars, a site map etc. – to increase the likelihood that a person will find what they are looking for at a site.”

Web Content Accessibility Guideline
Position of navigation elements

Website navigation needs to provide adequate navigational choices so that users can find what they want, while at the same time not presenting the user with so many options that they become overloaded. A very broad site allows all items to be accessed with very few interactions, but all choices have to be on display at all times. Whereas, a deep site will display only a few choices, but the user has to dig down through multiple layers to get what they want.

The navigation menu on each page of a site provides the user with the results of the balance that has to be found between site breadth and depth. The placement and design of the navigation menu or menus will help determine the overall usability of the site and can greatly influence the accessibility of the site for people with disabilities.

Navigation elements can be presented at the top, bottom or on either side of a Web page. There are no rules stating where the navigation should appear on the page and over time various combinations of the different possible locations for navigation menus have been tried and tested by Web designers and usability specialists.

Top and/or left-hand navigation

During the early years of the Web, site navigation was often in the form of a bar across the top of each site page. This is still a very common practice, particularly with smaller sites.

More recently, there has been a move to left-hand navigation (sometimes in conjunction with a top navigation bar).

All Web users, including those with disabilities, are assisted when the site navigation is where they expect it to be and in general that means the top or left side of the page.

Global and local navigation

Many sites now provide global (or primary) navigation to the main areas of the site and local navigation within each area of the site.

On some sites the global navigation is in a bar at the top of the page and the local navigation for each site area is in a column on the left, or occasionally the right, of the page. On other sites, the global and local navigation are both presented in the left hand column.

When global and local navigation are incorporated into a single navigation column, the usual default setting is to display only the global navigation, or top-level choices. When one of the global areas is selected the navigation bar expands to include the local navigation within that area. The left navigation column will sometimes expand further to incorporate the choices available at deeper levels of the site.

The presentation of global and local navigation choices within the same column allows them to be easily associated by the user, which may benefit some people with cognitive or learning difficulties. A long left-hand navigation column however, can cause difficulties for some assistive technology users. Without an adequate way of bypassing the navigation, a physically impaired user who is dependent on a single switching device, maybe be forced to click through many links before getting to the page content they are seeking.

At this stage, it appears that many assistive technology users are more comfortable with the presentation of global navigation at the top of the page and local navigation in a left-hand column.

Navigation menus and labels

Images for text

Navigation menus on some sites present the links as images. Sometimes the use of images is obvious, for example when the navigation choices are buttons. In these situations, the text for the navigation labels is incorporated into the images. In other cases however, the appearance of the link text on the screen is similar to other text on the page, but is in fact an image.

Images are often used for navigation elements as a way of providing feedback to the user through JavaScript mouseovers (rollovers). As the user moves the mouse onto the image, JavaScript will switch the display to an alternative image. JavaScript however, can cause some problems for users of assistive technologies. Similar mouseover user-feedback that is more accessible can be provided with Cascading Style Sheets.

The use of images for text can cause significant accessibility problems, particularly for users with impaired vision (including many elderly people) since they are unable to use the browser to increase the size of the navigation labels. Also, without an appropriate alternative (alt) text for each link label, the navigation may be inaccessible to users of screen reading technologies.

“When an appropriate markup language exists, use markup rather than images to convey information. [Priority 2]”

WCAG Checkpoint 3.1

Navigation labels

Navigation labels should be short and easy to understand. The words used for the labels (links) should also be sufficiently descriptive to provide a clear indication of the page they link to.

The text used for navigation labels and other links on a page should closely match the main heading of each page they refer to. When a user selects a link, the match between the link label and the resulting page provides feedback to the user helping them confirm the outcome and appropriateness of their choice.

“Clearly identify the target of each link. Link text should be meaningful enough to make sense when read out of context – either on its own or as part of a sequence of other links. Link text should also be terse. [Priority 2]”

WCAG Checkpoint 13.1

Meaningful link text

With screen readers like JAWS, a user can display a list of all the link labels on a Web page with a few keystrokes. Many blind users of the Web use this facility to quickly navigating through various pages as they search for information. For it to work effectively however, each link label must be unique and sufficiently descriptive so that it can be easily understood.

The Websites for media organisations often contain pages with a large number of links. Typically these pages will contain brief summaries of news stories with a heading, and sometimes a photo, and then a link to the full story.

For example, a hypothetical Web page might contain the summaries of ten or more stories. One of the summaries is for a news item on a ‘New Health Scare’, with an illustrative photograph, and another is for an opinion piece on the ‘World Health Crisis’ with a photograph of the author, Tom Jones. With summaries such as these, the story title, the supporting photograph and the word “more” at the end of the summary are often all links to the full story.

When a user asks JAWS to read the links contained in the two story summaries described above, JAWS will present the labels for each link (including the images). For this example the links might be read as follows:

new health scare
world health crisis
For a sighted user of the site, who is able to quickly scan the actual Web page and consider each link within its context, all these links are likely to be meaningful. For the user who is dependent on a screen reader however, the labelling of many of these links is likely to considerably reduce the accessibility of the site.

The repeated use of the link labels such as “more” or “click here” on the same Web page is a common practise on many sites. The “more” link appears twice in the example above and if there were ten story summaries it would appear ten times. When the list of links is presented in the order they appear on the site, as above, the user will be able to gain a clue to the context of each link by referring to the link that precedes it. However, some screen reader users opt to have the link listed presented alphabetically and for these people a list of ten “more” links is not likely to be useful.

Unique link labels

The use of different labels for links to the same page can also cause significant problems for screen reader users. Consider the following excerpt of link labels from the previous example.

new health scare

It is not uncommon for three links like these, which are all associated with the same story, to point to the same page, in this case the full article “New Health Scare”. However, since the labels for each link is different it would be reasonable for the user to assume that each link points to a different page. At best, they might think the first link points to the page, “New Health Scare”, and the next two links point to another page, “3/newsph_health”, but with little indication what this page might be about.

The Link Context Checker will display each link on a page out of context and can be used to check the appropriateness of link labels.

Cues and feedback

Presentation of navigation elements should incorporate visual and non-visual cues that indicate the range of possible choices and the appropriate action required to make a choice. The navigation system should also provide the user with feedback so that they know if their actions have been successful.

The basic coding language for Web pages, HTML, incorporates cues and feedback mechanisms for the user. For example, when the mouse moves over an image or text containing a link the default setting is for the cursor appearance to change from an arrow to a hand with a pointing finger. This suggests to the user that the item is some how different to the surrounding material and provides a clue to the possible action that is required. The use of different default colours for visited and unvisited links provides feedback about which pages of a site have already been visited.

Page titles

The inclusion of a meaningful title within the element in the head section of each page enhances the usability of a Website. The page title is displayed in the window title-bar at the top of the screen, providing feedback and orientation to users of the site. The title is also displayed in the search results of most search engines helping users identify those pages that are likely to be of the greatest interest.

The use of unique and meaningful page titles can also improve the accessibility of a site for people who rely on screen readers such as JAWS to use the Web. The page title line is the first thing read out by a screen reader when a page is visited and the keyboard can be used to get the page title read at anytime. Some screen readers also provide keyboard short cuts that allow users to hear a list of the windows that are currently open and to tab through open windows hearing the title of each as it is displayed.

A meaningful page title should communicate both the identity of the site and the page within that site.

Dynamic menus

The desire to make the navigation on sites more ‘interactive or interesting’ saw a rise in the use of dynamic html, most commonly JavaScript, for a few years. Earlier in this document, we considered the use of JavaScript to provide user-feedback by replacing one image with another as the mouse passes over it. JavaScript can also be used to control the generation and presentation of navigation elements. One of the most common uses is to generate a “fly-over” or “drop-down” list of different level menu items for each main heading in the site navigation.

“Ensure that pages are usable when scripts, applets or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.[Priority 1]”

WCAG Checkpoint 6.3

“Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies. [Priority 1 if functionality is important and not presented elsewhere, otherwise Priority 2]”

WCAG Checkpoint 8.1
While the use of JavaScript for the presentation of site navigation elements may result in some minor improvement in the user-experience for able-bodied users, it can be the source of significant problems for users with vision and physical difficulties.

Dynamic menus, like those described above, rely mainly on the use of the mouse and there is no standard way of making them keyboard accessible for people who cannot use a mouse. Blind users for example, cannot position a cursor visually and so use the keyboard in conjunction with a screen reader to access the different elements of a Web page. People with severe physical disabilities rely on simple switching devices, which mirror the function of the keyboard tab key, to move around the page. In both cases, the use of JavaScript can render the resulting navigation items inaccessible to users of these technologies.

If the link function is not applied to the navigation image, but is incorporated in the JavaScript, it will be impossible for the users of many assistive technologies to use the site resulting non-compliance with WCAG Checkpoint 6.3. This violation can be overcome by ensuring users without JavaScript enabled are able to go directly from the primary navigation menu item to a page that contains all the next-level navigation choices within that area of the site.

“Fly over” menus can cause problems for vision-impaired users who rely on screen magnification programs such as Zoom Text and for people with cognitive disabilities who become disorientated when part of the page is hidden. These navigation menus can also cause difficulties for people who find it hard to control the mouse as they move it through the different choices to make a selection.

On some sites global or, more commonly, local navigation menus are generated dynamically and presented on the user’s screen on the fly often by a combination of JavaScript and Style Sheets. If JavaScript and/or Style Sheets are not supported by the user’s browser, these navigation elements are not displayed rendering the site inaccessible.

The accessibility problems associated with JavaScript have seen an increasing move away from the use of JavaScript for navigation in recent times.

Question of colour

Colour is often used to indicate different areas of a Web page, provide feedback and highlight headings and selected areas of text. With all these uses, care needs to be taken so that people who have difficulties distinguishing different colours are still able to use the site effectively.

“Ensure that all information conveyed with colour is also available without colour, for example for context or markup.[Priority1]”
WCAG Checkpoint 2.1
If colour alone is used to convey information then people who are unable to differentiate between certain colours will not be able to access that information. Nearly 9% of men (and a far smaller percentage of women) have colour vision deficiencies.

It is unlikely site navigation will ever rely solely on colour, however colour is often used to provide navigational feedback. For example, by matching the colour of a navigation link button with an identifying colour on the related page, or changing the colour of a navigation link to indicate the page is being displayed. The use of colour in these ways can enhance the usability of site for all sighted users and can be of particular benefit to people with cognitive and learning difficulties. The feedback will only be useful for people with colour vision deficits if they are able to distinguish the different colours.

The Vischeck Web site ( can be used to simulate various colour vision problems. Vischeck is a free online service that can be used to check the accessibility of Web page colours for people who experience colour vision difficulties.

“Ensure that foreground and background colour combinations provide sufficient contrast when viewed by someone having colour deficits or when viewed on a black an white screen.[Priority 2 for images, Priority 3 for text]”

WCAG Checkpoint 2.2
Many people who are not normally considered “colour blind” can have difficulty reading text, including navigation menu items, when the difference in colour and contrast between the text and the background is not sufficient. Determining what is sufficient can be difficult although the W3C provides the formula to assist in this determination.

Alternatively, by entering the hexadecimal values for the foreground and background colours into The Juicy Studio Colour Contrast Analyser ( you can find out if you colour combinations are accessible without a lot of mathematical work.

References And Additional Information


Clark, Joe. 2003. “Building Accessible Websites” New Riders Publishing, Indiana.
Slatin, John and Rush, Sharon. 2003. “Maximum Accessibility”, Addison-Wesley, Boston.

World Wide Web Consortium. “Web Content Accessibility Guidelines 1.0.”
Thatcher, Jim. “Web Accessibility for Section 508”
Pilgrim, Mark. “Dive Into Accessibility”

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s