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
- the date that the site was reviewed
- what tools were used
- the results of testing, both specific tests and overall
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
- 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
- Note that many tests will require some explanation. For example, using
the simplest possible language, whether equivalent alternatives are
- 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
- 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.