Intro to Web Accessibility Testing Tools Part I: Assistive Technologies
Hello, and welcome to the Olenick Web Accessibility Testing Tools Blog Series!
Throughout this blog series, we will introduce Web accessibility testing, overview some of the testing tools available for accessibility testing, and analyze the pros and cons of each tool.
In its simplest definition, Web accessibility testing is testing performed on a website to determine the extent to which the site can be perceived, navigated, and operated by people with a variety of disabilities. In a perfect world, all people would have equal levels of access to perceive, navigate, and operate all available Web content, regardless of disability.
There are a plethora of freely available testing tools that can speed up accessibility test execution and bolster testing quality. However, when kicking off accessibility testing for the first time, the best approach is to start by trying to navigate the Web using the same assistive technologies (AT’s) as people with disabilities use. This exercise will provide future testers with a clearer understanding of how people with disabilities interact with the Web and a better sense of what gaps to look for when testing Web pages and validating the corresponding HTML code.
When performing desktop Web accessibility testing, there are two great approaches to this exercise. The first and most effective method involves using the top-rated free screen reader NVDA (Nonvisual Desktop Access) to mimic navigating the Web like someone with low or no vision would. Using the screen reader, the user should be able to hear all of the Web content that is “in focus” (i.e. users hear the text that their cursor is hovering over). This approach makes users aware of what they should expect to find in the HTML code when they begin the actual testing (e.g. did the users hear alternate text for an image when their cursor hovered over it?).
The second approach to the exercise is to practice navigating Web content using only a keyboard. This procedure (to some extent) mimics the way people with low motor skills would interact with Web content. For example, users should be able to focus in on, and activate, all interactive elements of a Web page, just as a user would be able to with a mouse. Since some of the Web Accessibility Guidelines directly pertain to keyboard navigability, this approach will also alert future testers about where potential keyboard navigation traps exist on a particular Web page.
Aside from screen readers and the traditional keyboard, there are a wide variety of other assistive technologies that can be employed to mirror the Web interactions of people with different types of disabilities. Some examples include talk-to-type inputs and handwritten-inputs, however, the intent of this exercise is to gain a better understanding of the Web elements that accessibility testing is validating, not to exhaustively practice navigating the Web with AT’s.