Appendix A
Initial Listing of Specific Techniques
for Increasing the Accessibility of Application Software
Table of Contents
Character-Based Programs--Writing to the Screen.........
- Use Full-Width Text Wherever Possible..............
- Avoid Use of --- or *****..........................
- Avoid Alphabetic Characters to Draw Pictures, Boxes,
etc................................................
- Provide/Retain Character Mode for Your DOS Software
Graphics-Based Programs--Writing to Screen..............
- Use the System Tools...............................
- Use the Text-Drawing Tools to Erase Text As Well...
- Minimize Use of Painted Text.......................
Cursors, Pointers and Highlighting......................
- Use System Cursors.................................
- Drag the System Cursor With You....................
- Allow the Substitution of Larger or Heavier-Line
Cursors and Pointers...............................
- Carry a Character With You When Moving a Highlight
Down a List........................................
Screen Format and Color.................................
- Use Consistent and Expected Screen Layouts.........
- Use Care When Transmitting Information With Color..
- Provide a Monochrome Option........................
- Make Sure that Warnings, Alerts, and Help Balloons
Are Sufficiently Stable To Be Read Before They
Disappear..........................................
Menus...................................................
- Use the System Tools...............................
- Avoid Non-Text Menu Items (Unless Redundant).......
- Provide Keyboard Access to All Menus...............
- Provide Alternate Mechanisms to Access Commands....
- Direct Access to Palettes and Toolbars.............
- Draw Toolbar Icons Individually....................
Buttons and Dialog Boxes................................
- Give Buttons Logical Names.........................
- Order Buttons in the Dialog Box Definition in a
Logical Screen Order...............................
- Use Standard Relationships Between Buttons and Their
Captions...........................................
- Allow Direct Keyboard Access to All Aspects of the
Dialog.............................................
Sound...................................................
- Provide All Auditory Information in a Visual Format
As Well............................................
- Provide ShowSounds Support for All Sounds..........
- Ensure that Visual Cues Are Noticeable.............
- Provide Captions for Synthetic or Recorded Speech..
Keyboard................................................
- Update System and Keyboard Flags/Lights for Locking
Keys...............................................
- Provide Full Access to All Aspects of the Program
from the Keyboard..................................
- Do Not Interfere with Key Latching and Other
StickyKey Functions................................
Documentation...........................................
Packaging...............................................
General.................................................
- Making All Program Settings Software-Queriable and
Settable...........................................
Appendix A
Initial Listing of Specific Techniques
for Increasing the Accessibility of Application Software
This appendix contains an initial list of specific guidelines. This list is
only a collection of items submitted so far; it is not meant to be
comprehensive. Once this document has been circulated for comment, a more
complete list will be compiled and published. Please consider this list
open-ended: feel free to comment on any item or add as many items as you
wish.
The lists are organized by aspects of software design--menus, cursors,
writing to screen, etc.--rather than by disability. This has been done so
that the significance to design is made more clear.
Character-Based Programs--Writing to the Screen
1) Use Full-Width Text Wherever Possible
Text-based screen readers default to reading left to right.
Text which is positioned in columns is often read as if it were
continuous text; that is, the text in the first column is read,
and then the screen reader jumps to the next column and
continues reading. Many screen readers can be programmed to
deal with text in columns. Where possible, however, continuous
text is easier to deal with.
2) Avoid Use of --- or *****
Where possible, use extended ASCII character graphics rather
than standard ASCII characters (such as "***") for drawing
lines, making boxes, etc. When screen readers hit such text,
they may read it as "asterisk, asterisk, asterisk,"
unnecessarily slowing down the process. A particular nuisance
is text buried in a string of asterisks. In order to read the
text, the individual must sit while the screen reader reads off
the punctuation or other characters. Screen reading programs
can be programmed to skip nonalphabetic characters; however,
this can cause the individual to miss important information on
the screen.
3) Avoid Alphabetic Characters to Draw Pictures, Boxes, etc.
A similar problem appears when alphabetic characters are used
to draw boxes. Using 1's (the digit one) or l's (lower case L)
to draw a vertical line is obvious to somebody looking at the
overall screen. When reading a single line of text using a
screen reader, however, these do not look like a vertical line
but are read aloud as the characters "L" or "One."
4) Provide/Retain Character Mode for Your DOS Software
Software that presents information in a color graphics mode
often uses different strategies to highlight or select text.
Providing an optional character mode in your software greatly 42
facilitates access software, particularly cursor finding.
.a.:Graphics-Based Programs--Writing to Screen
1) Use the System Tools
Wherever possible, applications should use the standard text-
drawing tools included in the system. Most screen access
software programs for graphics-based computers figure out what
is on the screen by watching the use of these tools. Even when
the tools are used to draw characters in other (nonscreen)
locations of memory and then copy the information to the
screen, it is still possible for access software to track its
use. In this fashion, the access software can keep track of
which characters with which attributes appear in each location
on the screen without having to attempt to do optical character
recognition directly on the bit-mapped fonts on the screen.
(Direct OCR of pixel image of the characters on the screen has
been proposed. However, when small point italic characters are
used, they are generally so distorted as to be unrecognizable.
In addition, underlining, shading, outlining, and other
attributes to the text can make it difficult to recognize. As
a result, tracking the use of the text-drawing tools is the
only currently available technique.)
2) Use the Text-Drawing Tools to Erase Text As Well
Occasionally, applications will draw the text characters in a
different portion of memory, and then copy the block of text
onto the screen. As mentioned above, as long as the text-
drawing routines are used, this does not pose a problem.
However, when the applications are done with this text and they
want to re-use the area, they will often directly zero the
space in memory where they were drawing the characters rather
than using the text-drawing tools to erase this area. This
makes it more difficult for the screen reading software to keep
track of which characters are or are not still drawn in that
portion of memory.
3) Minimize Use of Painted Text
Occasionally, applications will use text which has been
predrawn and stored in the program as a bit image. Such
painted text cannot be read by many screen reading routines.
When this text is purely decorative, as on a start-up screen,
it does not pose a problem. If it contains important
information or information necessary to use or understand the
program, it should be created in real time using the text-
drawing tools in order to be accessible by screen reading
programs.
Cursors, Pointers and Highlighting
The problems surrounding cursors and pointers generally fall into two
categories: being able to substitute the cursor/pointer with a larger, fatter
cursor so that it can be seen with poor vision, and being able to
electronically locate the cursor so that the screen reading or enlargement
programs can follow text entry. Eventually, some standard mechanism for
allowing electronic cursor/pointer location may be devised. In the meantime,
the following strategies may be used.
1) Use System Cursors
Whether using text-based or graphics-based screens, using the
system cursors and pointers wherever possible facilitates their
location. Again, most screen reading programs can easily
locate the system cursor and pointer. However, if the
application software creates its own cursor (by highlighting
text, by creating a box, etc.), there is no way for the access
software to easily tell where the cursor is.
2) Drag the System Cursor With You
If the application software does use some special nonsystem
cursor, one strategy is to drag the system cursor along with
the special cursor. In this fashion, the access software can
easily follow the custom cursor. Screen reading software
frequently provides a capability to automatically locate the
system cursor. If the system cursor follows any specialized
cursor, then the blind user will be able to locate both. For
individuals with low vision, the screen enlargement software
will generally follow the cursor automatically, so that as they
type, the enlarged image on the screen tracks the typing.
3) Allow the Substitution of Larger or Heavier-Line Cursors and
Pointers
Some individuals with low vision are able to use computers
without screen enlargement software, either by using the
standard font or a slightly larger font. The text cursor (and
some mouse cursors), however, sometime consists of a single
thin line which easily disappears from the user's view. As the
user enlarges the fonts, the cursor line usually gets taller,
but it does not necessarily get any thicker or easier to see.
If an application is using a system cursor, then there
shouldn't be a problem (since the system should already support
an alternate system cursor which would be heavier and easier
for individuals to see.) If the application software is
providing its own cursors, however, then provision of an
alternate cursor with a heavier line width should be
considered. Alternately, a special control which would make
the cursor stand out in some fashion, to make it easy to
locate, could be provided. Some strategies for making the
cursor easy to locate include:
- Having the cursor momentarily change into some large
dark shape which is easy to locate when a particular
key combination is pressed;
- Providing a larger thick cross-hair which covers some
or all of the screen momentarily while a particular
key combination is pressed.
4) Carry a Character With You When Moving a Highlight Down a List
A common strategy for selecting items from a list is to use the
arrow keys to move a highlighted bar up and down the list. A
highlighted bar is much harder for screen reading software to
detect than is a character. If a small character is also moved
up and down a list (along with the highlight) or in some other
way change the characters on the line that is selected in the
list, it greatly facilitates access by screen reading programs.
Two examples are shown below.
Example 1: Example 2:
Item 1 1 Item
> Item 2 2 Item
Item 3 [3] Item
Item 4 4 Item
Screen Format and Color
1) Use Consistent and Expected Screen Layouts
For individuals who have low vision, consistency of screen
layout is important. As discussed earlier, individuals with
low vision often use screen enlargement software to access the
screen. As a result, they are only able to view a small
portion of the screen, similar to looking down a paper tube.
Similarly, individuals who are blind must use screen reading
software to locate items on the screen, searching one letter or
word at a time. Thus, programs that have a consistent location
for menus, feedback messages, etc., are much easier to use.
Where operating systems specify standard procedures and
locations for things, it is very helpful for application
programs to follow these standards.
2) Use Care When Transmitting Information With Color
For individuals who are color blind, the ability to select the
colors used for all aspects of the screen is helpful. In
general, most displays use light characters on a dark
background or dark characters on a light background. As a
result, they are generally visible no matter what their color
is, simply because of the difference in their intensity.
However, the ability to adjust colors to increase contrast is
helpful for some individuals.
When using color to encode information, using colors having
much different intensities makes the colors easier to
differentiate. A light yellow and a dark green, for example,
could be distinguished even if the screen were displayed in
gray-scale mode because of the difference in their intensity.
3) Provide a Monochrome Option
One mechanism to circumvent problems with color is simply to
provide a monochrome or gray-scale option for the program.
Individuals having difficulty with colors can then use the
program in the monochrome or gray-scale mode.
4) Make Sure that Warnings, Alerts, and Help Balloons Are Sufficiently
Stable To Be Read Before They Disappear
Alert messages that pop up and disappear quickly may be missed
by some individuals, depending on their screen access tools.
To avoid this problem, alert messages should remain on screen
until dismissed by the user.
Some other applications have text which appears when the mouse
cursor touches some point on the screen. If the mouse cursor
moves off of that point, the text disappears. This provides a
particular problem for screen access software, if it moves the
mouse pointer along as it reads the text.
A typical scenario of this problem would occur follows. The
user moves the cursor to a point on the screen, causing the
text to pop up. The user then tries to read the text, but as
the screen reader begins to read the text, it moves the mouse
cursor to move along with the reading. As soon as the cursor
moves to the first word, it has left the original trigger point
on the screen, and the text that the user is trying to read
disappears. At the present time, the balloon help on the
Macintosh suffers from such a problem. A mechanism which would
allow triggered text to be locked on, so that the individual
can move the cursor over the text to read it, would be helpful.
Individuals with learning disabilities may experience similar
problems. For example, there is now a special utility program
on the market which allows people with learning disabilities to
get reading assistance: the user points the mouse cursor at a
word, and the program reads the word aloud. Such a program
would be unable to read words in pop-up messages such as those
described above. As soon as the user moved the cursor to tell
the special utility which word to read, the message would
disappear.
Menus
1) Use the System Tools
As discussed earlier, most access software works by attaching
itself to the operating system. When application software uses
standard system menu tools, access software is able to read the
list of available commands and can provide the individual with
the ability to directly maneuver through and activate the
commands.
2) Avoid Non-Text Menu Items (Unless Redundant)
Menu items that are not text-based and are not accompanied by
text are difficult for screen reading programs to access.
3) Provide Keyboard Access to All Menus
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. 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 the menu items.
4) Provide Alternate Mechanisms to Access Commands
Application programs which provide multiple mechanisms for
accessing commands better accommodate the differing needs of
users. Access via menus and layered dialogs provide easier
access for individuals with lower cognitive abilities. Direct
access with key combinations provides better access for
individuals with physical impairments and for individuals who
are blind.
5) Direct Access to Palettes and Toolbars
As with menus, application programs which provide direct access
to palettes and toolbars greatly facilitate access by
individuals with different disabilities. If the toolbar is
only a shortcut method to accessing items in the menu, and the
menu is accessible, then access to the toolbar would not be
necessary. When the toolbar commands are not available in the
menu, however, direct access might be provided, or the items
might be provided redundantly as an optional menu.
6) Draw Toolbar Icons Individually
Screen access software for individuals who are blind works by
monitoring the operating system's screen drawing routines.
When individual icons are drawn separately, they can be
individually identified, named, and accessed. If a toolbar or
palette is drawn as a single bit image, the individual tools
within that palette are not individually identifiable or
accessible using standard techniques.
Buttons and Dialog Boxes
1) Give Buttons Logical Names
When naming the buttons within a dialog box (whose names do not
appear on the buttons in the dialog definition), be sure that
clear, logical, descriptive names which match the words printed
on the screen near them. Screen reading software accesses
these names in helping the person who is blind to decipher the
information within the dialog box.
2) Order Buttons in the Dialog Box Definition in a Logical Screen Order
In some operating systems, buttons within a dialog box are not
normally accessible directly from the keyboard. Access
utilities exist which allow individuals to tab through the
buttons until they reach the desired button, after which they
can select it from the keyboard. The order in which the tab
moves through the buttons is dependent upon the order in which
the buttons are defined in the dialog. If the button
definitions are not in logical order, the tabbing key will jump
the highlight in what appears to be a random pattern around the
dialog, highlighting the buttons in their definition order.
Although this does not prevent access, it is disorienting.
3) Use Standard Relationships Between Buttons and Their Captions
If the caption is not a part of the button itself, use some
standardized spatial relationship so that the location of a
label for a button (or a button for a label) is predictable for
individuals using screen readers to explore/use a dialog box.
4) Allow Direct Keyboard Access to All Aspects of the Dialog
Again, the best solution is to provide direct keyboard access
to all aspects of the dialog, including buttons, scroll
windows, text entry fields, and pop-up menus.
Sound
1) Provide All Auditory Information in a Visual Format As Well
A general solution which solves the access problems for both
individuals who are hard of hearing and individuals who are
deaf is the provision of all auditory information in a visual
form as well. Auditory warning beeps can be accompanied by a
visual indicator. Beeps and other sounds would described in
text, both to differentiate the sounds and to allow access by
individuals who are deaf-blind (and would be using a braille
screen reading program to access all of the information from
the computer). Speech output (in cases where it is important
for understanding and using the program) can be accompanied by
text on the screen (either as a normal part of the program, or
in a caption box). This presentation of information visually
can be programmed to happen at all times, or can be invoked if
a special operating system flag is set indicating that the user
would like all auditory information presented visually. If the
system software provides a "ShowSounds" switch, the setting of
this switch could then trigger the visual display feature.
2) Provide ShowSounds Support for All Sounds
For beeps or other sounds which are not normally accompanied by
a visual indication, application software should check for a
system "ShowSounds" switch. At the present time, the
"ShowSounds" switch is not a standard feature. In the future,
however, it should be appearing as a standard system switch
which can be accessed by software. Users who are in noisy
environments or who cannot hear well would then be able to set
the "ShowSounds" switch. Application programs could then check
that switch and provide a visual indication to accompany any
auditory sounds.
3) Ensure that Visual Cues Are Noticeable
When providing a visual cue to what would otherwise be an
auditory alert, it is important to ensure that the cue is
sufficient to attract the user's attention when viewed out of
the corner of the eye. An individual who is looking at the
keyboard and typing, for example, is not going to notice a
small icon that appears and disappears momentarily in the
corner of the display. A flickering menu bar or area at the
bottom of the screen will stand a better chance of attracting
attention.
4) Provide Captions for Synthetic or Recorded Speech
As programs incorporate the use of synthetic or recorded
speech, closed captioning should be considered. Again, in
those cases where the information being presented via speech is
already presented in text on the screen, there is no need to
present the information visually in any other fashion. In
those cases where information is being presented via speech
which is not otherwise displayed on the screen, application
programs might check for the "ShowSounds" switch. If the
switch is set, a small box containing the text being spoken
could be displayed on screen. Music or other sounds being
provided for adornment would not have to be presented in
caption form, if they are not important to the operation of the
program. Where the tune or sound is important to the operation
of the program, then some description to that effect could
appear in the caption box.
NOTE: In addition to providing a "ShowSounds" switch as a part
of the operating system, manufacturers of modern operating
systems are also being encouraged to build captioning tools
directly into the operating system to facilitate the
implementation of closed captioning by application programs.
Keyboard
1) Update System and Keyboard Flags/Lights for Locking Keys
Some application programs provide their own on-screen
indication as to whether the CapsLock, ScrollLock, and NumLock
keys have been depressed. In some cases, this feedback is
independent of (and therefore sometimes contradictory to) the
flags in the system or the status of the lights on the
keyboard. This can cause inconsistent feedback to people who
are using access programs which check the status of these
indicators. Applications programs should either use the status
flags in the system and keyboard or update them to agree with
the program.
2) Provide Full Access to All Aspects of the Program from the
Keyboard
Making all aspects of the program, including menus, dialogs,
palettes, etc., accessible from the keyboard significantly
increases accessibility for some users. Although a MouseKeys
feature (which allows the user to use the keypad to drive the
mouse around the screen) could be used to provide access to
toolbars, for example, this is a very slow and ineffective
mechanism. Even if the individual is using MouseKeys for
drawing, rapid access to the tools via the keyboard can greatly
facilitate the use of the application software by individuals
with disabilities (and other users as well).
3) Do Not Interfere with Key Latching and Other StickyKey Functions
One problem faced by individuals with disabilities is the
inability to hold down two keys simultaneously. "StickyKey"
programs which provide electronic latching for the Shift,
Control, Alternate, Option, and Command keys on the different
computer platforms already exist, and are being made available
by operating system manufacturers. As a result, it is not
necessary to build this type of feature into your application
program. In fact, this is an example of an accessibility
feature which is best handled at the system level. Moreover,
implementing it in an application can cause a conflict with and
therefore interfere with the feature in the system software.
Documentation
See discussion in Part IV.
Packaging
Some packaging techniques make it difficult or impossible for
people with manipulation problems to open the package. Where
products are sealed for warranty or virus protection, some
means for easily opening the package should be provided.
General
1) Making All Program Settings Software-Queriable and Settable
In order to facilitate access to programs by individuals using
their access software, it is useful to have all user-settable
parameters both readable and settable via external software.
This might be accomplished in a number of fashions, including
providing an optional menu which could be enabled (since the
access software would already have access to the menus.) This
technique would allow the software both to easily get a list of
the externally available commands and to execute them.
Commands can be provided for reading and for setting
parameters, either directly or via dialogs.
|
.gif){kind=spacer}
