Where Does Accessibility Testing Fit in the Development Lifecycle?
As awareness of the need for software accessibility grows, large independent software vendors such as Google, Microsoft, Apple, and Facebook are introducing initiatives to bring accessibility into mainstream software development. While these industry giants are phasing in accommodations such as a built-in screen reader for a visually impaired users and color adjustment for those with low vision, the end-user-focused goal of 100 percent accessibility is still far from being achieved.
As a visually impaired user and, more importantly, an accessibility tester, I have firsthand experience with the shortcomings of the recent accessibility movement, and I have an idea of how software providers can negate or reduce these issues. The core problem lies with product teams’ keeping accessibility out of the core product development lifecycle. Although accessibility engineering may be planned for, accessibility testing is not seen as important as other testing areas such as functional or performance testing, which leads to uncovered accessibility issues during release.
“Test often, Test early” is an age-old saying in software engineering jargon. This holds good for accessibility testing, too, where it should be done from a product’s inception.
Here’s a recent example that illustrates why accessibility testing should be done from the early stages of requirements gathering. Until recently, the Facebook app for Android had a critical accessibility issue: Screen reader users were unable to expand posts, as the “continue reading” feature was not available via the assisted technology. There was no way for a visually impaired person using a screen reader on a mobile Android device to expand and read long posts.
After several updates, Facebook developers fixed the issue; however, they introduced a bigger regression issue. Now, mobile users utilizing screen readers are unable to edit profiles or access groups, bugs that aren’t even part of their known set of issues.
If I analyze why all of these issues occured, it appears that these features were not adequately tested across platforms from an accessibility standpoint. If accessibility had been considered from the very beginning, these issues could have been easily avoided. These issues are not all purely on Facebook’s end—some are accessibility issues from the Android side, too—though, in combination, the end-user is left with incomplete accessibility.
Like in testing of any other attribute, pushing accessibility testing toward the end of the lifecycle poses two major risks: Projects run over budget and time and it’s very difficult to fix accessibility issues later in the cycle. I recommend product teams build in accessibility testing early on and definitely have a few realistic accessibility users involved in their testing cycles.
