Performing Accessibility Testing on a Live Site: A Case Study
For five years, my company has been providing solutions for varied clients from diverse domains with a wide range of accessibility testing needs. In the most common case, they reach out to us not knowing much about their accessibility requirements and ask us to test their sites end to end and provide feedback and recommendations.
Given that accessibility is just starting to really gain prominence and awareness in the product development world, organizations are often not fully informed on what it takes to build accessible software—they just want to get there. Here’s a case study from a recent project that we worked on and what we did for them, given the challenges we were posed with.
This was a client of ours in the e-learning and digital media solutions domain. This project was unique in that it had a large challenge where we had to cover accessibility testing for seventeen e-learning courses in less than a month. Our team was up for the challenge. We set a target to cover one course a day and decided to choose the most optimal scenarios that would maximize test coverage.
Initial courses required more planning, but we were able to leverage what we learned from them for subsequent courses. We reported about three hundred bugs across all the courses. Some of the more prominent issues we faced are discussed here to help other teams under a similar time crunch.
Dragging and dropping is a very common activity in applications, but this action is often not accessible for screen reader and keyboard users. The client had difficulty making this activity accessible, so we proposed a solution where an optional view would be given for keyboard users and screen reader users. Accordingly, a message reading, “Screen reader and keyboard users switch to optional mobile view to complete this activity” was implemented.
Secondly, there was a lot of video content across the courses, but the media player was not accessible. Flash was used as the underlying technology, and making Flash content accessible for screen reader users is very difficult. We proposed using an HTML5-powered player to allow access to everyone.
Alt text also was missing for images, and while testing in pairs with a sighted engineer, we found that the screen reader was bypassing those images. While the client skipped alt text for many images because they were primarily decorative, our discussions with them ensured that essential images were given a proper text description.
Implementing accessibility is a process of deliberation. It is not purely verifying implementation against requirements; it involves design suggestions, engineering recommendations, adherence to guidelines, and exploring alternatives. Our efforts in this project prove that with the proper considerations—even in a short time frame—any company can take steps toward making their product more accessible to everyone.
