Hi,
Here's an FAQ about an auxilliary command line interface as an access
approach for blind people using GUI's.
Scott
PS If you would like to check out a demonstration, please let me know. You'll
need telnet access.
--------------------------------------------------------------------------
1. What is an auxilliary command line interface (ACLI)?
An ACLI is a type of access technology (AT) which can be used by visually
impaired computer users to interact with various aspects
of a GUI. The user enters various commands into the command line
part of the AT and the AT then performs the requested actions
with regards to the GUI.
2. Is the ACLI separate from a screen reader?
The ACLI can be implemented in two different ways. One as a stand-alone
piece of AT. In this case, the ACLI either produces direct voice
output or text output which is then read by a screen reader. The
other approach is for the ACLI to be built directly into the screen reader.
3. What kinds of problems does the ACLI address?
The ACLI actually addresses a number of problems. The ACLI helps
improve the efficiency of a blind person when both learning and
interacting with a GUI. The ACLI can also help improve a blind
person's understanding of each GUI.
A key problem for a blind person interacting with a GUI is coping
with the visual cuing that occurs in so many forms. A real basic
problem is icons. The blind user often has to compensate by using
documentation to learn of the existence, location and purpose of
a location. Using an icon means having to remember the location
and being able to move the focus to the icon.
Use of icons can be a little more confusing when the same icon
is used more than once on the screen. In this case, the
purpose of the icon is conveyed visually by what other objects
are nearby. For example, a right arrow icon could mean both
next person or next screen depending on what the icon is near.
Another example of visual cuing is color. Suppose that two
buttons have the same label, but the backgrounds are different
indicating different uses.
In an ACLI, each button, icon, etc, has one or more unique command
names. The command names can explain the purpose of each button, etc,
and reduce the dependency on visual cuing.
The ACLI can improve the efficiency of a blind person learning
a new GUI. Instead of exploring the GUI which can often be
incomplete or misleading if buttons are accidently missed or skipped.
the blind user can just ask for a list of command names which
helps the blind user get a quick overview of the functionality
provided by the GUI.
The ACLI can also improve efficiency by reducing both navigation
effort and learning requirements. For example, instead of
having to remember the location of a button in a GUI and
then navigating to it, the blind user could just type the
command name associated with the button.
4. Does this mean that a user will need to memorize many commands
for all the various GUI's he uses?
Actually, the ACLI can have various useful functions built into
it to reduce the need for memorization. For example, the ACLI
could contain a type of search engine. The blind user could
then tell the ACLI to execute a command which contains the phrases
"spouse", "first" and "name". The search engine could then search for
the desired command.
5. Where do the command names come from?
The command names and abbreviations need to be specify when the GUI
is being developed. Probably, the developer doing the work
would assign the command names and abbreviations for each button, etc.
6. Is there a way that the command names and abbreviations could
be automatically generated?
Doing this type of work automatically is currently ot very possible
in most situations. For example, if the GUI is using a right
arrow icon, the program would have to guess what a right arrow means.
Does it mean "next"? Is it the "right" direction? Or in another
situation, suppose that two button both have the same label,
but in one case the background is green for "husband" while in the
other case, the background is yellow for "wife".
7. How hard would it be for a developer to assign command names
to buttons, etc?
The developer could do this quite easily if the proper functionality
is provided by the GUI software. For example, if MSAA or Java Access
provided a slot in each button, etc, for command names, the
developer would just fill in the slot with a string containing a
command name and various abbreviation. The ACLI would then
request the string with the command name and abbreviations
when the GUI starts executing?
8. How would a developer choose command names?
Guidelines for choosing command names would be helpful. Also,
the command names could be reviewed as part of the alpha or beta testing
of the software. Changing the commands would be quite easy
since only the string needs to be changed.
9. Would assigning command names introduce the possibility of bugs
into the GUI code?
Actually, the possibility of introduce bugs into the GUI code
is extremely unlikely. The string is used by the ACLI and not
the GUI. This means that there's little chance of having the GUI
make some wrong decision because of the command name string.
10. Would command name slots make programs much bigger?
This is slightly technical, but in general, the answer is no.
For example, suppose that each button, field, etc in a GUI has a
slot for a string for command names. Let's say that the empty
slot uses only 4 bytes (more bytes if the slot has a string).
If a GUI hase 100 buttones, fields, etc, that would be an increase
of only 400 bytes if none of the slots are filled. In a program
of 2 MB, 400 additional bytes is a very small increase in size.
11. Could the user develop his own abbreviations or aliases for commands.
The ACLI could provide a couple of approaches. One approach
would be for the user to assign command names to macros.
Another related approach could be for the ACLI to let the
user assign commands to hot keys for each application.
12. Why would a developer take the time to specify command names?
Well, basically there is self-interest or a company's interest.
The developer could use the command names to create scripts
for automating testing and debugging via scripts.
Blind users are beginning to put more pressure on ADA Title II and III
entities for access to information via technology. These
entities will start choosing to purchase software which provides
the needed accessibility instead of software which doesn't.
If blind employees start demanding accessible software under
ADA Title I, this will also put more pressure on developers
to build accessible software. Other laws and regulations
would add to the pressure. Using command names is probably the
easiest way to do provide accessibility without introducing the
possibility of bugs.
An additional benefit to using commands names is that it would
make it a little easier to determine how accessible a piece
of software is. A separate program could analyze or monitor a GUI
to see if command names are provided or not.
|
