The ability to jump from one page to another using the anchor <a> element is what makes the web so flexible and powerful. Unfortunately it also has the potential to make the web very confusing if users become disorientated and lost amongst the millions (billions) of web pages accessible on the internet. This series of sessions looks at how we can provide links to other documents on the web in an accessible, meaningful and logical manner.


The anchor element

In its' simplest form the opening anchor element includes the hyperlink reference (href) attribute that points to another resource on the web. This is followed by some text that tells the user what that resource is called and the element is closed with the </a> tag as shown below.

<a href=””>Go somewhere</a>

The above code would produce the following screen output - Go somewhere .

By default all browsers style the anchor element as blue underlined text as shown above. This is helpful, because even the newest web user is able to recognize a link and be aware that something will happen if it is selected. This blue underlined style is fully accessible to all sighted users because people who are colour blind, or using a momochrome monitor can see that the underline distinguishes the link from the surrounding text.

Browsers also keep a record of the pages a user visits and change the colour of a link to purple when a page has been visited. This is a great help to users as it reminds them of where they have been and helps them avoid going round in circles. Because these default style settings are understood by everyone who uses the web they should not be changed without a very good reason. The exception to that recommendation is when the link is used as part of a navigation bar. This is discussed in session 2 of this lesson when we look at menu bars.


The key to an intuitive and accessible navigation system is the actual text used for the link (referred to as "link text"). If this text is relevant to the action that will be taken when selected then the user will be prepared for the result. On a properly constructed web site the link text will normally reflect the title of the page being linked to. Link text that says “Details of our environmental policy” is clear and unambiguous, the user expects to be taken to a page detailing the environmental policy. A link text that says "click here for more info" could mean anything. It is worth pointing out that the words "click here" are pointless if the style settings have been left at the default blue underlined text. Everyone knows that blue underlined text is a link that should be "clicked".

Screen readers, assistive software and search engine robots are able to catalogue the links on a page (usually only up to 50 links) and present them as a single list. Blind people find this a useful way to gain an overview of links if the main content is not what they are looking for. They can tab down the list, hear the link text and select one of interest by pressing the Enter key. For this reason it is vital that the text used for the link is meaningful by itself (i.e. out of context within the page). The use of phrases such as "Click here..", "more" or "go now" are just not accessible to blind users. Blind people have to ignore all links that use ambiguous text like this becasue they have no idea what will happen. If the link opens a new window such as a video presentation it could freeze up their screen reader forcing them to reboot their system and start all over again.

In addition to being accessible and helping disabled users, context rich link text helps search engines to catalogue your site. The algorithms used by these engines add weight to a page that reflects the content of the relevant link. The safest way of writing link text is to use the <title> or <h1> of the page being linked to as a starting point. If this is too long then compose a suitable summary, but always keep it relevant to the content or purpose of the target page. So accessible link text helps everyone, users get a better experience and you get a higher ranking in search engines.


Links to non-html files, such as PDF or MSWord files should really tell the user what format these documents are and, if it is a large file, how big it is. For example the following link tells the user what the document is about, what format and how big. Thus the user can make an informed decision as to whether to click on the link and wait for the download or to leave it alone.,

Read the full report on bee-keeping (PDF 1.2MB)

Failure to provide this information in the link text may encourage a user to select the link even if s/he does not have the appropriate application to read the document available, or has a slow connection. Although links to non-html documents that do not include the document format are technicaly accessible they cause real problems to blind users as their screen reader attempts to load the whole document into cache, this takes a long time and the user might think that their computer has frozen.

If you provide a set of links to non-html documents it is normal good practice to include a warning statement on the page such as "The following documents are in PDF format" plus a link to the free downloadable Adobe Acrobat reader (or MS Word reader etc.). However it is also important that the document type and size are included in the link text because, as explained earlier, blind users can hear a list of the links on the page without reading the whole page. Blind users may therefore not be aware that there is a sentence somewhere on the page saying “the following links are to PDF files”.


If the link is to a multimedia file such as a video this information needs to be included within the link text so that blind users can avoid it, and, hopefully, read on to find a link to the text transcript of the video. This is particularly important if the video is set to display as a pop-up window. Pop-up windows change the user focus and start a new history path. To get back to the original page (which is now lying underneath the current window) the user has to close this new window. This is very confusing for blind users because the history trail is broken (the new window starts a new history trail). It can also be awkward for people with limited dexterity (especially the elderly) as the process of closing the new window can sometimes cause the originating window to close as well.

Adding styles to link text in an accessible manner

With the introduction of CSS it became possible to re-define the look of hyperlinks and even to add a new styles that helped the user to know which link was being selected (focused) by the mouse or keyboard (often called a "roll-over" effect). These link styles need to be declared in a specific order within the style sheet to work correctly.

  1. a:link - sets the style for an unvisited link
  2. a:visited - sets the style for a visited link
  3. a:hover - sets the style when a user hovers the mouse cursor over the link
  4. a:active - sets the style when a keyboard user tabs to the link (Internet Explorer)
  5. a:focus - sets the style when a keyboard user tabs to the link (Netscape/Firefox)

In practice the a:hover, a:active and a:focus styles should all be the same whilst the a:link and a:visited should each be a unique style (preferably these two should be left at the default settings). Also take great care to keep the same dimensions for all the styles. If the hover style is larger or smaller than the link style the whole page can jump about as the user moves between the links. By way of example the following link has been set to change dimension when it is focused - funny link size - so that when you hover the mouse over the link, or select it using the keyboard, it changes colour, but also size. Try it now and see how this sentence and any following lines jump about. This can be disorientating for many people, particularly those using screen magnifying software.

Using images as links

Images are sometimes used instead of text as hyperlinks. This can cause serious accessibility problems for disabled users. Blind people cannot see the image and people with weak eyesight cannot enlarge the image. Go to our help sectionA suitable alternative text tag will alleviate some of these problems. The alternative text must say what will happen if the image is selected (not describe the image). The alternative text tag for the image opposite needs to say what will happen – such as “help in completing this form” not what the image looks like (question mark).

It is nearly always possible to separate the background of the image from the text that the image contains. This allows you to load the background image with CSS and the foreground text with HTML and was explained in an earlier session. For example if you wanted to use a simple lozenge shape as the background image you would establish a class in CSS that defined the following

.lozenge a:link { background-image: url(images/lozenge.jpg);
font-family: Arial, Helvetica, sans-serif;
font-size: x-large;
background-repeat: no-repeat;
position: absolute;
width: 8.5em;
height: 1.8em;
text-align: center;
text-decoration: none; }

In HTML you would code the link as

<span class="lozenge><a href=”index.html” title="go to home page">Home</a></span>

The result is shown below. Blind users and those with images turned off will still see the link text ("Home"). If they need a larger font size that works as well. By seperating the background image from the link text we can deliver a fully accessible link without losing the interesting style.


This is a very simple design, we shall look at more complex designs in the next session when we look at navigation bars.

Title attribute

The title attribute can be used to help explain the purpose of a link. Most browsers present the title attribute in the same way that they present the alt attribute for images. When the mouse cursor hovers over the link text the value (text content) of the attribute appears on the screen. Remember that it cannot be relied upon as a universal accessibility fix, you still need to make the link text reasonably intelligible, but it can be used to expand upon the link text to help some users make a better informed decision before following a link. We have added a title to the lozenge button above. Please do not use this accessibility fix too often, it can get really annoying to blind users if every link has this extra title attribute, especially when it is not necessary.


The purpose of most pages on a web site is to impart a message (deliver content). Providing loads of irrelevant links just confuses users and takes up bandwidth. Ideally the number of links on a page would be limited to a link to the site map and a series of links to the most relevant pages for the topic being delivered. The place for long lists of links is the Site Map (to be discussed in session 3). Screen readers such as Jaws have an initial limit of 50 links for a page. If the user wants to hear more links they have to specifically ask Jaws to provide the next set of 50 links. This is quite time consuming.

There is a school of thought that believes every page of a site should be accessible within two links (jumps) from any other page. The way to achieve this is to have a good site map linked to on every page, not clutter up each individual page with numerous irrelevant links.

Things to avoid

There are three common techniques that many webdesigners use thinking that they are improving accessibility when in fact they are often making the situation worse. These are the accesskey and tabindex attributes and javascript.


The accesskey attribute can be added to the anchor link. This allows the webdesigner to allocate "shortcut" keys to important links. This sounds like a very good idea, by allocating (for example) accesskey "1" to the home page link a user can just press the Ctrl key plus the number "1" on the keyboard and be immediately taken to the Home page link. Unfortunately the idea has three critical flaws. Firstly there was no agreement as to what key should be used for particular links, so every site had different sets of numbers for links. Secondly the action could conflict with existing short cut keys (Ctrl + P would send the current page to the printer instead of finding the accesskey with a value of "p"). Thirdly it caused real problems for blind people because their software already allocates most of the keyboard for navigation so any additional instructions could produce unpredicatable results. Thus the accesskey attribute has been abandoned.


The tabindex attribute can be added to the anchor element to control the sequence in which a keyboard user can focus on the links within the page. This attribute takes control away from the user and should only be used in very special circumstances such as a game that uses an image map. If the page is structured correctly there should be no need to use this attribute as it has no effect for mouse users and can cause confusion for keyboard users with limited vision who may not realize that the focus has moved out of their view when they press the tab key.


Many assistive software tools have real problems with java enabled web sites and links that use Javascript just do not work. It is possible to add a <noscript> alternative but this is just making the whole thing even more complicated. If you are forced to use java for navigation (and you really shouldn’t) then make sure that there is also an HTML version of the link available somewhere else on the page. Otherwise some people will not be able to navigate around your site.

Guidelines relevant to this session

2.4.4 The purpose of each link can be determined from the link text alone.