Testing Websites for Accessibility

Reference materials and applications

Setting up your computer

• You will need a variety of browsers: recommended are: IE, Netscape, Opera and Lynx.
• You should have these running on several platforms including Windows, MacOS and Lynux.
• You may need to be connected to the Internet to use some of the online tools.
• You will need to organise your work so that you can see immediately what you have done and still need to do.
• You should be in the position to make screen dumps of complete windows and of sections of the screen.
• You should try to have a copy of HTMLTidy (platform relevant) for your computer.

Paper documents

Documents you need to peruse

You will be testing the site against the Web Content Accessibility Guidelines (WCAG). There is a Checklist that helps you organise your work. there is also a document of techniques that helps you know what should be done for compliance with a guideline checkpoint. As WCAG 1.0 is in the process of being replaced by WCAG 2.0, it makes sense to use that document.

So you need to go to http://www.w3.org/WAI/Resources/ to get:

• the WCAG 1.0 (local)
• the WCAG Techniques Document (local)

and the

• the Checklist (local)

You may want the XML Accessibility Guidelines.

If you are interested in the newer versions of these that are soon to appear, go to

• http://www.w3.org/TR/WCAG20/

Finally, you will want the suggestions about how to evaluate:

• the main document from http://www.w3.org/wai/eval/ (local) and
• the evaluation techniques document from http://www.w3.org/TR/AERT (local), although designed for authoring tools developers, are very useful.

Documents you need to produce

Assuming you will provide a written report on your evaluation, you will need a reporting document outline. Think about what is compelling information for clients and work out how you will provide that information. It may be helpful to have some background incorporated into the reporting document.

You will also need a checklist, and to produce some evidence of what you find unsatisfactory about the site so the client can see the problem. You will need to show compliance against the standard as well as explain why something does or does not conform.

Worst of all, you will need to think about what the conformance test means to the client. This is, perhaps, the nut of the problem: "What needs to be done to this site to make it compliant?" This is not usually what clients ask for, but as soon as they have information about the compliance, or lack of it, for the site, they move from wanting that information to wanting to know what needs to be done.

In practice, it is almost not worth the effort to try to evaluate a site without doing some instant repair work in the process. For this reason, it is much better if the client is looking for a mixed report including:

• an evaluation
• with a repair strategy, and
• some recommendations as to how the repair work can be done.

The main options for repair are that it is outsourced or that the internal team learns to do it so they become competent to deal with accessibility in the future. The latter strategy is recommended and should be undertaken with several in-house web workers from the client side and a competent trainer who can 'speak code'.

Note that all web resources should now be encoded in XML and so familiarity with how to do this and why it is beneficial is useful. see sections on XML, XHTML, and more.

Activities

Pick a page or two to evaluate.

Follow the suggestions on the Evaluation Guide Page.

Write a short report on the page.

Compare notes with others in the group and discuss what you think about the page and what you did not think about the page - what did others discover that you missed? What do you agree/disagree with that was offered by the others?

Last updated: 8 March 2002