Yesterday’s Weekend Testing Americas session brought up a couple of interesting arguments justifying accessibility testing. Accessibility issues can have impact beyond the end user, and testing can be surprisingly cheap.
Thanks to Albert Gareev and Michael Larsen for facilitating the session, and all who contributed to the discussion.
You already test accessibility for free
When people talk about accessibility testing, it often sounds like testing for minorities. The percentage of users on a specific mobile device, the percentage who not read English, the percent who are colourblind, etc. It’s then easy to dismiss accessibility testing entirely because you can’t afford to cover minority groups.
But I’ll bet that you are testing for accessibility, just for a narrow set of users - users who are like you.
Imagine a website has a Login button, but the button has been offset off the edge of the screen. You look for the button, can’t find it, and report the issue. At first glance this seems like a generic functional issue, but really you’ve just performed an accessibility test covering sighted users. This issue wouldn’t have affected blind users, who could have located the button with an audio screenreader and selected it with Tab.
Obviously this testing is not rigorous or broad. But it’s something, and it changes the conversation from starting accessibility testing to expanding accessibility testing.
You’re doing it anyway, so do it better
In the example above, you’re catching an accessibility issue without explicitly looking for it. Even if you cannot commit resources to dedicated accessibility testing, you can improve your ability to passively spot these issues.
For example, after reading the WebAIM guide to visual disabilities, I realize that contrast between text and background is particularly important for many visual disabilities - and it impacts my reading as well. If I find myself struggling to read something, I can use that as a warning sign that users with weaker vision could find it very difficult to read - prompting further investigation.
So you find some accessibility issues… are they worth FIXING?
Every project has its own unique needs, but the WTA session raised a couple of arguments for fixing accessibility issues which I hadn't considered previously.
Accessibility issues have an impact similar to transient functional issues, so they deserve an equal response. Suppose a graphic failed to load 8% of the time, or simply never loaded in the Safari browser (Safari has a little over 8% market share). In most of the projects I've worked on, my team would pursue that issue. Well if the graphic relies on distinguishing red from green, then roughly 8% of Caucasians will be unable to use it, along with lower percentages of other races.
Accessibility issues carry an emotional weight beyond their functional impact. A user who finds your product unusable may feel neglected, and may pass that sentiment on to their friends and colleagues. Admittedly this impact is tough to measure, and you need to decide whether the “neglect” of an accessibility issue is worse than the “sloppiness” of a functional issue.