Most people would agree that identifying and fixing issues before they make their way to production is a better process than receiving complaints from Twitter (or worse— lawyers!)
If you’re reading this, you recognize the importance of accessibility and the role that testing has in ensuring our applications are usable by all.
But there’s often still a struggle when it comes to accessibility testing.
One of the common sticking points I’ve seen is developers not being sure where testing would be most effective when their organizations largely don’t support it or care.
Here’s my advice on a process for prioritizing an area of your application to test.
First, identify the most important user flows. These are the things that would be really bad if they broke in production.
Write out the steps that a user would take to do a thing if they were using a mouse. Then do the same process for users interacting with the keyboard.
How does the user interact with the application–what actions can they take? What new data appears? What navigation takes place?
From there, turn these steps into a manual testing process that can be followed regardless of the team someone is on. This has the added benefit of getting other people in an organization involved & invested in the result.
Does the keyboard allow the user to move through a flow as expected? Do accessibility browser extensions report as expected?
Using a screen reader might be a bit ambitious for a new tester, as there is definitely a learning curve as it relates to user expectations. But it’s still worth considering.
Once you’re confident that multiple people on your team will be able to contribute to manual accessibility testing, move on to implementing automated tests.
For each step of a user flow, take stock of the individual components and elements involved.
Write unit test assertions against interactive controls, including inputs and buttons, to ensure they include proper labels and are operable per the WCAG 2.1 AA guidelines. Check out the many useful techniques available for unit testing & integration testing for simulating user events like key presses and clicks.
While building a repeatable process in the “real world” isn’t always straightforward to implement, this general approach is my go-to as a first introduction to an accessibility testing flow.
We go deeper into the nuances around implementing testing processes and how to determine what to test when in the Testing Accessibility workshops.