Testers, as you well know, technology, especially the web has opened up new worlds for everyone who uses it. But have you ever thought about how the ability to access to technology impacts the lives of those with special needs? Imagine being blind yet able to read, unable to hear or speak yet able to chat or being complete paralyzed but able to travel the world? Technology has made all this possible for those with special needs, enriching their lives in ways they never imagined.
According to the US Census Bureau, 19 percent of the population in 2012 had a disability and half of these reported a severe disability, and therefore, accessibility testing will continue to grow in importance. So testers, welcome to the brave new world of accessibility testing!
People with special needs use special technologies including screen readers, screen magnification software, speech recognition software and special keyboards for communication, work and personal fulfillment, yet not all website are user-friendly to special users. Accessibility testing is defined as a subset of usability testing that is geared toward users of all abilities and disabilities. The focus of this type of testing is to verify not only usability but accessibility.
So how do we test accessibility? As with any usability testing, focus on the users. This means not only users with various disabilities and severities thereof, but also those with limited computer literacy, infrastructure, access and equipment. We may look for standards against which to measure and well as legal requirements that must be satisfied. In the United States, Section 508 of the Rehabilitation Act requires that all of the federal government’s electronic and information technology be made accessible by everyone; however, this applies to federal agencies only. However, the World Wide Web Consortium (W3C), the main international standards organization for the Internet, has created a guideline for making web content accessible to people with disabilities.
Web Content Accessibility Guidelines (WCAG) 2.0
The Web Content Accessibility Guidelines provides recommendations on making web content more accessible to people with disabilities. It provides conditions for testing in the form of success criteria based on four principles of usability principles. These are perceivable, operable, understandable and robust.
In order to be perceivable, web content must provide alternatives for non-text content, and time-based media. Examples include providing options for braille translations and captions for audio or video only recordings. Content should be able to presented in different formats and foreground should be separated from background for easier reading.
Operability requires that that all actions can be executed from a keyboard and that time limits for actions can be extended. Flashing should be limited as it is known to cause seizures. Finally navigation help should be provided in various contexts so that users know where they are in the application and are able to find content.
Understandable content means that it is easy to read i.e., limited use of jargon, abbreviations and it is written at lower levels of reading ability. In addition, web pages should appear in predictable was and functionality should be provided to help users correct their mistakes.
Robustness means that the web content should be able to be interpreted by current and future technologies including assistive technologies.
WCOG 2.0 goes one step further by breaking down the success criteria into levels of conformance. Level A is the minimum level of conformance; Level AA includes meets all Level A success criteria as well as the success criteria set at Level AA or provides an alternate version of the web content. This is the level that is recommended for most websites. Level AAA is the highest level of conformance and it is not possible for all web content to satisfy its success criteria.
Web Accessibility Testing
How do testers determine if the website under test meets the WCOG success criteria? The good news is that there are automated tools available for this. These tools evaluate the syntax of the website’s code, search for known patterns that cause accessibility issues and identify elements on web pages that could cause. These tools may also find actual and potential accessibility issues. Interpreting the test results requires knowledge and experience in accessibility issues.
However, as with all types of testing, especially usability, accessibility testing cannot be completely automated. And it is important that all testers consider accessibility as we execute our functional tests. For example, try turning off the mouse and track pad to make sure all functions are operable from the keyboard and try turning on Windows High Contrast Mode to see how the application works for low vision users. And what happens when images are turned off? Can you still understand the context of the content in the application? Testers, always remember, our job evaluating the quality of the application and that means ALL users must be able to access and derive value from the applications we test.