Process for Reviewing Websites

This document is some notes about the process of reviewing a website for accessibility. They have not been reviewed or endorsed by anybody. So far it has been edited by Charles McCathieNevile, with some review by Sylvie DuChateau and Gregory Rosmaita. It was last modified on $Date: 2000/04/14 19:29:56 $

Note that the Evaluation and Repair Techniques document being prepared by the Evaluation and Repair Tools Interest Group covers much of the detail of reviewing according to the Web Content Accessibility Guidelines (WCAG). Although that document is apparently intended primarily as a specification for tool developers, human reviewers should also be familiar with it.

Things to do for review:

Describe the methodology used
Include

and describe the tests that were applied. (Where less than the entire site was reviewed, the process for selecting pages, and which pages were selected, should also be described.)

Select the pages to review
Ideally all pages will be reviewed. In a large site this may seem impossible, although many large sites are really templates populated from a database. In this case, testing the templates, and that the data provided is appropriate (for example there are equivalent alternatives as required) may not be as onerous a task as testing a medium-sized site whose content is unique. Where it is impractical to test an entire site, a representative set of pages should be chosen This must include any pages that are critical in the standard navigation path ("front or home page", site map, search pages, etc).
Validate the pages
Ensuring that the pages conform to a published gramar is in fact a requirement for WCAG-based review, but it is also a useful first step in many reviews since it can identify systemic problems of markup syntax.
Ensure that the pages work on a variety of platforms
Having a browser compatibility chart or tool is an invaluable aid. However, the test for accessibility is not whether the rendering is exactly the same, but whether there are bugs in some common browsers that render the content unusable.
Check the pages against the Web Content Accessibility Guidelines checklist.
Note that many tests will require some explanation. For example, using the simplest possible language, whether equivalent alternatives are appropriate, etc.
Check that the pages are usable by people with disabilities
This depends on knowledge of actual usage scenarios, or the availability of testers. In particular, this feedback can help to identify whether there are areas of the guidelines that need to be reviewed and perhaps revised. Note that currently the WCAG group has worked on the principle that if there is a widely available tool that can solve a particular problem then not having that tool is not an accessibility problem but a problem that the user could solve.
Contact the content author or provider and provide the review for comment
As well as being good manners, this can have two positive effects. Where there are accessibility problems identified in the page, the author may use this feedback to fix them, and where there are errors in the review (for example the reviewers didn't look at an important part of the page or site) these may be identified by the content author, who is liekly to best know the entire site content.