🚀 go-pugleaf

Thought this may be of interest,
Jamal
----------
 From the web page
http://www.connact.com/~esj/ha.html

Handicap Accessibility for Linux
By Eric S. Johansson (esj@inguide.com)


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:
  * Additional development requirements for application
    developers
  * Narrowly targeted accessibility aids
  * No general model for accessibility
  * 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

----------
End of Document