APPENDIX SIX: ACCESSIBILITY AUDIT REPORT Conventions Used within the Report Summary of key issues Main Findings Appendices Accessibility Pages Properly Labelling Graphics Specialist Access Methods Accessibility Glossary

APPENDIX SIX: ACCESSIBILITY AUDIT REPORT

Introduction

This report contains the findings of an accessibility audit conducted by AbilityNet on behalf of Ipsos MORI and Transport Scotland, evaluating the accessibility of the Transport Scotland website (www.transportscotland.gov.uk) against W3C Web Content Accessibility Guidelines 1.0 standards. The website was reviewed between 24 and 28 July 2008.

This document reports the findings of the accessibility audit, which is one element of a wider review of the Transport Scotland website undertaken by Ipsos MORI. The full research programme consists of:

An online survey hosted on the Transport Scotland website gathering visitor feedback
Interviews and usability testing among stakeholders of Transport Scotland, including MSPs, journalists, Local Authority representatives, those employed in the transport sector and members of the General Public
Usability testing among eight disabled users

Overview

Of the 20 pages audited to AA compliancy status
11 are single-A compliant, and 0 are AA compliant.

The pages tested were: (Because the URL remained static when browsing the site, only the page titles have been given.)

1. http://www.transportscotland.gov.uk/

2. http://www.transportscotland.gov.uk/road/development-near-trunk-roads/major-planning-applications

3. http://www.transportscotland.gov.uk/road/traffic-count/map-application

4. http://www.transportscotland.gov.uk/concessionarytravel

5. http://www.transportscotland.gov.uk/concessionary-travel/who-qualifies

6. http://www.transportscotland.gov.uk/projects

7. http://www.transportscotland.gov.uk/projects/m74-completion

8. http://www.transportscotland.gov.uk/projects/m74-completion/the-project/fly-through

9. http://www.transportscotland.gov.uk/projects/m74-completion/the-project/timeline

10. http://www.transportscotland.gov.uk/rail

11. http://www.transportscotland.gov.uk/rail/service-quality-incentive-regime

12. http://www.transportscotland.gov.uk/rail/service-quality-incentive-regime/results-for-your-line

13. http://www.transportscotland.gov.uk/reports

14. http://www.transportscotland.gov.uk/reports/consultation-papers-and-responses

15. http://www.transportscotland.gov.uk/reports/consultation-papers-and-responses/j9651-00

16. http://www.transportscotland.gov.uk/news

17. http://www.transportscotland.gov.uk/stag/td

18. http://register.transportscotland.gov.uk/

19. http://www.transportscotland.gov.uk/sitemap

20. http://www.transportscotland.gov.uk/accessibility

Specific W3C Web Content Accessibility Guidelines 1.0 checkpoints are given as reference in the text of this report. The complete list is available online at: http://www.w3.org/TR/WCAG10/full-checklist.html

The ‘Main Findings’ section of this report details accessibility issues which were encountered during the audit together with suggested remedies.

At the end of this report there is a glossary of accessibility related terms. Whilst not all of them are relevant to this report, they have been included for reference.

Conventions Used within the Report

The following conventions are used within this report:

[ref: number]	This will be used to identify a particular W3C Web Content Accessibility Checkpoint.
[page number]	This will be used to identify a particular page reviewed when discussing issues and recommendations. The page number corresponds to the same number in the list in the Overview.
<code>	This will be used to show code snippets.
<code>	This will be used to show suggested changes to code to improve the accessibility of the website.

Summary of key issues

Priority 1 Accessibility

The audit found 5 priority 1 accessibility checkpoint errors that need to be addressed:

Images [ref: 1.1] - The use of alternative text (also known as ‘alt tags’) for pictures, text as graphics, decorative graphics, spacer gifs, form buttons and graphical links is fundamental to accessibility. This issue was encountered on pages [6, 7, 10, 11, 12, 17]
CSS [ref: 6.1] - Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document. This issue was encountered on one page [3]
Tables [ref: 5.1] - For data tables, identify row and column headers. This issue was encountered on page [9]
Frames [ref: 12.1] - It is important to title each frame, particularly for vision impaired users, so that users are aware of whereabouts on a page they are. This issue affected page [3]
Scripting (Client-side) [ref: 6.3] - A level 1 requirement is that pages work if JavaScript is disabled or not supported – its use impacts on around 5% of web users, those disabled people using adaptive technology, people who have high security settings (in which JavaScript is turned off) and PDA users. This issue was encountered on pages [2, 3, 6, 12, 17]

Priority 2 Accessibility

The audit found 8 priority 2 accessibility checkpoint errors that need to be addressed:

Images of Text [ref: 3.1] - On page [15] there are images of text used for different language examples. Some of these could be coded up as text with the appropriate language attribute.
Validation [ref: 3.2] - Ensure pages validate against html standards. This error was found on pages [3, 9, 11, 17, 18]
CSS [ref: 3.3] - The majority of the pages tested used table based layouts, which could instead be achieved by using CSS.
Headings [ref: 3.5] - Headings are useful for providing an overall document structure and dividing a document into logical sections. On the majority of pages tested, headings were implemented incorrectly.
Lists [ref: 3.6] - Mark up lists and list items properly. On all pages tested on the site, the main horizontal and left hand navigation bars could usefully be coded up as lists
New windows [ref: 3.5] - On several of the pages tested, there was a link that opened in a new window when clicked on by the user, without first warning the user that this would happen. This can be disorienting for some users as once content is opened in a new window, the back button no longer works and they may be unsure of how to return to the originating page
Links [ref: 13.1] - Clearly identify the target of each link. Found on pages [6, 20]
Applets & Scripts [ref: 6.4] - For scripts and applets, ensure that event handlers are input device-independent. Identified on page [4]

Main Findings

The following section contains a detailed breakdown of checkpoint failures together with recommended solutions. The recommendations provided will help ensure that the website is as accessible as possible to a wide variety of users.

Priority 1:

Images [ref: 1.1]

Why is it important? And who does it affect?

The use of alternative text (also known as ‘alt tags’) for pictures, text as graphics, decorative graphics, spacer gifs, form buttons and graphical links is fundamental to accessibility – it is responsible for around 30-40 percent of all problems affecting a range of disabled people accessing the web.

All graphics on a page need to be labelled correctly for a number of reasons. Blind users accessing the website via a screen reader will have only the information in the alt tag to gauge the importance of a particular image. In addition, missing alt text on graphical links and form buttons will impede the usability of the website for users accessing via voice recognition software. The usability of the website will also be significantly reduced for users with cognitive impairments or dyslexia as software packages that they use to assist them (e.g. Text Help’s Read and Write) will speak the content of the page including pictures and graphical links. Therefore, if no alternative text is provided, this would reduce the readability and thus their understanding of the content.

Issue: Images missing alt text or displaying inappropriate alt text

On pages [6, 7, 10, 11, 12, 17] the banner image alt text has the word "Banner" suffixed on, e.g. Projects Banner.

There is no need to add the "Banner" text onto the alt text, as this will not add any extra meaning to screenreader users.

Another example is on page 6. There is a small table of graphical links, some of which have alt text of ‘M74 Completion Logo’ ‘Aberdeen Western Peripheral Route Icon’. Again, there is no need to have the "Icon" or "Logo" suffix on this alt text.

Recommended solution

A good way of checking alt text is to view a page with images turned off (by unchecking the ‘Show pictures’ box under the Advanced tab in Internet Options in Internet Explorer) and make sure the page still makes sense. Displaying content in this way will show the alternative text for the images as end users would encounter it.

In the above cases, there is no need to add "Icon", "Logo" or "Banner" to the end of alt text. Screenreader users, who most often make use of alt text, will be automatically alerted to the fact that an item is an image when they hear the alt text being read out.

Generally, because of the relatively small amount of graphics on the site, there were no other issues to do with alt text.

CSS [ref: 6.1]

Why is it important? And who does it affect?

This affects users of older, or specialist browsers that may not support CSS, while other users, particularly those with a visual impairment, may specify their own preferred stylesheet within their browser settings, which then overrides styles specified by the website.

Issue: Interactive map on page 3 does not function with CSS disabled

With CSS disabled, the map is not displayed correctly in IE7. There was a note on the page about possible issues with IE7, but this issue only manifested itself when CSS was disabled.

Recommended solution

With CSS disabled the map keeps flickering, being displayed for a fraction of a second before disappearing.

The main issue is to resolve this flickering problem, which would require testing the site on a machine with CSS disabled to see how it is affected. If this is not possible, then an alternative, possibly text only version of the page, would be required.

Having a text only alternative would also get round of the problem of the map not functioning if JavaScript is disabled (mentioned below).

Tables [ref: 5.1]

Why is it important? And who does it affect?

Tables need to be marked up using row and column headings, with data in the cells associated directly with those headings, in order for screen readers to navigate them effectively. If the column headings are just marked up as regular table cells, then they will be read out as such. When column headings are marked up correctly, a screen reader can then reference each table cell to that particular header, reading it out before it reads out the data.

Issue: Table headers missing

On page [9] the Timeline table does not have the table headings present.

Recommended solution

Specify the table headers using <th scope="col">Column name</th> within the first table row, above the actual content table cells. The scope=col attribute specifies that the heading is a column, rather than a row, heading.

e.g.

<table>
<tr><th scope="col">Timeline activity</th><th scope="col">Completion date</th></tr>

Frames [ref: 12.1]

Why Is This Important \ Who Does This Affect?

Sites with Frames and iFrames cause barriers for adaptive technology users. In particular, navigating around a site is very difficult if frames are not titled clearly and accurately to their purpose and content because screen readers and text browsers such as Lynx view a webpage built with frames not as a complete page but as a list of frame links, so they have to navigate into each frame to view its contents.

Issue: Page is missing iframe titles

Page [3] uses an iFrame for the embedded map on the page, but does not provide a title for this frame.

Recommended solution

If frames must be used, use the title attribute to provide a meaningful title for each frame e.g.

<FRAME NAME="Content" SRC="main.html" TITLE="Interactive map">

Scripting (Client-side) [ref: 6.3]

Why is it important? And who does it affect?

A level 1 requirement is that pages work if JavaScript is disabled or not supported. Statistically, this impacts a significant minority of web users – around 5 percent would have issues with a site that used JavaScript because they have browsers that do not support it or have it disabled. This 5 percent is made up of people surfing the web behind secure firewalls that for security reasons have disabled JavaScript, PDA users and disabled people who use adaptive technology that has limited or no support for JavaScript.

Source: http://www.thecounter.com/stats/2004/May/javas.php

Issue: Some links are JavaScript dependant

On page 2 the Go button on the Planning Applications form does not function if JavaScript is disabled.

On page 3 the interactive map is reliant on JavaScript being enabled.

On page 6 the Go button on the Trunk Roads section does not work with JavaScript disabled.

On page 12 the form relies on JavaScript and is no longer usable with JavaScript disabled.

On page 17 the dropdown boxes all use the JavaScript onChange event handler to take users to a new page as soon as they choose a link. However, this feature no longer worked with JavaScript disabled.

Recommended solution

For pages 2, 6, 12 it was not obvious how JavaScript was tied to the particular form buttons, but with JavaScript disabled, the forms no longer functioned.

To pass this checkpoint, these pages will all need to function with JavaScript disabled.

On page 17 the drop down boxes all use the onChange event handler to activate links. Rather then using this method, a better solution would be have a separate Go button next to each drop down box, which a user can press once they have chosen their link. This would correct the problem for this page, and has the advantage of addressing the Priority 2 issue concerning JavaScript, namely, that the current method used is not accessible to keyboard only users.

An alternative to the map on page 3 might be a text only version, using a drop down list of locations rather than a series of links on a map. This would address both this issue and the issue described above about the map being unusable with CSS disabled.

For the map page, it may be wise to include some text for users who do not have JavaScript enabled. This can be done using the <noscript> tag e.g.

This will only be displayed to users who do not have JavaScript enabled.

Priority 2:

Images of Text [ref: 3.1]

Why is it important? And who does it affect?

The W3C guidelines state that when an appropriate mark-up language exists; it is best-practice to use mark-up rather than images to convey information. Using mark-up and Cascading Style Sheets (CSS) where possible rather than images promotes accessibility as it allows text to be magnified or interpreted as speech or Braille. The added benefit is that search engines can use text information.

Issue: Image of text used where mark-up and CSS could have been used

On page 15, there were examples of the alternative languages available: See Fig. 1 below

Fig. 1 – Images of text

The above example is entirely made up of images of text, but could be made more accessible by replacing portions with CSS styled text.

Recommended solution

Where possible, replace images of text with actual CSS styled text. From the above example, this will only be possible with a few of the languages. An example of this would be the Gaelic example above:

<span lang="gd">Gheibhear lethbhreacan....</span>

Note the language code ‘gd’. Using this language code ensures that any screenreader users hear the text pronounced as correctly as their screenreading software will allow.

Some information on adding accented characters can be found here: http://tlt.psu.edu/suggestions/international/bylanguage/gaelic.html#htmlcodes

For languages, such as Urdu, Punjabi, Traditional Chinese etc, where a text version cannot easily be provided using images of text is perfectly acceptable.

Validation [ref: 3.2]

Why is it important? And who does it affect?

Adaptive technology makes the assumption that web pages have been created using specific rules and that they validate against those standards - if this is not the case it can cause quirky or unpredictable behaviour in adaptive technology software.

Issue: HTML does not validate

Pages 3, 9, 11, 17, 18 all displayed some validation errors.

Recommended solution

Use the W3C HTML validator to check the code and fix any problems: http://validator.w3.org/

CSS [ref: 3.3]

Why is it important? And who does it affect

Style sheets should be used to control layout and presentation as this allows for graceful degradation of the page in older browsers and provides more flexibility for alternative viewing devices.

Issue: Tables are used for layout

On all pages tested, except 18, 19, 20, the layout was governed by tables. The same layout and presentational style could be achieved by using CSS to position elements and for presentational purposes.

An advantage of CSS is the ability to provide multiple layouts per page, so a particular page might have the standard layout used for most computer users, with separate layouts for handheld devices such as mobile phones or for PDAs, as well as a separate layout for when the content is printed.

Recommended solution

Replace table based layout with a CSS controlled design. For more information on CSS and its implementation, see http://www.w3schools.com/css

Headings [ref: 3.5]

Why is it important? And who does it affect?

Correctly structured headings enable users to gain a feel for the structure of the document, making content more readable. Screen reader users can listen to a list of headings to find out which section of the page interests them instead of listening to the entire content.

This issue affects all users but it specifically affects screen reader users and users with a cognitive disability.

Issue: Incorrect headings

Many of the pages had multiple H1 level headings.

See Fig 2 below – the homepage

Fig 2.Homepage with headings marked

Recommended solution

Each page should have a single level 1, <h1>, heading as a minimum. This heading should be the main title of the page where relevant. Following on from this, if pages are divided up into subsections, each section should be given its own headings. Those immediately below the top level heading should be given H2 level headings, further subsections within the H2 section should be given H3 level headings and so on.

A good rule is that the main, H1, heading on a page should replicate the text in the title bar for the page.

In the case of the homepage, in the example above, there are two H1 headings used – for the ‘Latest news’ and ‘Links’ headings on the right hand side of the page.

In the case of the homepage, the H1 heading should be the main heading on the page – "Transport Scotland". The ‘Latest News’ and ‘Links’ headings could then be usefully coded up as H2 level headings.

Lists [ref: 3.6]

Why is it important? And who does it affect?

Marking up lists and list items correctly gives them a good structure and makes them semantically correct.

Issue: Items not specified as lists

Although a minor issue, which was apparent when viewing pages with CSS disabled, some of the lists contain several blank list items. See fig 3 below

Fig. 3 – Blank list items at the end of a list

Coding lists up gives screenreader users more information about a page. Before a list item is read out, the user would be informed that there was a list of items and how many items were in the list. If a list is reporting that there are 11 items in a list, but 2 of those are blank then the user may be confused.

Recommended Solution

Remove any blank list items.

New Browser Window [ref: 10.1]

Issue: Window opens without warning the user.

On pages 1, 3, 4, 13, 14, 18 there were links that opened into a new window without first warning the user.

Examples include the ‘Traveline Scotland’ or ‘Traffic Scotland’ links on the homepage.

Recommended solution

Avoid specifying a new window as the target of the link with the target="_blank" or target="_new" attributes of links, unless users know that a new window will open.

If this attribute is used, either indicate in the link text or in the title attribute of the link that a new window will be opening.

e.g. rather than

use the alt attribute of the linked image to alert the user that the link will open in a new window:

<a href=" http://www.travelinescotland.com/"
target="_new">Traveline Scotland<a>

Links [ref: 13.1]

Why is it important? And who does it affect?

The destination of each link needs to be clearly identified. Screen reader users have the ability to list the links in a page and use this to navigate. If non-descriptive link text such as ‘click here’ is used, they have to either guess at the destination, or explore the page for contextual information. Additionally, if the same link text is used to link to different pages, this will also cause problems. Link text should be descriptive and unique.

If images are used as links, the screen reader will pick up the alt text as the destination of that link. If no alt text is provided, the screen reader will then read out the destination of the link – something that very often makes little or no sense at all.

Issue: link text not unique\readily identifiable

Page 6 has several graphical links, some of which have abbreviated alt text. E.G. FRC (Forth Replacement Crossing), however a screenreader user browsing a list of links on a page may just hear FRC, GARL etc. and be unaware of what these abbreviations meant.

Page 20 has a link titled ‘Download’, to allow users to download the Adobe Acrobat Reader. If read out of context, a user would not likely be aware what this link was relating to, however.

Recommended solution

For the issues on page 6, it would be better to expand the abbreviations used as the image alt text, so a vision impaired user would hear the whole text, rather than just the abbreviation. E.g.

For the issue on page 20, a more descriptive link phrase should be used, so rather than "download" use

<a href="adobeDownload">Free download of Adobe
Acrobat</a>

Applets & Scripts [ref: 6.4]

Why is it important? And who does it affect?

Users of older browsers, or assistive technology, that don’t support JavaScript.

Issue: Page contains mouse only event handlers

On page 17 there are a series of list boxes that all take the user to a new page automatically when they choose a link from the selection. This is achieved using the JavaScript onChange event handler.

This would cause a problem for any keyboard only users, who may be unable to use the mouse. If they tabbed around the webpage, and tried to scroll through the list of available options in the list boxes, the onChange event handler would automatically take them to a new page before they could properly browse the list.

Recommended solution

Use only device independent device handlers, or ensure that all devices are catered for. E.g. if the OnClick event handler is used, also use the OnKeypress event handler to cater for keyboard users.

In this case, the onChange event handler should not be used. Instead, remove the onChange event handler, and include a go button next to each list box. This allows a user to browse through the list of available options before selecting one. Once they have chosen, they can press the "Go" button as a separate action. This also ensures that the drop down lists are accessible to users who may not have JavaScript enabled.

Appendices

Accessibility Pages
Properly Labelling Graphics
Specialist Access Methods
Accessibility Glossary

Accessibility Pages

It is recommended that your homepage feature a very prominent link to a set of pages describing various ways in which a visitor can improve their access to your site. This link could be called something like "Accessibility and User Preferences". Offering such a service would be a public statement of your commitment to "inclusivity".

A visitor who has had their experience of your site facilitated as a result of being able to optimise the interface would also have their entire computer usage improved.

Such a set of pages could comprise all or a selection of the following:

Instructions on how to change the text size within the commonly used browsers (e.g. IE, Netscape and Opera). If you have specified absolute and not relative font sizes then these instructions would need to include how to override them
Instructions on how to change text and background colours within the commonly used browsers
Instructions on how to change the system theme/colour scheme within Windows
Instructions on how to set the screen resolution to 800x600 for easier viewing within Windows
Instructions on how to tune the response of the mouse (e.g. acceleration and double-click speed)
Instructions on how to tune the response of the keyboard (e.g. acceptance delay, key repeat rate and sticky keys)
Information on a core range of specialist software, and how it can improve access for those experiencing difficulties using your site. Links to demos could be included
A list of useful links to other sources of on-line information on disability and IT

Please note that AbilityNet has put together such a set of accessibility and user preferences pages that can be co-branded with your organisation and linked to from your home page. These pages can either be hosted on our servers or your own.

This service is offered free of charge. To see how the pages would appear and to review their content please visit www.abilitynet.org.uk/myweb

Site Help Section

In the general site help section of your site you may also want to include:

A general summary of the site structure and navigational scheme
A listing of the primary navigational links’ access keys (if you have implemented them)
An invitation to feed back any comments or questions specifically on accessibility and usability issues

Contact details for support/help with difficulties in using the site

Properly Labelling Graphics

The very first checkpoint in the W3C guidelines (1.1) states:

"Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video. [Priority 1]"

Often it is quite easy to decide what label to give a picture or graphic on your web page, but sometimes it is not. Below are some recommendations of best practice.

Pictures or Photographs

Pictures or photographs are quite straightforward. For example, the picture on your news page showing a recent launch of a new product should have an alt tag describing briefly what the picture is about. For example:

<img src="widget.jpg" alt="Widget Deluxe, a new product launched this month">

Because blind visitors relying on speech output are not able to scan through a page or be as selective of what they read as others can be, every opportunity should be taken to minimise what they have to listen to. Hence alt tags should be as concise as possible.

You do not need to include the words "Picture of…" in an alt tag. All visitors who are not actually able to see that there is a picture there are informed of the presence of graphics by their access technology or text browser. For example, a blind visitor using speech output (or screen-reading) software) may hear "Graphic - Widget Deluxe, a new product launched this month" and so are made aware that this is a picture.

Graphical Links and Imagemaps

Many web pages include graphics as links to other pages or parts of the page, or as image maps (graphics that have multiple "hot-spots" that link to multiple pages). Whilst the use of proper text for links is preferable (as it can reflect a user’s preferred size and colours) having appropriate alt tags on graphical links is vital. Without them, the link is as good as broken for the screen-reader or text browser user.

Missing or unhelpful alt tags on graphical links and imagemaps is the most common, and most serious, accessibility issue encountered on the internet. It is both an easy issue to remedy and the cause of great difficulty for some visitors to many websites on the internet.

Similarly to the case above, the alt tag to a link does not need to include the descriptive text "Link to…" as the user’s access technology will inform them that it is a link.

Graphs and Charts

Usually a picture that represents a graph or chart conveys a significant amount of information. In this case an alt tag would not be suitable.

The best known and most well-supported method of providing such information in a textual format that will be accessible to those using access technologies is to provide a "D" link.

A "D" link is simply a capital "D" placed at the bottom right corner of the image that is a link to a separate page that contains a full description of the contents of the image. The page should also contain a link back to the original page (preferably with a "#" reference to the exact part of the page where the image was located).

For example, on the page containing the chart:

<a name="#chart"><img src="chart.gif" alt="Chart showing the yearly figures of 2002"></a>
<a href="description" title="Description of the chart">D</a>

And the link on description back to the original page:

<a href="originalpage/#chart" title="Go back to previous page"> Go back to previous page</a>

Cosmetic Graphics

Often graphics are used as minor embellishments to the page. For example, a bullet pointed list may use graphics for the bullet points instead of HTML mark-up, or an arrow may draw attention or emphasise an item of text.

In these cases it is important to give them a short, concise, alt tag (for example alt="Bullet" or alt="Arrow"). Without these alt tags some meaning or emphasis would be lost to some visitors.

Insignificant Graphics

Other graphics convey no important information at all. These include invisible spacer graphics used to govern layout, and all graphics that are simply flourishes (a sub-divider between menu items, for example).

It is important to ensure that access technologies ignore these graphics as they add nothing to the meaning of the page and would only cause unwanted "clutter".

Some web pages label spacer graphics with alt="spacer". This is highly inadvisable as they cannot be made to be ignored and will only serve to be very annoying to some visitors (especially in cases where there are several dozen on every page).

Some organisations advise the use of an asterisk (alt="*"). This practice is very widespread but also has problems (see below).

The best practice is to use a null alt tag of alt="" on all images that do not convey important information.

When graphics are labelled with a null alt tag no tooltip appears in Internet Explorer or Netscape when the graphic is hovered over with a mouse.
With a "*" alt tag a tooltip of "*" appears in both Internet Explorer and Netscape
People with little or no vision may be using screen-reading software (software that speaks back to them or sends information to a Braille display) or a self-voicing web browser. Hal (a commonly used screen-reader package) does not ignore graphics labelled with the "*" alt tag (i.e. alt="*") and announces "Bitmap star"
HPR and pwWebSpeak (two commonly used self-voicing web browsers) also do not ignore the "*" alt tag and announce "Image star"
All screen-readers and self-voicing web browsers completely ignore graphics labelled with the null alt tag (alt=""), with the exception of pwWebSpeak which simply announces "Image".

A null alt tag of alt="" will not cause any issues with the automated checking tools you can use to check your website.

Specialist Access Methods

There follows, for your information, a summary of the various methodologies and technologies used by those with disabilities in accessing pages on the web, with design recommendations to enhance accessibility/usability.

Mouse Users

Many individuals have no effective access to the keyboard. They may be using an on-screen keyboard to input data, but their primary method of access is some sort of mouse equivalent device.

The design issues that concern such a group of users in accessing on-line material is as follows:

Make graphical links and clickable areas a decent size
Avoid graphical or text links in close proximity
Avoid time-dependent functionality
Link to a page explaining how to tune the mouse response (see the "Accessibility pages" previously described in this report)

Keyboard Users

Some users rely almost entirely on the keyboard for their access. For example, those using a mouth stick, screen-reading software (see below) or switch access. Switch access entails pressing a switch (this could be with any part of the body, with the blink of an eye or by making a noise) to select a key from an on-screen keyboard.

These users would benefit from:

Limit the number of links on a page
Define a sensible tabbing order within links and forms
Use "Access Keys"
Avoid time-dependent functionality
Link to a page explaining how to tune the keyboard response

Voice Recognition Users

These packages are very powerful, and very complex. They can offer effective access to web pages by voice given sufficient computer processing and memory capability, a trained dictation technique and knowledge of the product and on-going support. The two main competitors in this field are Dragon Naturally Speaking and IBM ViaVoice. Of the two families of products the Dragon range incorporates a higher degree of "hands-free" capability (with the only truly hands-free package being the top level Dragon product, "Naturally Speaking Professional").

Voice recognition users move through the document with verbal commands. To click a link using voice recognition software the user must say all or any part of a hyperlink, or the alternative text to a graphical link. Page design issues for voice recognition users include:

Choose text for hyperlinks with care and avoid repetition
Ensure all graphical links are labelled with corresponding text
Avoid multiple forms on a page

Cognitive Difficulties and Dyslexia

Some users may have difficulty in reading text, may become confused by complex page layout or navigation scheme, or have difficulty in filling out forms.

Simple text to speech software (e.g. Texthelp or Readplease 2002) is often used by those with a literacy difficulty or dyslexia to reinforce their reading of the text (Texthelp offers additional functions to help with confusable words and word spelling). The issues with accessing web pages and other material are common throughout all text to speech packages (including those magnification software packages with additional speech output mentioned above). No one package will offer more effective access than another.

To improve access for this group you should:

Have consistent navigation methods and use non-graphical sitemaps and breadcrumb trails
Ensure consistent and uncluttered page layout
Ensure that text is concise, easy to understand and jargon-free
Use short paragraphs with sufficient white space
Limit new points to one per paragraph
Use a clear non-seriffed font
Link to a page explaining how to change colours and font sizes

Visual Impairment and Colour-Blindness

Many users have difficulties seeing a normal computer screen. Web pages can be cluttered, with small text in low contrast colours. Those with colour blindness have difficulties with certain colour combinations that appear to offer good contrast between text and background.

There is much that can be done within the browser and operating system to improve access for this group. However, for those with a more severe impairment, (commonly classed as moderate vision impairment) magnification software packages (such as Zoomtext Extra, Lunar or MAGic) can help.

These packages are all very similar in their functionality and the implications they present in accessing web pages. Hence no one package will give more effective access than another. However, Zoomtext Extra and MAGic have versions that can offer some speech output as well, which may improve access for some individuals.

Magnification software magnifies the full screen image to the user's desired level. The user cannot see the entire screen at any time, but rather a proportion dependant on the level of magnification being used (e.g. at 3x magnification the user sees a ninth of the full screen image).

The user moves the mouse around to "drag" the viewable area to different parts of the screen and clicks on links and forms in the usual way.

To offer best access for those with a visual impairment, magnification software users and those who are colour-blind:

Ensure consistent and uncluttered page layout
Avoid using graphics for text
Choose colours that ensure sufficient background and foreground contrast
Avoid using red/green and blue/yellow text/background combinations
Don't use colour alone to convey information
Use a clear non-seriffed font
Ensure all font size definitions are relative and not absolute
Link to a page explaining how to change colours and font sizes (see the "Accessibility pages" previously described in this report)

Screen-Reader Users

Screen-reading software allows a user with no useful vision to use a computer "eyes-free". It is much more sophisticated than text to speech software which simply adds speech feedback to reinforce what the user sees and is limited to speaking data that can be pasted to the clipboard.

The most popular screen-reading packages are Jaws, Window-Eyes and Hal. They all encounter similar problems when accessing a web page, with Jaws and Window-Eyes arguably offering the most sophisticated access to more complex web pages. IBM's Home Page Reader is a self-voicing web browser, which also offers comparable access.

No screen-reader user can access embedded applets or dynamic presentations such as Flash.

Here are some of the design issues to consider for this group:

Avoid numerous navigational links which are repeated at the top of every page
Ensure all images have alt tags - especially links
Avoid using graphics for formatting purposes that may be spoken
Choose text for hyperlinks with care and avoid repetition
Position labels in forms to the left or above the control
Offer an alternative to Flash and Java applets

Accessibility Glossary

Accessibility (web) - Designing sites so as many people as possible can access them effectively and easily, independent of who they are or how they access the web.

Alternative Text (ALT Text) - Descriptive text attached to any non-text elements such as images, movies and animations on a web page written in HTML. It is particularly important for blind web users who use assistive technology called screen readers to make sense of a page.

Assistive/Adaptive Technology - Computer software or hardware that makes it possible for people with disabilities to access computer systems they otherwise not have access to with standard computer equipment. Examples include screen readers and magnifiers, closed captioning, alternative keyboards and mice.

Cascading Style Sheet (CSS) - A separate file linked to a web page that contains the rules for how the page should look in terms of colours, font styles and size and layout.

Disability Discrimination Act (DDA) - The legislation in the UK that covers the rights of disabled people. The section of the act on the provision of goods and services includes the requirement that websites should be made accessible.

Extensible Hypertext Markup Language (XHTML) - This is an updated version of HTML, which uses more rigorous standards and rules to make better structured and accessible web pages.

Flash - Multimedia technology developed by Macromedia used for web animation and often used to build websites with rich dynamic content. Historically has not been very compliant with Adaptive technology but with each new version the accessibility features improve.

Frames - A feature of HTML that allows a page to be divided into two or more separate windows. If the frame does not have a <title> element, or the <title> element is not meaningful this can cause accessibility issues.

HyperText Markup Language (HTML) - The standard markup language used to create web pages.

JavaScript - A scripting language commonly used on web pages. It has many uses, including validating fields in a form, or writing information to the user's screen. Adaptive technology such as Screen readers don’t always support JavaScript which why its use is an accessibility issue

Lynx - A text only browser that is popular with people with disabilities and those in low bandwidth areas.

Screen Reader - Software that reads the content of a computer screen aloud. Screen readers can only interpret text content, so all graphic and multimedia must have alternative text descriptions using ALT text, captions, transcripts, or other methods.

Section 508 - This is a common name for Section 508 of the Rehabilitation Act. This is an amendment to a US law that basically says all Electronic and Information Technology purchased or developed by the US Government must be accessible to people with disabilities.

Spacer Images - also called spacer gifs. These are small transparent images placed on a page, usually in a table used for layout. They help to place text and images on the page for a good visual effect.

Usability – Determines how easy a product is to use. It has been defined as: "the effectiveness, efficiency and satisfaction with which a specified set of users can achieve specified goals in particular environments".

World Wide Web Consortium (W3C) - An international consortium of companies and organisations involved with the Internet and the World Wide Web, responsible for maintaining web technology standards, such as HTML and CSS.

Web Accessibility Initiative (WAI) - Started by W3C and its members, it addresses web accessibility issues.

Web Content Accessibility Guidelines (WCAG) - These are the guidelines built by the W3C/WAI to address issues in building accessible web pages.

Validation - Each web page should conform to a specified standard (document type) which is normally placed in the web page code, if when checked with a validation tool the page passes the standard it said to be valid. The benefit of valid pages is that they work better/more reliably with web browsers and a range of adaptive technology used by disabled people.