Handicap Access/RSI & Linux

Eric S. Johansson sent us a discussion document he's written about Linux and handicap access. I've included the full text below (with permission). Given the way my wrists have felt lately, this is something that really makes me think. What do you folks-what's the work being done for handicap access? For everything from RSI to vision impairment, I think this will become more important. There has been a significant discussion in the linux community about making Linux available to ordinary users but there remains one group of users who are not able to use Linux in any form. I am referring to handicapped users. Whenever there has been discussion about handicapped users, it has been most frequently in the context of blind users. There are far more handicaps than simple blindness. There are a multitude of partial-vision handicaps, mobility handicaps, and aural handicaps. All of these handicaps need accommodation for Linux to reach the mainstream. Why handicap accessibility is important Microsoft is making a major push in the area of handicap accessibility. They are under tremendous pressure from handicap accessibility advocates and governmental regulators to make their applications handicap friendly. To their credit, they have a far greater range of accessibility aids and adaptability than is currently present in the Linux/X11 environment. Alternative input devices such as tablets, speech recognition, special keyboards are available to users. You can use alternative output devices such as text-to-speech screen readers. Contrast this to the Linux world. While there are a few notable exceptions, Linux is "unfriendly" to people with disabilities.

For me, the two most compelling reasons for building handicapped accessibility into any operating system are 1) it's the law and 2) more importantly, it's the right thing to do.

Love it or hate it, the 'Americans with Disabilities Act' is the law. In a nutshell, it requires reasonable accommodation for handicapped people in public buildings and in the workplace. One of the major positive effects of ADA has been the creation of the design concept known as "universal access" or "universal design". The original goal was to create a design philosophy for constructing buildings that would be equally usable by handicapped and non-handicapped people. One of the unexpected side effects was that many of the design features that made it easy for handicapped people also were better for non-handicapped people. The reason for the side effect is that many of the physical tools (kitchen utensils, door knobs, sink faucets, etc.) that we use are kept out of habit and tradition. When examined for usability, better designs become quickly apparent and usually cost no more than the traditional design.

On the negative side, ADA creates liabilities for public and private sector employers. The reason this liability is a particularly insidious is that when it comes to computers, an employer may have no choice but to discriminate on the basis of a handicap because there is no way to accommodate the handicapped user. Employers are damned if they do and damned if they don't. This liability in turn becomes a problem for the operating system manufacturer and the application vendor. Vendors like Sun and Microsoft recognize the liability and have research groups working on addressing the problem.

More importantly, building handicapped accessibility is also the right thing to do. Depending on which statistics you believe, there are between 45 and 54 million disabled Americans. Workplace injuries continue to generate hundreds of thousands disabled people each year. The software development field alone generates some 50,000 handicapped people a year. By the time we reach roughly 60 years of age, about half of us will be disabled as a side effect of living on this planet. Any way you look at it, that's an awful lot of people to exclude from a computer-intensive society.

By not making computers handicapped accessible, you are telling some 20 percent of our population that they cannot hold a high-paying job, get additional education, or take advantage of the benefits of the Internet.

I know of all this first-hand. I was disabled in 1994 because of too many hours at the keyboard. I have recovered from my injury to the point where I can drive a reasonable amount, prepare food, and yes, use a keyboard to some extent. I'm still disabled because there are many things I can't do without causing myself tremendous amount of pain. I have experienced job discrimination and public embarrassment because of my handicap. Yet I've been lucky. I've been able to reinvent myself and develop a work life with computers thanks to speech recognition systems. But far too many of my peers have just fallen off the economic ladder when they became injured/disabled. When talking with them about what's gone wrong and how to fix things, it comes up over and over again that computer handicap accessibility isn't good enough yet for most jobs.

Today, computer handicap accessibility is very primitive. Accessibility efforts have focused on very select communities such as the visually handicapped and the profoundly physically handicapped. Accessibility aids such as screen readers, unicorn sticks, sticky keys, and paddle switchs are useful only if you have no other place to turn. Whenever I read articles or see programs showing some profoundly disabled person laboriously keying in characters so they can send email, I think people are astonished and pleased not because the accessibility aid worked well but because it worked at all!

The closest thing we have to a general accessibility aid for mildly handicapped people is speech recognition, but even that falls short, because it is optimized for a specific task. Speech recognition is tuned beautifully to English language dictation. Try to write code, however, and you'll soon find your throat feeling like you've been gargling broken glass.

When you step back and look at the entire handicap accessibility repertoire, it is apparent that accessibility aids are primarily point solutions that need to be done and redone with every revision of every operating system and application. A case in point is T. V. Raman's Emacspeak work. It's a wonderful example of adapting an application to a specific handicap. It's also a wonderful example of what's wrong with the state of computer handicap accessibility.

Emacspeak works extremely well as a tool for blind users using Emacs. It is extremely flexible, configurable and works with a wide range of Emacs Lisp based applications. The downside is it only works with Emacs and it only works with blind users using text-to-speech. It is a well done single point solution for a very targeted population.

Flaws with current computer handicap accessibility There are many flaws in the current approaches to handicap accessibility. Some of the major flaws are:

1. Additional development requirements for application developers
2. Narrowly targeted accessibility aids
3. No general model for accessibility
4. Accessibility aid and application bound together on same machine

Application developers today need to go through extra effort to enable their application for both visually and physically handicapped users. This is a flawed approach for a couple of reasons. First, if you do not live with a disability, it is very difficult to catch all of the usability flaws. Second, based on personal experience, anything requiring extensive additional work tends to get dropped as deadlines loom near. That means extra work for handicap accessibility is the first thing that dropped from a project.

Most accessibility aids, by their very nature, are targeted to a specific handicap. For example a unicorn stick does absolutely nothing for a blind user and a screen reader is overkill for a color blind user. Without a general model for accessibility, developers would need to build multiple user interfaces for a given application. It is my believe that a general model for accessibility would allow developers to add handicap accessibility to their applications with little or no effort.

Another flaw in the available computer handicap accessibility tools is that the adaptation and the application are bound together on the same machine. This forces the handicapped user into using a single machine which has been adapted for them. If your job requires you to use multiple machines, then you have to enable every single one of those machines with the same accessibility aids and configuration files and then try to keep those configurations in sync as your use evolves. If your enabled machine fails, you cannot work until the machine is repaired or replaced and all accessibility aids are restored.

With barriers like these, is it any wonder that handicapped people continue to have the double-digit unemployment rates even times like these?

Considerations for handicap accessibility There are better ways to solve the computer handicap accessibility issue than those provided by current solutions on the marketplace. The general case solution for handicap accessibility is a "hard problem" and I can't do it full justice here in this forum. The only aspect of handicap accessibility that I can speak to is that of a person with sore hands. However, with biases declared and out in the open, I will try to describe some of the requirements for building handicapped accessibility infrastructure.

A user should be able to

• Modify or customize the interface to meet their handicap needs and thought processes.
• Create incidental scripts easily to aid in task automation.
• Rely upon applications to have all functionality, data, and state available for query by a common accessibility scripting environment.
• Have the ability to store, retrieve, and act on state and context specific information.
• Count on applications having the capability to invoke actions in the common accessibility scripting environment.

The need for a changeable interface comes from the different characteristics of each person's handicap. For example, someone using speech recognition has a different user interface experience from someone using text-to-speech. Incidental scripts are important because limited mobile or vocal capacity should be conserved when performing repetitive tasks. The next two items come out of the need for an accessibility aid to drive an application. Speech recognition needs to know context in order to improve recognition accuracy. Text-to-speech needs to be able to find out what's on the screen and then read that back to the user. Data persistence is important in order to remember what is valid to hear or say in a given context. The last item comes from the need of an application to signal a user. When email arrives, instead of not hearing a voice saying "you've got mail," deaf users could have a light flash on their desktops triggered by the application calling a handicap accessibility script.

A long-term goal for handicap accessibility is to provide enough information so that an agent could explore an application via the interfaces listed above and generate an accessible user interface matching the persons handicap.

Conclusion Many of these problems became apparent to me from personal experience. There are many others that we could add from the blind, deaf, and severely physically handicapped communities. Once such an accessibility infrastructure is implemented, handicapped users would be empowered to adapt their corner of the online world to their needs. Given the right boot-strapping tools, we can pull ourselves up the rest of the way.

I wasn't kidding when I said this was a difficult problem to solve. It will require coordination and communication between multiple project groups. It will cause serious changes to GUI toolkits. Each of the requirements carries potential security risks. But it will provide the means to make a positive change in the lives of millions.

Are you up for it?

Write me at esj@inguide.com