We use cookies to ensure that we give you the best experience on our website. You can change your cookie settings at any time. Otherwise, we'll assume you're OK to continue.

Durham University

Computing and Information Services

Checking accessibility and accessibility-checking tools

There is no fully automatic way to check your pages for accessibility. A comphrensive manual check and some common sense in interpreting the guidelines will be necessary. However, the following tools may help you discover and fix some common problems.

It cannot be emphasised strongly enough that a site is not accessible just because one or more of these tools report no problems. If one of these tools reports a problem, then it probably needs to be fixed (though false positives do happen in certain circumstances). However, absence of reported problems does not mean absence of problems.

Accessibility checking assistants can give a false sense of correctness. Use them, because they will detect some problems, but never rely on them.

For example, very few accessibility checking assistants attempt to check whether alternative text for images is appropriate, only whether it exists. Even those that attempt to check for appropriateness do so imperfectly.

The guidelines section contains information on which parts of the recommendations can be checked.


One of the most useful checking methods is testing the site with a wide range of browsers. The RNIB has guidelines for using browsers to check accessibility.. We also have some guidelines for checking the accessibility of a visual design. As a minimum, you should use the following:

In addition, Opera, other text browsers such as w3m, other versions of Netscape, Konqueror, a speech-based browser such as Home Page Reader, and many other browsers should also be used for testing. You will probably need a combination of Windows, Linux or Unix, and Mac computers for full testing, but the four browsers above are all available for windows.

Why those 4 were recommended first

  • Mozilla and other Gecko-based browsers have a very standards-compliant rendering model, which is close to many other browsers.
  • Internet Explorer is very commonly used and has some noticeable differences from Mozilla
  • Netscape 4 has a wide range of bugs, especially with stylesheets, and no other browser behaves comparably.
  • Lynx is a traditional text browser, with minimal support for tables and frames in more recent versions. w3m has better table and frame support, but is not as commonly used. Lynx is also installed by default on the vast majority of Linux and Unix systems.

There are many more browsers available, and it is worth installing as many as possible if you are developing web sites.

If you have not used Lynx before, a basic lynx tutorial is available from - type lynx at the Unix prompt. If you are unfamiliar with Unix, Guide 1: An introduction to Unix will explain the basics.

Mozilla (and Mozilla Firefox) may benefit from the addition of the Web Developer Toolbar to make testing certain things easier.

HTML Validators and CSS checkers

Validators, unlike accessibility checking assistants, do give an exact answer. However, it is still possible for a valid page to be entirely inaccessible. Validation errors can cause accessibility errors due to variations in browser handling of these errors.

Your pages must be valid to meet Priority 2 recommendations.

  • The W3C's HTML Validator: This validator will check your site's code for compliance to the HTML standards. While errors here are not necessarily an accessibility problem, sites will display more reliably if errors reported here are fixed. It can check online sites and uploaded HTML files.
  • The Web Design Group's HTML validator: This validator is very similar to the W3C's validator, but phrases error messages differently. If you are having problems understanding the W3C validation reports, try this one instead. This validator can check entire sites or sub-sites at once.
  • Cascading Style Sheets checker: This checker can check style sheets for both syntactic errors, and for combinations of styles that may cause a display problem. Style sheets can be checked either by pointing at an online URL, or by copying them into a form.
  • Dr Watson validator: This validator can also check for some accessibility issues as well, including some link checking, spell-checking, and estimated download times. It does not support XHTML particularly well, however.

Accessibility Checking Assistants

Accessibility checking assistants are not perfect, and cannot be. They will give false negatives, failing to detect major accessibility issues, and (less often) false positives, noting accessibility issues where none exist due to their interpretation of the specification.

Many of these checking assistants provide 'seals of approval'. These are generally worthless. It is entirely possible for a site to meet every automatic check that Bobby and the other checking assistants provide, yet still be entirely inaccessible. Sites that use frames or javascript can cause false results very easily.

Jukka Korpela's description of the shortcomings of accessibility checking assistants is worth reading before using any of these tools.

  • Accessibility Valet: This checking assistant checks for a number of errors, and also has several modes that will assist checking of potential problems manually. It checks online pages, and is more insistent on the avoidance of deprecated presentational markup than other checking assistants. As well as the automatic checking it can also assist in manual checking of pages by highlighting things to check, and helping a systematic approach to checking (look at the Level 2 options in Report Format).
  • A-Prompt: This freely downloadable tool can check for common accessibility problems in a site and help you fix many of them. It only works on local files, so it will not be very useful if you use server-generated pages (unless you use a site downloading tool such as wget to take a local copy of the site). It tends to require manual checks of points, which can be useful, and it generally provides more useful suggestions than Bobby. Its advice on alternative text is unhelpful, however, suggesting descriptions instead of text equivalents. It also hasn't been updated for a while, and has some known bugs and shortcomings.
  • Wave: This is another online accessibility checking assistant. It doesn't check as many points as some of the others, but it is a useful way of checking many of the more basic points.
  • LIFT: LIFT is a set of usability and accessibility tools that work with Dreamweaver and Microsoft Frontpage. There is also an online version available to check pages already on the web. A free-to-use demonstration version of LIFT is linked from TechDis.

Specialised Accessibility Checking Assistants

This sub-set of accessibility checking assistants do not claim to tell you whether a page is accessible, but do make it easier for you to quickly test a page or set of pages under specific conditions.

    • Vischeck: Vischeck can simulate the effects of red-green and blue-yellow colour blindness on either existing web pages or on images. It is probably more useful to take a screenshot of a web page and use that, as Vischeck's support for some aspects of HTML and style sheets is limited.

    • Colour Contrast Analyser: There are recommendations for minimum contrasts. This tool will take two colour codes and give the brightness and colour distance between them.

Colour usage accessibility is part of the Priority 1 and Priority 2 recommendations.

  • Link Context Checker (local): This page produces a list of the links in a page, removed from their normal context, and with images replaced with their text alternatives.
  • Header Order Checker (local): This page looks at the order of header tags on the page and points out incorrect ordering.
  • Alt Text Checker (local): This page produces a list of images and their alt texts with a small amount of context from the original page to assist in checking of the appropriateness of text equivalents.
  • Web Page Backward Compatibility Viewer: This page allows you to selectively remove support for certain HTML tags and attributes from a web page. If your web page becomes unviewable under certain combinations then it needs fixing.
  • Search Engine Simulator: This page lets you look at your pages as some search engines might see them. It is important that pages contain distinguishing information in the search engine results.

Link Checkers

Broken links are a usability problem rather than an accessibility problem, but should be a high priority for fixing. Research suggests that broken links are the fourth largest cause of distrust of websites.

  • Xenu Link Checker: This tool is available on the Networked PC Service. An Infosheet (PDF) explaining how to use it is also available. Results can also be emailed to you. There are some types of broken link that it will miss because it's retrieval system automatically corrects them - but not all browsers will.
  • W3C Link Checker: This link checker can check pages that are currently on the web for broken links, and can recurse through links to a specified depth.


Lots of programs generate badly written and invalid HTML code. Tidy can fix some of the more common errors, and produce valid code instead. It will not, however, fix (or warn about) most accessibility problems, with the exception of accessibility problems that are also violations of the HTML specification, such as <img> tags without alt attributes.

  • HTML Tidy:

    This freely downloadable tool will automatically tidy up old HTML files into valid HTML code. Like A-prompt it will only work on local files.

    Tidy is now available on CIS Unix - from the unix prompt type tidy -f error-file -o output-file input-file. Make sure you read the error file, as this will tell you about errors that tidy was unable to fix automatically.

    Further information is available in Infosheet 163: Repairing HTML files with tidy.

    Tidy has lots of options. Type man tidy at the Unix prompt to read about some of them, and man tidyrc to learn about advanced configuration.

  • Tidy Online: This version of HTML Tidy can be run on pages on the web, and will display the tidied page to your browser, which you can then save as HTML.

Dealing with HTML produced by Microsoft Word

HTML tidy, even with the --word-2000 yes option, does not deal particularly well with HTML produced by Word 2000, though with the -c option it works well with Word 97's HTML.

The best way to deal with this is to use Microsoft's own HTML filter.

  1. Download the filter if you don't already have it.
  2. Save HTML from word as an unfiltered document
  3. Run the filter command-line program that comes with the download using the -m -s -t options, or use the graphical user interface. This will remove most of the custom markup in a sensible way.
  4. Run tidy with the default options on this file. This will change it from the windows-1252 character set to a more sensible character set. This will allow the page to be viewed without problems on Unix and Mac browsers.

Manual Checking

Checking pages with these tools does not guarantee that a page is accessible. However, errors reported by these tools will often seriously hinder some groups in their efforts to view your pages, and so should be fixed. A full manual check is always required.

User stylesheets

The use of user stylesheets to adjust the display of a page can often make accessibility problems clearer. A set of sample user stylesheets is available. User stylesheets are supported by several recent graphical browsers, including Internet Explorer, Galeon and Opera 5 or higher.

Opera 7 and Galeon 1.2 have the ability to apply multiple user stylesheets either simultaneously or separately, which makes testing with them easier.

For information on using user stylesheets, consult your browser's manual. Each user stylesheet has a brief explanation of its effect at the top of the stylesheet file.