The Frustrations About 'Working Around' Accessibility

The point of accessibility is for users with a variety of needs to use your product. It is not simply to satisfy a federal regulation. If that’s all a company is concerned with, it’s a guaranteed missed opportunity. Moreover, stating that something is accessible does not mean it actually is -- meeting digital requirements without testing from an end-user perspective may mean that a product doesn’t work as accessibly as it could.

I was prompted to consider this situation due to a particular piece of software I was required to use for a class this past term. It’s a statistical package into which data can be imported and analyzed. Despite a specific section of their website devoted to their software’s compliance with Section 508 of the (American) Rehabilitation Act, which deals with digital accessibility, use of this software is cumbersome at best and frustrating at worst.

The results of inputted data can’t be read with any screen reader, lists of variables don’t appear as text so they must be memorized and typed in manually, and the viewer for the Help documentation is unnavigable. There is a command-line version of the software available, but it is only offered for Linux operating systems.

In fairness, the customer service team responds to accessibility questions and does try to help. The trouble is they don’t seem to have any solutions that work. For instance, they recommend a particular screen reader be used, which is not particularly helpful in this case. They don’t, however, tell customers about a particular command which could help alleviate the unreadable output problem – a command which creates a text log of all commands entered and their results. I had to find this out through a blind-specific mailing list. Google, not the Stata accessibility page, told me that help files could be accessed online in readable html, eliminating the need to use the unusable pdf viewer.

My issue is not that the software doesn’t work well for me. It’s not even that technical support didn’t know about specific accessibility recommendations. It’s that all of these things were true whilst the company claimed to have an accessible piece of software.

Whatever metrics they were using to test their software for compatibility, they didn’t include using keyboard-only access or reading help documentation with text-to-speech software. Worse still, their accessibility page appears to be written for legislators and government employees rather than potential end-users. They might have mentioned the above work-arounds, which at least make their software somewhat usable. As it is, I spent far too much time online looking for solutions, and resent the six-month license fees I paid.

In short, if a piece of software or an application is made more accessible  through the use of work-arounds, be sure to know what they are. If it isn’t accessible in any sense, don’t claim that it is. Honesty is always better than false hope.