Navigation around a web page can be achieved in a number of ways. Text, graphic buttons, imagemaps and keyboard shortcuts can all be used in any number of combinations.
Each of these tools may be implemented within a website as long as measures are put in place to ensure that every user can gain access to every page.
Use each checklist to ensure that your web pages comply with these guidelines
6.6.1 Checklist and summary: Core guidance
Not all users choose to view websites using graphics, and many are unable, because of impaired vision, to use images at all. These users may be using small-screen browsers that only display text, or may be visually impaired users using access technology.
It is for this reason that text is the simplest and most powerful tool available to construct a navigational aid for users.
To ensure that the most important element of the page is loaded first and is accessible to all, it is imperative that all UK public sector websites offer text navigation, containing each of the important links, at the very top of each page.
The text elements within this top navigation bar should be separated by spare + vertical bar (|) character + space which is not part of the link. This avoids the problem with the access technology reading all the links as one.
This text navigation should also use the hotkey capabilities referred to in the WAI guidelines (see section 2.4). This allows authors to assign keyboard actions to hyperlinks. As well as being a useful tool for getting around a website, its primary role is to aid users with motor disabilities who find controlling a pointing device difficult.
Go to section 2.4 Building in universal accessibility
This keyboard access is part of the HTML 4 recommendation for all browsers, although this facility can only be used by the Microsoft Internet Explorer browser at present.
It is essential that once the order of the text navigation is decided on, it is adhered to throughout each page on the website. This allows users to quickly become accustomed to your website structure.
The text elements of the top navigation bar are best formatted using a CSS, ensuring that the text is legible against the background colour and easily displayed by browsers that are unable to interpret CSS.
A sighted person will scan a page and ignore repeating items. A user with a visual impairment cannot do this and they have to tab through each link every time. To assist these users, the first link on the top text navigation bar should offer a jump to bypass the repeating elements. This link should be an internal link to the beginning of the document text itself.
This example illustrates how each of the earlier points is implemented.
<a accesskey="S" href="#skip">Skip Navigation bar</a> |
<a accesskey="1" href="index.htm">Homev/a> |
<a accesskey="2" href="whatsnew.htm">What's New</a> |
<a accesskey="3" href="sitemap.htm">Sitemap</a> |
<a accesskey="C" href="contact.htm">Contact</a> |
<a accesskey="4" href="search.htm">Search>/a> |
<a accesskey="6" href="help.htm">Help</a>
<a name="skip"><h1>Document Title</h1></a>
The resulting web page would be displayed as follows:
When inserting a hyperlink it is sometimes advisable to enter some information for users that is not included within the link text or graphic using the ‘title’ attribute. This is illustrated by the following example:
<p>This page is also available in the following formats <a href="html-doc.htm" title="56kB">[html]</a> <a href="pdf_doc.pdf" title="120kB">[pdf]</a> <a href="rtf-doc.rtf" title="61kB">[rtf]</a></p>
In this example, the ‘title’ information is the size of the file to load (HTML file is 56kB, PDF file is 120kB). This information will display in a visual browser when the pointer hovers over the link, while a speech browser will automatically read it.
The ‘title’ attribute can be an excellent tool to help the user but it is important not to make the caption too long-winded. Too long a message, however helpful, will only cause irritation to a visually impaired viewer who will have to listen to it whether they want to or not!
6.6.2 Graphic navigation: Core guidance - if used in website
Navigation to pages can be achieved by using pictorial buttons saved in either GIF or JPEG format.
It should be remembered that PNG format is not yet widely supported by web browsers.
The effect of graphic buttons can be appealing when designing a web page but can be an annoying hindrance to users if implemented inappropriately.
Any page on a website can benefit from appropriately used graphics. They can be used to illustrate a point, label a document as a department’s property or give a more visually rich navigation environment.
When navigation of the website uses graphical buttons the site must always be as easy to use when these graphics cannot be viewed. There must always be a descriptive value to the ‘alt’ attribute given to every navigationally important graphic.
Turn off the automatic graphics download in your browser to give an indication of what your page is like when you cannot see the graphic buttons. Is it still easily usable?
When graphic buttons are used, specific values to both the ‘width’ and ‘height’ attributes within the image tag must be set. This helps the browser to render the page on screen with the minimum number of screen redraws.
It is important that graphic navigation buttons are not too large, so that the largest area possible is given over to displaying the document whilst also ensuring that the graphic file sizes are as small as possible.
When graphic buttons are relatively small on screen and a small text font is used, it is important that this text is large enough to be legible for everyone and not anti-aliased (see section 2.8.10).
Go to section 2.8 Web graphics
An example of the correct implementation of a group of graphic buttons is shown below:
<a accesskey="1" href="index.htm"><img src="http://webarchive.nationalarchives.gov.uk/20100807034701/http://archive.cabinetoffice.gov.uk/e-government/resources/handbook/html/images/button1.gif" width="80" height="20" border="0" alt="Return to Homepage"></a><br>
<a accesskey="2" href="whatsnew.htm"><img src="http://webarchive.nationalarchives.gov.uk/20100807034701/http://archive.cabinetoffice.gov.uk/e-government/resources/handbook/html/images/button2.gif" width="80" height="20" border="0" alt="What's New"></a><br>
<a accesskey="3" href="sitemap.htm"><img src="http://webarchive.nationalarchives.gov.uk/20100807034701/http://archive.cabinetoffice.gov.uk/e-government/resources/handbook/html/images/button3.gif" width="80" height="20" border="0" alt="Sitemap"></a><br>
<a accesskey="C" href="contact.htm"><img src="http://webarchive.nationalarchives.gov.uk/20100807034701/http://archive.cabinetoffice.gov.uk/e-government/resources/handbook/html/images/button4.gif" width="80" height="20" border="0" alt="Contact Details"></a><br>
<a accesskey="4" href="search.htm"><img src="http://webarchive.nationalarchives.gov.uk/20100807034701/http://archive.cabinetoffice.gov.uk/e-government/resources/handbook/html/images/button5.gif" width="80" height="20" border="0" alt="Search"></a><br>
<a accesskey="6" href="help.htm"><img src="http://webarchive.nationalarchives.gov.uk/20100807034701/http://archive.cabinetoffice.gov.uk/e-government/resources/handbook/html/images/button6.gif" width="80" height="20" border="0" alt="Help"></a><br>
Each of the buttons is 80 pixels wide and 20 pixels in height. The tag is there to ensure that each button starts on a new line and is directly below the previous button.
Note that each of the graphic buttons uses the same ‘accesskey’ letter identifiers as the earlier top text navigation bar. This is essential to avoid confusion within the browser itself and to allow users to acclimatise to a standard set of navigational aids within the website.
See section 2.4.4 UK Government accesskeys standard.
Go to section 2.4 Building in universal accessibility
6.6.3 Imagemaps: Core guidance - if used in website
Navigation to pages can be achieved by using one large graphic.
Areas within this graphic can then be designated as live by using the ‘map’ tag and x and y co-ordinates.
These imagemaps can be appealing on a web page but are next to useless if the user is visually impaired. This does not mean they shouldn’t be used, it just means alternatives should be offered.
However visually appealing this method of navigation may look; it should only be used sparingly in the website.
There are basically two forms of imagemap, both of which have names that describe how they work, server-side and client-side. The client-side imagemap is the more flexible and therefore the version that must be used.
Server-side imagemaps are the older variety that will only work if the browser is connected to the Internet at the time the hot spot is selected. Each click on the image will result in a transaction between the user’s browser and the content provider’s website. This is relatively inflexible and has been overtaken by client-side imagemaps.
These were developed by Netscape in 1996 and do not require any interaction between the page and the originator’s website once the page has been loaded to the user’s browser. They can be used offline because all of the co-ordinates are contained within the HTML page.
HTML authors should be aware that some early browsers do not support client-side imagemaps and may wish to include server-side imagemaps as well to cater for them. Browsers that can use client-side imagemaps will use them in preference to server-side ones if both are provided.
When an imagemap is used, a text alternative should be supplied alongside the graphic in question. This text must be formatted using Cascading Style Sheets and must be clearly legible against the page’s background colour.
It is essential that each designated area within the client-side imagemap be given an ‘alt’ attribute with a value that describes the link. This is useful to all users. There is an accessibility requirement to provide a text alternative.
An example of a correct implementation of a client-side imagemap is as follows:
<img src="http://webarchive.nationalarchives.gov.uk/20100807034701/http://archive.cabinetoffice.gov.uk/e-government/resources/handbook/html/images/landsend.jpg" width="301" height="260" border="0" alt="Lands End Signpost" usemap="#route_map">
<a href="landsend.htm">Landsend |</a>
<a href="newyork.htm">New York |</a>
<a href="johnogroats.htm">John 'O' Groats |</a>
<a href="scillyisles.htm">Scilly Isles |</a>
<area shape="rect" coords="39,73,138,93" href="newyork.htm" alt="New York">
<area shape="rect" coords="171,72,283,96" href="johnogroats.htm" alt="John O Groats">
<area shape="circle" coords="149,39,38" href="landsend.htm" alt="Lands End">
<area shape="poly" coords="141,116,9,105,14,128,141,139,141,116" href="scillyisles.htm" alt="Scilly Isles">
In this example there is the image object, called ‘landsend.jpg’, followed by the text alternative version which is formatted using the ‘class=”imagenav”’ from the Cascading Style Sheet.
The client-side ‘map’ that follows contains the co-ordinates, link attributes and values that makes the imagemap work.
6.6.4 Alphabars: Core guidance
This method of navigation is designed to allow the efficient location of a part of a very complex or large document or list.
If an organisation’s website is to contain a lengthy list of links or other information, it makes no sense to try and fit it all in to one document and let the user try find the information they want by scrolling up and down an enormous page. This process would be very annoying for many users and almost impossible for people without the use of a pointing device.
The best way of navigating around this sort of information is to offer the user a quick navigational jumping point to the letter or section of interest.
An example of an alphabar for an online Glossary document is shown below.
This example uses capital letters. Although these are generally seen as being more difficult to read, they do offer a larger footprint on the page than lowercase letters. The larger the footprint, the easier it is for the user to locate the hypertext link with their pointing device.
The letter or number codes used in the list may be internal links within the document; alternatively they could link to internal reference points within other documents.
It is always advisable to have a link back to the top of the document at the end of each section to avoid having the user scroll back to the top to use the alphabar again.
Illustrated below is an example of a correct implementation of an alphabar, it has been slightly truncated for display purposes.
<table border="0" cellpadding="2" cellspacing="2">
<td class="whitetext" width="60">Letter</td>
Each of the letters is an internal hyperlink to a section within the document.
Go to section 2.4 Building in universal accessibility