CODI: Cornucopia of Disability Information

Initial Listing of Specific Techniques for Increasing the Accessibility of Application Software

				 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,
     - 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
     - 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
     - Allow Direct Keyboard Access to All Aspects of the
     - 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..
     - Update System and Keyboard Flags/Lights for Locking
     - Provide Full Access to All Aspects of the Program
       from the Keyboard..................................
     - Do Not Interfere with Key Latching and Other
       StickyKey Functions................................
     - Making All Program Settings Software-Queriable and

                              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

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

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

       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


  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

  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.


  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

  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.


  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

       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.


       See discussion in Part IV.


       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.


  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.