2001 Conference Proceedings
Go to previous article
Go to next article
Return to 2001 Table of Contents
CREATING AN ACCESSIBLE APPLICATION USING MAINSTREAM
American Foundation for the Blind
11 Penn Plaza Suite 300
New York, NY 10001
This project has attempted to incorporate principles of
accessible software design into a database application, using
popular tools and techniques. The intent is to provide others who
wish to influence the accessibility of software to have concrete
advice and suggestions to contribute and to understand the
compromises they may find it necessary to make. During the
presentation we will look at specific examples of problems
encountered and solutions developed while designing and
developing both versions of the CTIB software.
The project includes decisions such as:
The application that will be used for our example is the American
Foundation for the Blind's Careers and Technology Information
Bank. Two versions of this have been created, one for internal
AFB use and one for distribution to the public. Features of both
will be used as examples of challenges and solutions in the
design process. Attendees will receive copies of the "public"
version of the software.
- What will the functionality of the program be and what will
the interface be like?
- What are the characteristics of an accessible
- What tools are best for developing my application?
- How will I know that the resulting application is
- To what extent should I consider screen reader features in
determining the accessibility of the application?
- How do I decide where to compromise?
Designing the Application
Often, accessibility is considered late in the design process, if
at all. Users should be involved in the design process from the
beginning. It would be less than efficient to design a program
intended to manipulate statistical data without the participation
of researchers or statisticians. Users with disabilities, and
especially those using assistive technology, need to be sought
and consulted at every point in the process.
Even during the first steps of the design process, deciding on
the functionality the program is to have and the type and level
of user to whom it is directed, it is necessary to consider
accessibility. This is especially true if outside resources are
being used, since the need for and nature of accessibility has to
be communicated to the designers and programmers.
Characteristics of an accessible Application
To allow people who are blind or visually impaired even minimal
use of a software program, the application must be compatible
with screen readers, have keyboard commands for all functions,
and provide information explicitly. It must be flexible enough to
accommodate a variety of access methods and preferences.
Conformity to Programming Conventions
Since many people with disabilities use assistive technology
which interfaces with the application software, the application
must conform to conventions of good programming practices.
Microsoft and others provide guidance on general ways in which to
create "well-behaved" Windows applications.
Compatibility with screen readers
To be accessible to screen reader users, an application must use
controls and text that are readable and usable by screen readers.
Does the program in question use edit boxes, check boxes, menus,
and other controls understandable to a screen reader in all
aspects of the program? If not, screen reader developers or users
must spend hours or months working around the unconventional
The application must use a standard means of displaying focus.
Does the program place a caret in the data-entry field so that
the user can read the current line and hear the correct data? Is
the data displayed in a normal edit box so that the screen reader
can automatically read the data when the user moves to it? Can a
user move to a button in a dialog box by using the Tab key? Does
such a button indicate that it is the "current button" in a
conventional manner? If not, the user must spend time and mental
energy using screen reader mouse functions to find buttons.
Also, an accessible application must not do anything that
interferes with the screen reader. Programs that intercept
keystrokes and do not allow them to be passed on to the screen
reader are nearly impossible to use. Programs that display text
and then "mask" it with another invisible display may fail to
convey essential information.
Accessible software applications must have keyboard commands for
all functions. Can users move from field to field in a data-entry
screen, select text or objects for manipulation, and move items
around by using keyboard commands? Although screen readers
provide mouse simulation, these substitutes are time consuming,
tedious, and require much more skill on the part of the user. It
is rare that a complex program with no keyboard access can be
used efficiently by a visually impaired user.
An accessible application must provide information explicitly. A
good screen reader goes a long way in converting a visual display
into an aural one, but the application must provide the
information for the screen reader to convert. If a bar in a
database gradually changes color as the user moves from the top
of the database to the bottom, sighted users might know when they
are nearing the end of the table, but screen readers can make no
use of this information. A status line with "Record 975 of 1132,"
for example, is much more useful to visually impaired
Database users, for example, must access specific pieces of data
quickly. A customer service representative on the phone with a
customer may need to jump directly to the account balance and
then to the customer's phone number. Separate keystrokes for each
field give more efficient access than the simple ability to Tab
through all fields to the desired item.
Any user may find some of the choices made during the design
process to be unacceptable or less than optimal. Low vision
users, for example, may find the colors hard to see. Users should
be allowed the greatest choice possible in color selection,
position of information, input method, and all other interface
When choosing among the wide range of tools available for
creating Windows-based applications, a number of factors need to
- To what extent are programs resulting from these tools
"naturally" accessible? Are keyboard commands built into programs
or are keyboard commands at least easy for the programmer to
incorporate? Are the controls used in resulting applications
standard? Are resulting applications well-behaved, normal Windows
- How much programmer-intervention will be necessary to get my
program into a usable state? In other words, can I afford to pay
someone to make my program the way I want it using this
- Can the people I'm considering hiring use this tool? Do they
have the skill? Are they familiar with it? If they use assistive
technology, does the tool work well with it?
Knowing you've Succeeded
- In order to be sure your program is accessible, you must Make
sure it meets all the criteria under "Characteristics of an
- Test it with all forms of assistive technology you expect
your users to use. Testers must be knowledgeable in the use of
the assistive technology and similar applications. Simply running
a screen reader and noting that speech is occurring is not
- Test the program with real users. You may have to go out of
your way to be sure that those who use assistive technology are
included. It is likely (nearly certain) that work will need to be
done on the application after each of the above steps. Be sure to
give yourself time. For example, don't schedule the user testing
two weeks before the schedule release date.
Considering Assistive Technology
It would be wonderful if you could compare your creation against
a checklist and know that it was perfectly accessible and usable
by all possible users. Unfortunately, users vary in their skill
level, experience, understanding of concepts, physical and
sensory ability, choice of assistive technology, skill with
assistive technology, and operating system settings, to name a
short list of variables.
If your application is to be used by the public at large, you
must consider the widest array of assistive technology possible.
For example, if you find that your application works well with
product A and very poorly with product B, it is not safe to
assume that users will all use or be willing to switch to product
A. On the other hand, if your program is only to be used within
your organization and only a limited number of adaptive devices
are in use, it may be reasonable to support only those devices.
Go to previous article
Go to next article
Return to 2001 Table of Contents
Return to Table of
Reprinted with author(s) permission. Author(s) retain copyright.