VIII. Accessibility Testing
Testing the accessibility potential of a website or any other application is an iterative process that must be undertaken very early in the design of the application or website. The purpose of an accessibility testing is to highlight problems encountered by the testing users while performing tasks on the website. Accessibility tests can be conducted within a usability test as the tasks may be the same, only a different type of testing user will be involved: disabled persons. Indeed, if accessibility is not only meant to facilitate disabled user’s experience of a website, they do are the firsts to encounters problems using an inaccessible website.
It sometimes seems difficult for developers to ask testing users to perform a task when the website is not fully functional, but partial prototypes or even sketches of the pages that will compose the website are enough to conduct the first tests; though the more close from the final product the more the comments will be precise.
Steve Krug dedicates a full chapter from his book “Don’t Make Me Think!” on usability testing. The processes, strategies, and advices he gives on the subject can perfectly be fitted to accessibility testing. In particular, he explains that it is better to run several tests with few users that one single test with many users. Krug demonstrates this theory with a simple example:
Figure 8.1: Problems identified by eight users in one single test.
“Eight users may find more problems in a single test. But the worst problems will usually keep them from getting far enough to encounter some others.”
Figure 8.2:Problems identified by three users in two tests.
“Three users may not find as many problems in a single test. But in the second test, with the first set of problems fixed, they’ll find problems they couldn’t have seen in the first test” (Krug, 2006, p139).
However, conducting accessibility, or even usability, test with even a few users needs time and money. And, even tough big, established company may have the means to do so; small, young ones may not. In this case, more basic testing can be made, generally involving only one person: the developer. This basic testing will simply be to check to website against the WCAG recommendation, and more particularly, its checklist (See Appendix 2 - Checklist of Checkpoints for WCAG 1.0). As previously said, the WCAG alone is not always enough to ensure the accessibility of a website to all, but complying with these recommendations will already be a good step toward a better accessibility.
The W3C checklist can also be completed by following recommendations of other structures such as Opquast. Opquast gives a list of best practice for the web. These practices, although not all turned toward web accessibility, will generally help improve a website’s accessibility, when followed. Opquast, like the WCAG, offers a checklist to be completed manually; some of the checkpoints can also be checked automatically (See Appendix 3 – Opquast Project Evaluation). This list of checkpoints contains some points similar to the WCAG checklist’s.