Slashdot Mirror
Handicap Access/RSI & Linux
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:- Additional development requirements for application developers
- Narrowly targeted accessibility aids
- No general model for accessibility
- Accessibility aid and application bound together on same machine
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
If you have access to a good newsagent or a University library (or any reasonably sized metropolitan library I suppose) track down their New Scientist collection. There is an article in the 10th of April issue covering RSI from a slightly different angle than normal. There's an interesting theory that RSI is not caused by physical damage to the wrists/hands, but rather caused by blurring of the brain's distinctions between the fine motor control areas for the hands.
It seems that when you spend a lot of time moving your fingers in very precise, accurate ways your brain can blur them together: you lose fine control over time. This effect has been shown to take place in monkeys made to earn food by `typing' (aside: presumably they put them on Usenet...), and there seems to be some evidence of it occuring in humans. Particularly susceptible, as you might expect, are keyboard operators and musicians.
There is a tiny tidbit from some while ago on the New Scientist web site -- unfortunately they don't appear to have put up the article I'm talking about. If anyone's sufficiently interested I daresay I could type in a couple of short extracts for review.
Here are a couple of links which you might find interesting (tracked down from the broken NS links...):
--
W.A.S.T.E.
W.A.S.T.E.
datahand
I can't help but evangelize this device. It is wonderful. My wrists were at the point that they hurt constantly, painfully; I lost sleep over it. I couldn't stop using the computer, though. After about a month of using nothing but the datahand, my wrists are SO much better. I still have occasional pain and numbness, but that's usually after using normal keyboards (like in the computer lab).
Datahand + fvwm2 go together to make a WONDERFUL team in terms of customizability. Even when I'm not using my Dathand, I don't have to use the mouse much (ctrl+shift+HKJL to move coarse, ctrl+shft+alt+HKJL to move fine-grained), and when I am, the fact I can customize the interface to be exactly right for the Datahand is so wonderful...
The personal edition cost me $900 after a 10% student discount. They're not cheap. But they're worth every penny. Consider that RSI surgery is generally $10k and only treats the symptoms (not the cuase)...
---
"'Is not a quine' is not a quine" is a quine.
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
>My wrists have started really aching lately, and I'd love to get an ergo keyboard or something,
This is not the correct response to the situation. The correct response is to SEE A DOCTOR, IMMEDIATELY. Every day you spend on self-treatment with a particular solution which may or may not be appropriate is another day in which you could be doing irreversible damage to your body. You do NOT want to do this.
(Trust me; I spent nine months largely incapacitated and in great pain thanks to delaying proper treatment, and while I can work again, there are still a lot of things I can't do with my hands and arms. This is not something to screw around with.)
Which particular keyboard you use is only a tiny aspect of your behavior which is causing this damage. Posture at *and away from* the keyboard, work habits and breaks, typing in non-strenuous ways, ergonomic workstation setup, and so forth are all important.
Furthermore, if you're already experiencing pain, it's quite possible that you can't type normally without causing more damage. In my case, by the time I saw a doctor, repeated microtears, scarring, and healing had shortened my extensor tendons to the point where I no longer had anywhere near a normal range of motion. Even if I'd adopted perfect ergonomics, I still wouldn't have been able to type without pain and worsening my condition. I needed a lot of physical therapy to get back to normal.
In short, don't assume you can treat this yourself. See a doctor.
Recommended reading: Pascarelli and Quilter, Repetitive Strain Injury.