There are some excellent tools available to aid in the task of evaluating your Web pages for accessibility. While no software can do the whole job, automated checkers can flag both obvious errors and areas of potential concern, where human judgment is key. Best of all, many of these accessibility tools are free!

When should I use evaluation tools?

  • On existing sites

Not just for retrofitting – most of the accessibility problems an automated checker will find are easily correctible. By far the most common error is a missing ALT attribute in an image tag. Fix them on the fly!

  • During development

As you build, using accessibility tools will help ‘keep you honest’ and designing according to standards. Intelligent design from the start will save you – and your users – worlds of pain later on.

  • Before going live

A formal accessibility evaluation can both catch last-minute problems and provide some validation for your hard work during the development process.

Useful Tools

A continual awareness of accessibility concerns should be a part of the development process, and these tools allow you to perform both informal spot checks and more thorough analysis as you build. Evaluation tools fall into three main general categories: Web-based, desktop applications, and toolbars. All have their place in an integrated development environment. In addition to evaluation, there are also easy ways to emulate the experience of a user with disabilities, which can be very informative (see Emulating the User Experience below). All of the tools mentioned here are either free or donation-ware.

  • Toolbars

Accessibility toolbars are a great resource. They make the developer’s job easier by aggregating disparate utilities in one convenient location. The fact that they are browser-specific is the only real downside to toolbars, but happily there are good ones for IE and Mozilla. The NILS accessibility toolbar, for Internet Explorer, has a solid focus on accessibility, and provides an astonishing array of features, from browser window re-sizing to links to popular Web evaluators. Chris Pederick’s Firefox Web Developer Extension Toolbar offers many of the same gee-whiz emulation tricks for Mozilla/Firefox users, as well as a host of general Web development tools you really can’t live without. And Mozilla users should keep their eyes on WAIZilla, which is not yet ready for prime time but promises great things.

  • Web-based

If you don’t want to add a toolbar that provides direct links, you can always bookmark the evaluation and emulation tools you choose to use. First ports of call for any self-respecting developer are the World Wide Web Consortium’s markup and CSS validators – if your code validates, chances are it is well on the way to effective accessibility. Web accessibility checkers examine your code and generate a report based on parameters you set – which standard (508, WCAG, etc) and the amount of verbosity you require. Watchfire’s Bobby is an excellent product, and the WebAIM initiative’s WAVE is also good. These render output differently, and usability isn’t always that great. Try these (and others!) and go with the one that you find easiest to interpret.

  • Desktop

There are software applications that operate outside the browser – these are frequently more robust than their Web-based counterparts, but have their own limitations – platform specificity being chief among them. IBM’s aDesigner provides a thoughtful interface and genuinely useful output in a desktop application. A-Prompt, from the University of Toronto, is feature-rich but perhaps a little more complex to use.

Emulating the User Experience

While automated testing tools can compare your pages to a set of guidelines and give you a thumbs up or thumbs down, there are other resources that can help you experience the page as a user might. This is often much more informative from a design standpoint. The best emulator, of course, is no emulator at all, but a real user instead. If you know a person with a disability who would be willing to give you feedback, by all means take advantage of the opportunity.

Using assistive technology can also be useful, since users with disabilities will be using it as well. The learning curve is often steep, however, and screen readers vary in price from $150 (IBM Home Page Reader) to $1000+ (JAWS, UNC’s campus standard). To visualize the browsing experience from the point of view of a blind or low-vision user, try linearizing your site by using a non-graphical browser, like LYNX. Delorie.com kindly hosts a LYNX emulator if you don’t have access to a command line.

Human Judgment: No machine can do it all

Like all things worth doing, accessible design is fraught with judgment calls. Some accessibility guidelines simply can’t be checked off by an automated tool. Consider screen contrast – it is a subjective value, and you need to actually see it to decide if it is acceptable or not (Juicy Studios may not agree; see their Contrast tool). In other cases, it is actual content that needs human judgment – the description in alternate text, for example. The bottom line is that you cannot rely exclusively on the wonderful tools described in this document. Treat any site with a ‘Bobby Approved’ label as suspect – just because a Web page ‘passes’ Bobby means very little in practical terms. The World Wide Web Consortium Web Accessibility Initiative has lots of resources related to evaluation, and handy guidelines you can follow in your role as the human half of the testing team.

Conclusion

The proper tools, used consistently throughout the development process, will ease the accessibility burden dram””atically. Taking the time to install – and use – a browser toolbar will make informal spot checks very straightforward, and Web-based or desktop applications can provide the features you need for a more comprehensive evaluation.