Other Resource: “Accessibility Testing” at the W3C Wiki

Citation: Hawkes-Lewis, B. (2014) Accessibility testing. W3C Wiki. Retrieved from https://www.w3.org/wiki/Accessibility_testing

The idea of carrying out web accessibility testing on a web site you’ve built can be daunting, especially if you’re not well-versed in web accessibility in the first place. This guide, originally created by Benjamin Hawkes-Lewis for Opera’s Web Standards Curriculum, introduces users to the idea behind web accessibility testing, provides an overview of basic concepts, and describes a number of methods that can be used to test a web site or other online resource for accessibility.

One of the key takeaways from this guide is also its shortest section: When to test for web accessibility. Hawkes-Lewis notes that “test early; test often” is the best advice, as trying to do all your web accessibility testing at the end of the development process can be expensive and time-consuming.

Before you can start doing that, though, you need to know the reason you’re testing. Your “external requirements,” such as government mandates, corporate or institutional best practices, or common userbase demands will all play a role in what you check for in the testing process. Hawkes-Lewis notes, however, that these “should only be the beginning of the process; they should be treated as a minimum set of requirements” instead of your end goal.

One way to get a handle on what kind of disabilities to test for is to create user personas—”fictional users that act as archetypes for how particular types of users would use a web site.” These personas can be used to more clearly understand the kinds of things your users might want to accomplish on your site, and can help you uncover some of the problems they might run into while doing so.

Hawkes-Lewis further breaks down accessibility testing into “expert testing” and “user testing.” Expert testing—probably the type most people think of—involves a web accessibility expert examining and analyzing either the public view of your web site (whether via a monitor, mouse, and keyboard or through the use of a specific web accessibility tool) or its code (manually or by automated checkers).

User testing, as the name implies, involves seeking out actual users—ideally those with actual disabilities—and observing them while they try to use your web site. As Hawkes-Lewis points out, this kind of user testing can quickly get expensive. However, he says that “even small-scale user testing” can have significant benefits for accessibility.

It’s important to realize that for user testing to really be effective, you don’t just want to put your testers in front of your web site and let them do whatever. Instead, you should have a set of tasks for each tester to try and complete. Observing testers try to complete these tasks can allow you to “uncover lots of problems you had not anticipated.”

Hawkes-Lewis provides a number of links to groups that might be approached for user testing purposes.

The final step in web accessibility testing according to Hawkes-Lewis is to communicate your results and to act on those results by working to improve your site. It’s worth remembering the adage he quotes early in the guide, however: “test early; test often.” By integrating accessibility testing into your design process, you can drastically improve your final web site.