Manual Accessibility Testing: Some content simply cannot be tested using automated accessibility validators and tools. As an example, an image of a tiger could have its alt text set to “mouse,” which is clearly inappropriate. There is currently no automated tool that can recognize the contents of an image and determine whether the alt text is correct. Ensure you chalk out a clear test plan with areas that you want to test manually to extensively cover the accessibility guidelines. Use assistive technology tools in the test efforts to simulate a disabled user’s experience in verification efforts. For instance, use screen readers such as NVDA or Jaws in a combination of operating systems, browsers, and devices to test for both accessibility and compatibility scenarios.
Automated Accessibility Testing: There are several tools that scan through the source code as well as analyze the application’s UI to report core accessibility issues. Such findings greatly supplement the manual test efforts in reaching out to all corners of the code, which may be difficult in manual code reviews. In our test efforts we’ve used:
- World Space Deque Tools
- W3C Markup Validation Service
- W3C CSS Validation Service
- Wave Accessibility Tool
- W3C Link Checker
- Color Contrast Analyzer Tools
- Tools from several independent sources, such as Juicy Studio
Use the VPAT: The Voluntary Product Accessibility Template (VPAT) is a great resource for the entire product development team, especially the test team. Developed in 2009 and owned by the Information Technology Industry Council, the VPAT lists the requirements for Section 508 to accommodate for accessibility in the product under development. The tester should ensure this template is discussed up front with the business, design, and development teams so everyone is on the same page about incorporating the requirements in the product. When included in your accessibility test efforts, the VPAT is almost like a certification for your product’s compliance with Section 508.
Consider Collaboration: To elicit valuable feedback, you can work with organizations that support people with accessibility issues. At our company we work with the Blind Relief Association in India to engage the visually challenged in our accessibility test efforts. This has helped us not only evaluate a product’s accessibility to the visually impaired but also provided equal employment opportunities for the disabled. As a side benefit, such collaborations have gone a long way in encouraging our employees to actively participate in our corporate social responsibility mission.
As you read about accessibility testing, it is important to understand and differentiate accessibility from usability—at least at a high level. Accessibility is about promoting access to a product and its contents to a group of people who might otherwise be deprived of the same. On the other hand, usability is about promoting a product’s user experience and intuitiveness. It is really difficult to say that one is more important than the other. What is important is to understand the underlying differences and work toward building a product that is both accessible and usable.
Take a moment to ponder the points listed above. Some are pure science on specific disabilities that need to be accommodated, some are pure art in terms of working with end-users to elicit feedback, and some are a combination of art and science with your hands-on accessibility testing efforts. When you arrive at the right balance in your overall accessibility test efforts and collaborate with your product development team and end-users, you are in a position to create a product that is accessible to one and all—and leaves no one behind!