Saturday, October 10, 2009

Firsthand Frustration with Interface Inaccessiblity

Most of us in the software development business are probably at least aware of accessibility issues associated with software development (particularly user interface development). However, I find that I usually understand the need for something better when I experience the need myself. Although I have learned some lessons about the importance of accessibility from those around me with accessibility issues, I recently encountered a personal experience with an interface that was rendered largely inaccessible for me. It was a frustrating experience, but has provided me with new understanding and empathy for those who are forced to use interfaces that lack sufficiently accessible design. In this post, I look at the personal frustration I felt firsthand during this experience and review what I've learned from it.

Those who know me or have attended one of my technical presentations would probably agree with my statement that I have relatively deep voice. One of the disadvantages of having a relatively deeper voice than "the typical range" of voices is that careful enunciation is more important to convey what I'm trying to say. Years ago when my wife and I went to Disney World, I was impressed at the advancements in speech recognition demonstrated at the Epcot Center. Although these voice recognition systems worked well for everyone in our party, they did not even acknowledge that I was speaking. Since then, I've noticed that most voice recognition software has trouble handling my voice.

In this recent customer service fiasco, I needed to change some information on one of my accounts. The automated telephone system gave me the option of using telephone keys or voice recognition. Because I am all too familiar with the limitations in speech/voice recognition related to my deep voice, I chose the option of using the telephone keys. For most of the options, this worked well. Unfortunately, there were a couple of prompts during the process that required me to speak the selection. My guess is that the system was built this way because of the difficultly of differentiating between numerals and letters based on telephone keys pressed. Whatever the reason for this design and as no surprise to me, the voice recognition did not work well with my voice.

The voice recognition service kept misinterpreting at least one of the letters that I spoke. When I tried to enunciate them more clearly, any late emphasis in speaking a particular letter was interpreted as a second letter. It was bad enough that I had to keep repeating the same string of letters and numerals, but it was even more frustrating when the system would report automatic transfer to a customer service agent after three failed attempts. This would not have been so bad except for the fact that the "transfer" ended up in the call hanging up after about 15 seconds of various noises. After experiencing this twice, I really wished that I could continue trying to voice the letters in a way the system could understand rather than being "transferred" again.

In this case, the company I was working with has a virtual monopoly on the service that I purchase from them. This may be one reason that they get away with a system that "transfers" a customer by hanging up on that customer. It also made me realize that their telephone system was basically inaccessible to me and, if I had any alternatives or substitutions for their service, would drive me to that competitor. I asked myself why they didn't have an online presence where I could enter letters and numerals from my computer keyboard in such a way that they could easily differentiate between the two and I would not need to worry about inaccessibility due to the deepness of my voice.

From all this, I now appreciate more than ever the importance of building accessible software systems. Several years ago, I learned the importance of dealing with colors when one of the highest ranking officials representing my client had severe color blindness. I had built a Flex-based demonstration for this client that relied heavily on colors and contrasts for visual effect. This client representative could barely make out some of the features after significant effort. Although my color scheme enhanced the conveyance of information for the "typical" viewer, it made it worse for him. I experienced the same frustration with the telephone system: it probably works well for the "typical" user but was extremely frustrating and essentially inaccessible for me.

The Electronic and Information Technology Accessibility Standards (Section 508) states its purpose as follows:

The purpose of this part is to implement section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d). Section 508 requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, Federal employees with disabilities have access to and use of information and data that is comparable to the access and use by Federal employees who are not individuals with disabilities, unless an undue burden would be imposed on the agency. Section 508 also requires that individuals with disabilities, who are members of the public seeking information or services from a Federal agency, have access to and use of information and data that is comparable to that provided to the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency.

This requirement for federal systems (United States) to be accessible to public users is particularly important because there is usually no competition for these services. In other words, the users are captive customers and need to be able to access their services. In the competitive marketplace, it makes sense to provide accessible services so that potential customers will not move to the competition.

It is important to develop our services in an accessible way so that potential customers do not give up on us and leave in frustration. Popular programming languages, frameworks, and platforms often provide assistance in creating more accessible software. Examples of this include Java SE Desktop Availability (including the Java Accessibility API and the Java Accessibility Utilities), Flex Accessibility (including accessible components, tutorials, and best practices), and .NET accessibility features (such as the AccessibleObject class).

Accessibility Rule of Thumb

As a rule of thumb, it seems that an interface should always have at least two ways to convey and accept information. If the telephone system uses voice recognition, it should probably also be built for 100% support for pressed keys for those of us with "voice challenges." Similarly, the voice recognition is likely a nice alternative to pressed keys for those who have poor eyesight or otherwise have difficulty pressing the correct telephone keys. Our interfaces are more likely to be generally usable if they provide more than one way to accomplish each task. Some people hear better than they see and some people see better than they hear.


It can be an extremely frustrating experience to deal with an interface that likely works for "most people," but does not work for me because of assumptions made when designing the interface.

Additional Interface Usability/Accessibility References

Electronic and Information Technology Accessibility Standards (Section 508)

Usability Approach to Accessibility (focus on tip #17)

Understanding Web Accessibility

The Resolution Race: Perpetuating Inaccessible Computing

Clinton Pledges Funds for Net Accessibility Research

No comments: