2001 Conference Proceedings

Go to previous article 
Go to next article 
Return to 2001 Table of Contents


Crista Earl
American Foundation for the Blind
11 Penn Plaza Suite 300
New York, NY 10001
E-mail: crista@afb.net

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.

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 controls.

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.

Keyboard commands

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.

Explicit information

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 users.

Efficiency features

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 characteristics.

The Tools

When choosing among the wide range of tools available for creating Windows-based applications, a number of factors need to be considered:

Knowing you've Succeeded

  1. In order to be sure your program is accessible, you must Make sure it meets all the criteria under "Characteristics of an Accessible Application."

  2. 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 sufficient.

  3. 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 Proceedings

Reprinted with author(s) permission. Author(s) retain copyright.