CODI: Cornucopia of Disability Information

What Should Application Software Manufacturers Do?

				   Part V
	     What Should Application Software Manufacturers Do?
			       -- Overview --


Six basic ways for making application software more accessible are:

    1) Using an open systems approach

    2) Cooperation with access utilities and access features in the
       operating system

    3) Designing software to minimize the skills and abilities needed
       to operate it

    4) Providing more accessible documentation and training

    5) Inclusion of access software and hardware in the alpha and beta
       testing stages of product development (to ensure their
       compatibility)

    6) Provision of special customer support lines or specialists
       within your customer support structure who are familiar with
       disability access software and hardware, as well as any
       compatibility issues and solutions for your software

    7) Provision of special developer support lines or contact people
       for third-party manufacturers of access software and hardware


1) Using an Open Systems Approach

Providing access to people who have disabilities is in many ways just a
natural extension of the open systems approach to software design.  Support
of the open systems through GOSIP, POSIX, and the applications portability
profile facilitates compatibility with special access software and hardware
within these environments.  With the rapid advance of technologies and
operating systems, software that is based upon open systems concepts and
which retains a stable or similar interface format across platforms greatly
facilitates the efforts of third-party accessibility developers in keeping up
and adapting their products.


2) Cooperation with Access Utilities and Access Features in the
  Operating System

** Using System Tools and Conventions/Standards

The most important and easiest mechanism for ensuring greater compatibility
with access software is to use the tools and conventions which have been
established for the operating system.  Most access software works through
modifications to the system tools, or bases its operation on assumptions that
the standard conventions for the system will be followed.  As long as
application software programs use the system tools and conventions, there is
generally little problem.  For example, programs that do not use the BIOS or
toolbox to write to screen, that do not use system cursors, that get
keystrokes from the keyboard in unusual or nonstandard fashion, or that write
directly to the screen rather than using standard screen drawing tools can
cause problems for special access software.  Use the system tools for all
screen drawing/writing activities (many screen readers for users who are
blind depend on it, especially in the GUI environment).

** Provide Software Access to Commands

When commands are all executed through the menus, access software has very
little trouble in both accessing listings of the available commands and
activating the commands.  Program commands which are issued in other
fashions--such as tool bars, special palettes, etc.-- present problems.  It
is difficult to get a listing of all of the commands (for example, to present
to somebody who is blind).  It is also difficult to directly activate the
various commands (for example, by an alternate access routine for someone
with a severe physical disability).  Where all of the palette and tool bar
commands are available via the standard menus, this is not a problem.  When
these commands, however, are not otherwise available, it is important that
access somehow be achieved.

Access to commands in a program consists of four parts.  Fortunately, the
movement toward inter-application control is making the commands in a program
more accessible electronically.  Features like balloon help are also useful
for providing descriptions of the commands and buttons on the screen.
Eventually, it would be nice to be able to:

    a) Obtain a listing of all of the possible commands

    b) Obtain help text for each of the commands

    c) Be able to execute all of the commands from an external program

    d) Be able to read the status of user-settable parameters (and be
       able to set all such parameters) from an external program

When these capabilities are all available in a standardized format, it will
make the process of developing access programs much simpler and more
complete.  In the meantime, programs which have most of their commands
available for inter-program control may consider making the rest of the
program commands available as well.


3) Designing Software to Minimize the Skills and Abilities Needed to Operate It

The best way to view people who have disabilities is to think of them simply
as individuals with reduced abilities rather than as people without an
ability.  The reduction in their abilities may vary from slight to severe.
The more you can reduce the sensory, physical, or cognitive skills necessary
to operate the program, the more people will be able to directly use the
program.  It also makes it easier for everyone else to use the program.  Some
examples: using a slightly larger or clearer type, using menus which can be
scanned rather than commands which must be memorized, keeping menus short and
dialog boxes uncluttered, reducing or eliminating the need for fine motor
control.

It is also helpful to provide multiple ways of accomplishing functions in
order to adapt to different needs or weaknesses.  For example, having
pull-down menus reduces the cognitive load and makes it easier to operate
computers.  While providing hot keys reduces the motor load and makes it
easier and faster for individuals with physical disabilities to use
computers, providing both addresses the needs of both groups and gives all
users more options to meet their preferences.  A second example would be the
ability to use either the scroll bar or the keyboard to select position
within a document.

The third general strategy is to provide layering to reduce visual and
cognitive complexity.  One example of this are programs which provide both
short and long forms of their menus.  The use of option buttons in dialog
boxes or other techniques for nesting complexity would be a second example of
this.

4) Providing More Accessible Documentation and Training

** Electronic Documentation

An important component to the accessibility of any software is the ability of
the user to access the documentation.  Documentation can be made available in
a number of formats, including standard print, large print, braille, audio
tape, and electronic form.  The most universal of these is the electronic
format.  In order to be really accessible for people who are blind, the
information should be available as an ASCII text file.  This would involve
converting photographs and diagrams into descriptions, and identifying other
techniques for providing emphasis to particular words other than the use of
different fonts and highlights.  Once a file is available in a pure ASCII
form, it can be easily accessed using screen readers as well as translated
and printed out as braille or recorded in audio tape format.

Although individuals who are blind will find an ASCII text file to be the
most useful form, individuals who have severe physical disabilities may find
that an electronic copy of your manual which also provided pictures and
diagrams will be the most useful form.  The electronic form of the manual
would allow people with physical disabilities to have access that they would
not normally have, because of the difficulty in manipulating books.  Having a
full graphic version of the manual would provide them with the maximum amount
of information.

Someday, when "electronic paper" is common, having the manual in both ASCII
and "electronic paper" would be optimal.  In the meantime, the ASCII version
is the most universally accessible format.


** Print Documentation

Even the design of standard print manuals can be done to better facilitate
their direct use by individuals with visual and other impairments.  Some
things which can be done to improve the accessibility of standard print
documents are:

    -  Using a binding which allows a book to open and lie flat.  (Try
       turning the pages of your documentation using the eraser end of
       a pencil.)

    -  Avoiding the use of very light colors which might not be easily
       reproduced by copy machines, especially for important
       information.  (Individuals with low vision will often make a
       "large print" copy of a manual by running it through an
       enlarging copy machine.)

    -  Avoiding color coding, or making it redundant with pattern or
       some other type of coding.  (This helps avoid problems for
       individuals having color blindness, and facilitates the making
       of large print versions of manuals using enlarging copier
       machines.)

    -  Using a sans serif font for non-running text.

    -  Information that is presented in charts or diagrams should also
       be presented redundantly in text.  (This facilitates the
       scanning of documents into ASCII text files using optical
       character recognition technologies.)

One form of electronic documentation which is becoming increasingly more
prevalent is on-line help.  As long as the help is presented using standard
screen-writing routines, access should be no problem.  If pictures are used
within the on-line help, then text should accompany the picture and provide
enough information that the picture or diagram is a redundant visual aid.

Translating documentation from its standard print form into an ASCII text
file which is effectively formatted can take some effort.  However, there are
programs set up in the United States which can provide technical assistance
in the translation process.  (See Appendix B, Resources Available to Help.)


** Training

In addition to the printed and on-line documentation, many programs have
videotapes or other multi-media training materials available for them.  In
addition, some companies provide training courses, either in the direct use
of their product or for programmers or other professionals wishing to use or
extend their product.

Having access to the training materials for a program can be as or more
important than access to the basic documentation.  As software becomes more
and more complicated, the ability to access and use the training materials
becomes essential.  Videotapes with closed (or open) captions, provision of
equivalent training materials which do not require the ability to see, and
the use of descriptive video (where the actions taking place on the screen
are described as a narrative on a separate audio track) are examples of some
strategies which can be used here.  Providing more accessible training does
not mean that videotapes cannot be used because there are people who are
blind, however.  It could mean that the same information provided in the
videotapes is also available in a form that does not require sight.

In addition to the training materials themselves, it is also important that
training sessions be as accessible as possible.  Some strategies for doing
this include holding the training sessions in facilities which meet ADA
accessibility standards, and may include the provision of interpreting or
other services to meet the needs of specific attenders.


5) Product Testing with Access Software and Hardware

It is difficult to ensure that new application software will not cause
problems for any of the many different types of special access and adaptive
hardware and software.  Often, the only way to tell whether a product or new
features in a product will cause problems is to actually try it out with the
different access products.  As a first pass, companies may have people with
disabilities on site who can test new programs for general usability.
However, there are literally hundreds of different adaptive aids.  As a
result, it is difficult for each application software manufacturer to have
all of the adaptations on-site to try with their new software or new
features.  Two alternate strategies are therefore suggested.

The first strategy is to include individuals from the various adaptive
hardware manufacturers and software developers as a part of the early beta
testing of a product.  This will take a concerted effort on the part of
application software developers, since these adaptive product manufacturers
themselves do not represent a large enough market to normally qualify for
early beta release of application software programs.

A second strategy would be to contract with a third-party testing lab that is
familiar with a) the different types of hardware and software adaptations
available and b) the problems usually encountered by these access products
with application software.  This would involve a financial investment on the
part of the application software developer.  On the other hand, it may
provide for a better mechanism to get a relatively high confidence evaluation
of the compatibility of the application software.  It would also allow
testing with a range of different hardware and software adaptations without
requiring the application manufacturers to release their software to a large
number of different manufacturers.  The early testing of software (pre-beta)
is important, since problems with accessibility are likely to occur at a
level that is difficult to address at the beta stages of an application.  A
major difficulty with this approach is that there are no known testing labs
with the broad cross-sectional base of information that would be needed to
carry out such testing at the present time.

The best approach at this time therefore appears to be involving the
developers of the adaptive hardware and software as early as possible in the
testing of a product or update.


6) Provision of Special Customer Support Lines or Specialists

Another key to having software which is more accessible is the provision of
specialized customer support.  Often, an application program will seem to be
incompatible with various adaptive hardware or software products, when in
fact it will work with them if certain parameters are properly set.  In other
cases, it may be incompatible with one particular adaptation, but be easily
accessed using others.  Such information is important to users who have
disabilities, and generally cannot be obtained by calling the standard
customer support lines.  In fact, a number of companies have built-in
accessibility features in their products which are unknown to their own
customer support teams.

While it would be nice to have all of the customer support personnel fully
aware of all types of disabilities, adaptations, and compatibility issues,
this is unrealistic.  There is simply too much specialized information.  Even
with a specialized hot line, application companies may find that they
identify different individuals with expertise on how to use or adapt their
software for users with different disabilities.

A two-tiered approach to support for users with disabilities is therefore
suggested.  First is the inclusion of basic disability access issues and
information across all of the customer support personnel.  This would include
both a TDD (telecommunication device for the deaf) line and a voice line.  It
would also include an awareness of the efforts by the company to make their
products more accessible, and the existence of the specialized customer
support line.  All customers, including those with disabilities, could then
use the standard support lines to handle standard product use questions.
When specialized questions arose, such as compatibility of the product with
special disability access utilities, the calls could be forwarded to a
disability/technical support team.

The second tier would be the creation of a customer support line specifically
for individuals who have disabilities.  If your company provides an
electronic customer assistance mechanism, a special forum or section for
disability access should also be provided.  The purpose of these mechanisms
would be to provide specialized and in-depth information and support
regarding disability access and compatibility issues or fixes for different
access utilities.

For some small companies, it may be difficult to develop a depth of expertise
in each of the disability areas.  In that case, rather than trying to hire
someone with expertise in the different disability areas as well as expertise
in the technical support aspects, the company might contract with an outside
agency who does have this expertise and give them the training on the
company's software and technical support information.

The existence of the special customer support, as well as the phone numbers,
should be prominently listed in the documentation.  Specific services and
disability access features of products should also be plainly documented in
manuals.


7) Provision of Special Developer Support Lines or Contact People
  for Third-Party Manufacturers of Access Software and Hardware

Another key area in ensuring the accessibility of application software is
support for companies developing disability access software.  Again, these
companies are usually small enough that they do not qualify for the types of
support generally provided to other, larger developers and operating system
manufacturers.  As a result, it is often difficult or impossible for them to
qualify for access to technical support in the same manner as other larger
third-party manufacturers.  In addition, the types of problems they have
sometimes differ.  It is often therefore helpful to have individuals within
the technical support team who specialize in these issues, and who can work
with developers to both a) identify strategies for those developers to
effectively access your application, and b) identify ways in which your
application or future editions of it can be made more user-friendly.

This latter point is essential in the development of new versions of
application programs.  As mentioned above, discovering an incompatibility
with access software at the beta testing stage is too late.  Typically, the
types of inconsistencies that occur with access software occur at a rather
fundamental architectural or structural level in the application.  Thus, it
is usually too late by the time the beta test occurs to do anything about
accessibility problems.  On the other hand, software is usually not available
for testing until it is substantially completed.  Ensuring the future
accessibility of software products is therefore highly dependent upon
interchange and communication between the software development team at the
application manufacturer and the third-party access product developers.
Through this interaction, as well as through documents such as this,
application software developers can begin to identify the kinds of things
that do or might cause accessibility problems.  They can then get in contact
with the third-party assistive device manufacturers and explore ways to
circumvent these problems.