There are a few general themes that you'll notice occurring repeatedly in the specific guidelines in the next section. They are worth noting since they provide the rationale for many of the specific guidelines and can be used to help make decisions when options exit for a given design.
Many software based access programs provide their alternate input and display capabilities by tapping into the system software. These access systems depend on the application program using the system tools provided for input and output. Application programs which do not use the system tools may not be accessible to people using special access software or features in the operating system.
For example, alternate input software may take Morse code in and convert it into alternate or "counterfeit" keystrokes which it then puts into the input cue or buffer just as if they came from the keyboard. Application software that takes its keystrokes from the input buffer will find these alternate keystrokes and treat them just like regular keystrokes. If your application program bypasses the input buffer and takes its keystrokes directly from the input hardware, then the alternate keystrokes will not be seen and the person will not be able to use it.
Similarly, screen reading software for people who are blind works by watching the activity of the text drawing routines in the operating system. By watching commands sent to the operating system telling it to draw text on the screen, the screen reading software can keep track of everything that is written to the screen. If application software writes text directly to the screen, then the screen reading software will not know that it is there.
Alternate mouse or pointer routines would also depend on the ability to make system and application software think that a person was moving the mouse when in fact they were operating a mouse simulation program.
Wherever possible follow system standards and style guides. For people with cognitive disabilities it makes it easier to predict and understand how things should operate and what they mean. For people who are blind and use screen readers to find out what is on the screen, predictable layouts and controls are easier to figure out. Also, adaptive software manufactures can build techniques into their software to handle the standard objects and appearances, but not unique or one of a kind implementations. If you do something different, be sure it is accessible (see "Product Testing and Developer Support" at the end of Guidelines - Part I.)
Application programs which provide the ability to access all of the menus by using the keyboard greatly facilitate access by individuals who cannot use the standard mouse. It also makes access easier (or possible) for people with poor eye hand coordination or those who are blind. This access may be provided either by use of the arrow keys to move around through the menu structure, or through use of keyboard equivalents for ALL menu items.
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.
As mentioned above, 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.
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:
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.
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.