[237] in DCNS Development
access
daemon@ATHENA.MIT.EDU (Mark Curby)
Thu Aug 27 11:23:04 1992
Date: Thu, 27 Aug 92 11:23:11 EST
From: mlc@MIT.EDU (Mark Curby)
To: developers@MIT.EDU, macdev@MIT.EDU, dosdev@MIT.EDU
Cc: Su@MIT.EDU (Su Jones)
Developers -
Su's comments on the new Athena Architecture are a nice summary of access
issues all developers should keep in mind.
- Mark
-----
[0121] daemon@ATHENA.MIT.EDU (su@EAGLE.MIT.EDU) 08/26/92 16:16 (80 lines)
Subject: Req. for New Athena Ar ch.
Date: Wed, 26 Aug 1992 17:18:09 -0500
To: naa@MIT.EDU
From: su@EAGLE.MIT.EDU
Cc: jis@MIT.EDU, goguen@mitvma.mit.edu
Hi Jeff et al -
With my ATIC (Access Tech for Info and Computing) hat on, one thing that
comes to my mind when thinking about requirements for new Athena arch is
ACCESSability. In order to include all members of the MIT community in the
use of Athena, it needs to be accessible to all members of the community,
including those with disabilities.
That broad statement actually includes many different parts, some of which
I know you are all ready considering or working on. Here's my quick and
dirty summary of main pieces of an accessible system:
1) Physical access to clusters (keypads low enough that wheelchair users
can operate them easily, adjustable height tables, accessible paths to
clusters - ie no stairs...)
2) Accessible operating system - (currently many people with disabilities
must access Athena via dial-up, as opposed to using it in it's native
XWindows environment)
a)allows for input from a number of devices, including serial
devices like alternative keyboards, mice, head pointers, voice recognition,
etc...) Basically - need to provide hooks for 3rd party access apps
b) features available similar to Apple's Easy Access and
CloseView, or Trace Center's Access DOS (includes sticky keys, slow keys,
repeat keys, visual beeps, etc, screen viewing change black on white or
white on black...)
c) Built in ability to adapt the environment to suite individual's
needs and habits (like ability to change default OS font size and type,
ability to change the way info is viewed/organized (ex: from graphical to
text view, etc...)
d) allows for output to a variety of alternatives including
Braille output (Braille does not equal English - it is different and
requires translation from English to Braille), voice output (voice
synthesis), and perhaps other alternatives.
3) Accessible user software -
a) Easily usable, cross-application available spelling, grammer,
and thesaurus software (helps everone, including people with learning
disabilities)
b) Software that is compatable with access technology software
and hardware
I know many of these are big objectives. I'm not suggesting that they
could all tackled and solved, but maybe some may be easily implemented.
Additionally, if the architecture has the hooks built in, maybe it can grow
to be a more accessible system? There are many projects that folks who use
ATIC services mention in using Athena. I'm sure if you wanted input from
those users, they'd be happy to provide feedback, or act as beta testers.
Again - these are just top of my head thoughts in response to Jeff's email.
If there is anything I can do to clarify these commetns, please feel free
to contact me....
Thanks!
-Su
==========================================================
M. Susan Jones (617-253-5111)
Coordinator - MIT Access Tech. for Info and Computing (ATIC)
Consultant - MIT Information Systems
Building 11 - 112 / 77 Mass. Ave.
Cambridge, MA 02143
su@mit.edu
==========================================================
--[0121]--
