I had the privilege of attending accessibility testing for an enterprise-level software application and found some interesting issues that are not typical to many projects. Actual user testing is strange like that – dealing with humans brings out all of the random factors.
First Issue: User Interaction with JAWS
One of the testers was a diabetic. She was blind and used Jaws, she also suffered from carpel-tunnel-like symptoms, called trigger finger. The tendons in her hands were shortening and becoming increasingly inflexible, which happens to many diabetics. Her hands were scarred from multiple surgeries on those tendons. The issue I observed was that some of the keystrokes combinations were very difficult for her to perform. Certain hand movements were difficult, slightly painful, but it was a surprise to find an unintended consequence to key combinations.
This became more of a JAWS issue for her navigation. She relied on simple keystroke commands, but the application required her to use some complex commands, which were difficult. This became a case of evaluating the controls and how it could be made easier for accommodation.
Second Issue: JAWS familiarity
Most accessibility issues could be overcome by improving the level of JAWS familiarity. Many JAWS users have a basic level of JAWS interaction, enough to get them where they want to go. However, this application will require specific JAWS training for internal employees. There are many functions in the application that are much easier to manage with a high level of JAWS expertise. We found that most JAWS users have the necessary understanding for navigating documents and the web, but they like learning new methods of improving their experience.
The advanced JAWS users were more able to cope with troubleshooting, navigating new and unfamiliar applications, pages, and accomplishing the specific testing goals. The added familiarity supplemented their toolset of resources in dealing with unfamiliar web pages. The accessibility of any system improves with the level of knowledge of the JAWS user.
Third issue: Usability v Accessibility
The developers of this software application tested many methods of improving accessibility. Each option was tested and evaluated. However, in the actual user testing the JAWS users expected certain behaviors, such as error handling, which were typical of using the web in combination with Internet Explorer and JAWS. When those specific events were improved in the application, the users were not pleased with the different behavior. Even though the application was more accessible, the users did not expect the more accessible behavior. They were used to overcoming the obstacles of poor accessibility and expected that behavior. Because they expected something different, they were not prepared for the more accessible method, and some actually preferred the less-accessible behaviors.
This is one case where expectancy, a key component of usability, affected the judgment of users in using a new system. The developers now had a dilemma of keeping the more accessible code, which improved many functions, or to change the code back to the typical less-accessible counterpart, simply because users were used to the issues that they typically cope with.
Fourth Issue: Vendor Claims
Here is where I can rant for days. Software applications that claim to be “accessible” but really aren’t. And usually, there isn’t even a good case that could be made for the “accessible” claim. Because a screen reader can toss out a few works? How can you describe your product as accessible when you don’t even use proper markup of page elements, frames, and critical navigation items?
As an example, this software produces reports that are navigated across multiple frames. The frameset lacks any <noframe> descriptions, so the user only has the title of each frame, which is barely descriptive. The main navigation is a tree structure that has no labels or descriptions, and the only method to expand the tree navigation is mouse-dependant. The navigation labels in the actual report lacked any sort of descriptive text. “Void” was the label for the print function. Many other labels were non-existed, misleading or simply absent.
This is accessible? How can you possible claim to be an accessible product when your application does not even take the simplest steps for accessible mark-up?
This last issue was the one that made me the angriest. The vendor of this application is seemingly unimpressed with the customer’s repeated requests for an actual accessible product. They simply seem to shrug their shoulders and claim that it is “accessible” when it is clearly unacceptable. It makes me wonder how this claim can be made and if there are any laws being broken. I am also sure that many vendors make the claim of being accessible without even understanding what accessible means, much less having the user testing to back it up.
What I learned
Even the best programming cannot account for human accessibility and usability testing. testing is critical to developing any site or application, as there will be many factors that were simply not considered, but will increase the effectiveness of the end product. My favorite part of the testing was the interaction and conversations with each of the testers. I enjoyed getting to know them, their stories, and their opinions about website accessibility. I feel as though I learned more from these amazing people than any book could have contained.
