Observing Accessibility - SiteLogic Marketing

For many years, I was heavily involved in the Accessibility Community for programming, testing and developing accessible websites. So much so that I even ran a blog on it for many years. Many times, in my speaking on various subjects, I do not get the opportunity to delve into accessibility and the importance of it. Recently, I was able to observe some user accessibility testing of a large application, and was fascinated with the people and their stories. What follows is a steam of thoughts and observations that I had while observing these tests. Actual user testing is strange – 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, a screen reader, to navigate sites by listening to the links, content, and options. From the diabetes, she also suffered from carpel-tunnel-like symptoms, called trigger finger. The tendons in her fingers 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 is more of a JAWS issue as the program is made for blind users to use key combinations to navigate websites and applications, but sometimes does not take into account any physical disabilities that may also be in play. She relied on simple keystroke commands, but the navigation sometimes required her to use some complex key combinations, which were difficult.

Second 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.

his 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.

Third 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-dependent. 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 in the development. 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.