Basic Rules for Naming Files and Folders

  1. Always use lower-case letters a through z. Getting into this habit will save you from worrying about whether the URL contains MyFriends, MyFRIENDS, MyFrIeNdS, etc.
  2. Never use spaces in file names. Both Windows and Macintosh systems encourage us to use spaces in our file names. This is fine for Windows and Mac, but not fine for Web servers and Web browsers. The %20 that shows up in URLs like is your browser and a web server trying to compensate for the space. As you can see, the compensation makes the URL even harder to read.
  3. If you want the effect of a space, use the hyphen: - . It can be helpful, especially in longer file names, to have words separated visually. Use the hyphen to achieve this: Although one could use the underscore, too, (_), the underscore is usually impossible to detect in URLs that are underlined, as in a default hyperlink. Underscores can also cause problems in certain programming languages if it becomes necessary to refer to an external file. Play it safe, use the hyphen.
  4. Use numbers with a leading zero. Large, serialized collections of files can be named using numbers to distinguish them, e.g., photo-01, photo-02, photo-03. But use a leading zero (and perhaps a hyphen, too). This will help computers list the files in the order you intend. If you know you'll have less than 100 of something, start with 01 (01-99); if you know you'll have less than 1000 of something, start with 001 (001-999); and so on. On some systems, 2 (rather than 02) will be listed between 19 and 20 (...18, 19, 2, 20...28, 29, 3, 30...), which undercuts the value of serialization.
  5. In short, never use any characters besides a-z, 0-9, and the hyphenj when naming files and folders/directories. Again, this is a very conservative approach. But certain characters appearing in URLs, like the ? (question mark), & (ampersand), and = (equal sign), have very special meanings that have nothing to do with file names. Play it safe; it'll save you hours of frustration.


Session Summary

  1. Provide a context rich site map that gives an overview of the whole site
  2. For large sites provide section (or departmental) site maps
  3. Use headings to divide large site maps into categories
  4. For individual content pages provide the minimum of links before your content
  5. Enable users to jump over lists of links (provide a "skip to.." link)
  6. Navigation systems should be consistent across the site
  7. Links should change colour or style (but not size) when focused by either mouse or keyboard users
  8. There should be a "non-linking" gap between each adjacent link
  9. Pull-down menus need to be applied with great care and alternative methods of navigation must be available
  10. A "breadcrumb trail" helps visitors orientate themselves within the site structure
  11. Link text must be meaningful and in dependant of surrounding context
  12. Links to non-html documents must warn the user and indicate the download size of the document
  13. The title attribute is useful, but not universally accessible so must not be relied upon
  14. Images used as links must have meaningful alternative text tags
  15. Do not use javascript to activate links
  16. Try to limit the number of links on a content page



Most websites have many inter-linked pages and links to other people’s websites, not to mention links to non-html documents. It is easy for any visitor to get lost, and in particular for disabled people. This lesson covers the importance of a clear site map as part of your navigation system.

Site Map

For disabled people the site map is often the first page they look for on your website. A properly constructed site map provides a logical overview of your site that enables the user to understand what the site is trying to do as well as providing direct links to all the information. It is much more useful than even the best search facility (see search options below). A good site map provides a reliable and secure starting point for anyone who has problems navigating your site. It is the one place they can return to in order to get an overview of the site and some indication of where they have already been (links to visited pages should have changed colour or style).

Wherever possible site maps for large web sites should be organised conceptually rather than alphabetically. Many of your visitors will not have the same vocabulary as you, so a large A to Z index is not really much help. For example, suppose I want to find out what day my dustbins are emptied by the local council. Do I look under "D" for dustbins, "E" for environmental Services, "R" for refuse collection, or "W" for waste management etc.? Unless you put the appropriate link under all these alphabetic headings some visitors will struggle to find the information they need. Much better to first catagorise your services under general, informative headings such as "Environmental services - parks, allotments, street cleaning and waste management" and then list the relevant options.

If you are running a very large website, such as a local government site, you will have a number of different sections within your site. Each of these sections might require its own "site map" so that visitors can get just the most relevant links to their current area of interest. Each departmental site map should, of course, be accessible from a "top level" site map as well as from links on each page within the departmental section. The examples below show two common approaches to departmental site maps. On the left is a context rich index of sections that guide the visitor to areas of interest. On the right is a "Link-text" index consisting solely of links to pages within each section. Which type of approach is most suitable will depend upon your target audience and the complexity of your content. If most of your users are "first time visitors" then the context rich approach is best, even though it may involve an extra "click" to get to the required information. People who use the site frequently, and understand your terminology, will benefit most from the second example. However these are primarily "usability" issues. From an accessibility point of view both systems are effective providing that the text used for the actual link is relevant and meaningful.

Wandsworth community site map site map using single word links

It is important to ensure that each of the above site maps is constructed using the correct HTML heading codes. This means that a blind user can list the sections (Bereavement Services, Benefits, Children and Young people, Community Information etcetera) and jump straight to the section of interest. Without proper headings a blind user has to listen to the whole index to be certain of finding the information they require, this can take a long time.

Something to avoid

An interesting alternative to a listed catalogue of pages is a diagramatic concept "imagemap" as shown below. For a visual user with good mouse control this might be useful, but blind users and people who need to use the keyboard for navigation will find this type of site map almost impossible to understand or access. If you do use this idea then you MUST provide an alternative text based version that everyone can use.

concept diagramatic site map


Two or three click to any content

The idea that all your content should be available within 2 or 3 click from any page is a useful guide, but it should not get in the way of presenting logical routes to information, nor should it encourage you to create overly complex pages. The key to a usable (and accessible) navigation system is to make it logical and intuitive in structure. However, by providing a detailed site map with a link to it at the top of every page on your site does mean that you have provided a system that allows anyone to find the information they need within two or three clicks without cluttering up content pages with multiple links.

Content Management generated site maps

If you use a content management system (CMS) that generates a site map for you automatically you must check that the output makes sense to your visitors. Most CMS generates the site map text by copying the individual page <title> text, so make sure that page titles really do reflect the content of the page.


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.


Navigation Menu Bars

Most pages on your website have to serve two purposes; (1) Deliver actual content and (2) Present links to more content. Getting the balance right between these two tasks for any particular page requires careful thought. Content pages are primarily about imparting information or performing a task such as completing a form. On these content pages therefore, any navigation system becomes a hurdle that a visitor has to get over in order to obtain the content or perform the action.

Page structure

On most content pages you will want to offer your users two groups of links.

  1. For casual users, or those who have arrived at this page from a search engine, you will want to offer a top level (site-wide) navigation system so that they are encouraged to explore the site if this page is not exactly what they want.
  2. For people who are interested in the content of this page you want to offer links to similar, related, material once they have read the current content.

The usual practice is to provide a navigation bar across the top of the page to direct the user to the different main sections of the site. A further a sub-menu of links to pages relevant to the current section might be provided, usually down the left-hand side. We shall use this model for this lesson, but there is no golden rule about where you visually put your navigation bars on the screen – so long as they are consistent throughout the site. Remember that this positioning of elements should be done by CSS, always check that the underlying HTML sequence of navigation bars and content is efficient for assitive software and robots.

Skip links

It has become standard practice nowadays to start each page with a short series of site-wide links that include links to your home page, products/service, contact details, and your site map. This helps the casual visitor gain an overview of the site. However, to avoid frustrating visitors who are on their second or third page by constantly repeating this set of top-level links at the beginning of every page you can add a single link at the very beginning of a page that allows these users to skip the navigation bar and go straight to the content.

In practice this "skip links" option is very useful and should be used whenever you present a long list of navigation links. Keyboard users can get confused and frustrated if they have to keep on pressing the tab key to get through a series of navigation links that they know they do not want to use at the moment.


We shall use the following structure to explain how we reduce the navigation hurdles on a standard content page.

  1. Skip to content (link)
  2. Skip to secondary navigation menu (link)
  3. Top level navigation bar
  4. Page content
  5. Secondary navigation bar
  6. Anything else (e.g. advertisements)
  7. Footer navigation bar

Note that we have added a third navigation bar at the very bottom of the page (footer) so that visitors do not have to scroll back to the top of the page if they want to use any site naviagtion links.

Navigation bars

All navigation bars are lists of links. In our example the main site navigation is a horizontal list whilst the sub-menu is a vertical list. It is important that these lists are coded as lists in HTML so that assitive technologies, such as screen readers, can identify them properly in order to present them to the user. Lists of links also display correctly in text-only browsers. Each list of links must start with a heading that explains the purpose of the list (again this helps assistive software). This heading can be hidden from visual users by the style sheet. Blind users will be able to hear the heading read out aloud before they hear the links, thus they are able to set the links in context.

Horizontal navigation bars

Horizontal navigation bars use a list where the list <li> element is formatted in CSS to display "inline". There are a couple of additional formatting requirements in order to make horizontal navigation bars accessible.

  1. We need to make sure that there is a space between each of the links as they are displayed across the screen. This "non-linking" space marks the boundary between one link and the next. Thus, as the user passes the mouse cursor over each link it changes from a "hand" pointer to an "I beam" or "arrow" pointer in the space between the links. This change of cursor shape provides a good visual clue to the user and helps distinguish one link from the next.
  2. Keyboard users do not have a mouse cursor available, so they need to see a change to the actual look of the link when they tab to a link. This is done by defining a different colour for the link text when the text is "active" (using the pseudoclasses a:active and a:focus). We can change the background colour instead if we want, but we must not change the size or shape of the link. Changing dimensions whilst the user is on a page can make the whole page layout jump about as shown in the previous session.

In the following example we have defined a horizontal navigation bar using CSS

Sample CSS code

.topnav li {
display: inline;
list-style-type: none;
overflow: visible;

.topnav a {
font-family: Arial, Helvetica, sans-serif;
font-size: 1.1em;
font-weight: bold;
text-decoration: none;
color: #000099;
background-color: #FFFFFF;
padding-right: 1.5em;
padding-left: 1.5em;

.topnav a:hover {
color: #FFFFFF;
background-color: #000066;

.topnav a:active {
color: #FFFFFF;
background-color: #000066;

Example of a well spaced out main navigation menu

The simple navigation bar shown above has been formatted in CSS so that there is a gap between each link and the colours of the text and background change when selected. Many other formatting options are available, for example a right and left borders could provide a vertical line between each link as shown on the footer menu below. You can easily use images for the background to create a "button" effect using CSS, but do make sure that the text of the link is always presented as text in HTML.

Another useful option is to supply a different background colour or image for the currently active section. For example, whilst within the "Our Products" section of the website the background colour of the top "Our Products" link might be grey. This would remind visitors where they are within the overall structure of the site. These visual effects do not benefit blind users but they do help visual users.


Example of a footer submenu with vertical bars between each link

Here we have defined the the list element in CSS to have a left and right border

#footer li { display: inline; border-right-width: 1px; border-left-width: 1px;
border-right-style: solid; border-left-style: solid; border-right-color: #FFFFFF;
border-left-color: #FFFFFF; }

Vertical menu bars

The default option for the list element is to present a vertical list of the items, as a result there is a line space between each link so extra spaces are not normally required. Keyboard users still need to see a change in the link as they move through the list. Don't forget to include a heading for the list so that blind users can identify the overall purpose of the list menu. If you want to have an icon, such as a pointing finger, at the left of each link you should set this in CSS as the bullet image for the list item so that it is ignored by screen readers.

Using the title attribute

A useful addition for the anchor element is the title attribute. This attribute works in a similar way to the alt attribute of the <img> element in that the value (text) should be displayed as a user focuses on the element. Most, but not all, screen readers can also be set to read out the title attribute as the software reads out the link text. If you have short link text on your navigation bar and want to be a bit more specific you can use the title attribute to expand upon the link text. By way of a demonstration we have used the following code for the "Our Products" navigation link of the top level menu in the example above .


<a href="/products.htm" title="More information about our extensive range of cameras for professional photographers"> Our Products </a>

This is not a "universal fix" but it can be helpful for some users as it will be read out by mosts screanreaders and will also display when the mouse cursor hovers over the navigation button. However, you should use this fix with care. Not all users will be able to benefit from the title attribute. Furthermore it can be annoying to blind users if it is not really necessary


As mentioned in the previous session, CSS provides a set of “Pseudo-classes” for the link attribute (a href) that can react to the user focus (mouse or keyboard selection). These are

  1. a:link standard link
  2. a:visited listed in the browser history
  3. a:hover on mouse over
  4. a:active selected by the tab key (Internet Explorer)
  5. a:focus - selected by the tab key (Firefox)

These classes must be declared in the CSS in the order given above. It is best to define the hover, active and focus classes seperately (in the same style) because some browsers do not work well with combined pseudoclasses. Technically you can use a comma delimeted list such as a:hover, a:active, a:focus {definition} ). But experience has shown this is not 100% reliable.

Using CSS to create roll-over buttons is preferable to using javascript as CSS is universal. Each of the a:hover, a:active and a:focus classes need to be set so that both mouse and keyboard users can see the roll-over effect. For keyboard users this is a great benefit as otherwise it is not always clear where their current focus is (mouse users can see the cursor arrow to check where they are).

NOTE 1 – whenever we specify a font colour in a style sheet we should specify a background colour as well. This prevents us accidentally publishing white text on a white background!

Note 2 - whenever you use a mouse or keyboard action to change the look of an element such as a button you must not change the size. If the size of an element changes whilst the page is loaded the page layout tends to jump about and cause confusion to people using assistive software.


Pull-down (and “pop-across”) menus are useful for sighted users who have good mouse control, but for everyone else they can be a real problem. They are particularly problematic for people with weak eyesight, limited motor skills, or users of some assistive software. The purpose of any pull-down menu is to give the user an extended range of links. You should ask yourself why you need to provide so many links on a page designed to deliver content.

However, for large complex sites, a well designed set of pull-down menus can benefit users who have reasonable mouse control. For example the John Lewis website uses a navigation system on every page that presents links to each major department in the top level navigation bar. Mouse users are then presented with a "pull-down" submenu that groups together the various sections of that department. This means that however you arrive at the site you have immediate access to all the main shopping areas. Keyboard users do not see these pull-down menus, however as soon as they select one of the main departmental links they are taken to the department's "home page" where the drop down menu is duplicated as a standard vertical list in the left-hand column. This means that keyboard users may have to perform one extra click to get to the same content as a mouse users. However this extra click should not be considered a barrier to accessibility as the alternative would be to present the pull-down menus to keyboard users and require them to click through all the departmental sub-menus until they arrived at the last departmental sub-menu.

Note: Whilst the John Lewis pull-down menu concept is useful, the method of coding in HTML causes real problems to users of screen readers, text-only browsers and mobile devices because all the menus and submenus are coded in HTML before any content. As a result every page starts with 207 links! This is a clssic case of poor HTML structure. Preferably these submenus should be written after the content and CSS used to position them at the top of the page. Alternatively it might have been better to use javascript to deliver the pull-down menus (screen readers etc. ignore javascript so these users would have the same level and method of accessibility as keyboard users).


A website is a multi-dimensional resource presented in a two dimensional medium (the screen). It is easy for users to become confused about where they are and how they got to any particular point in the site. To help the user orientate himself within the web site it is helpful to provide a series of links at the top of the page that presents a logical path from the Home Page to the current page. This is called a bread-crumb trail.

For example a breadcrumb trail that said "Home Page -> Sports & Leisure -> Indoor Games" tells the user that they are in the Indoor Games section and can easiliy go back to the main Sports & Leisure main page for outdoor games etc.

Using visual positions for instruction

Please remeber that blind users do not see the whole page, they work up and down the text as presented in the HTML document. For this reason it is important that you do not rely upon positions (where something is on the page) for navigation. Instructions such as "Use the left hand menu bar" cannot be followed by screen readers, braille pads or text-only browsers.