This is from the Department of Education web site
([log in to unmask]" target="_blank">http:[log in to unmask] <[log in to unmask]" target="_blank">http:[log in to unmask]> )  It might be a
good set of guidelines for museum exhibit software too.

Linda Wilson
Visitor Studies and Evaluation
Shedd Aquarium, Chicago, IL 60605
PH (312) 692 3261
Fax (312) 939 8677
[log in to unmask] <mailto:[log in to unmask]>



REQUIREMENTS FOR ACCESSIBLE SOFTWARE DESIGN
Version 1.1
March 6, 1997
Purpose
The Department of Education considers universal accessibility to information
a priority for all employees and external customers, including individuals
with disabilities. The Department has established these Requirements for
Accessible Software Design in order to support its obligation, under
Sections 504 and 508 of the Rehabilitation Act of 1973, 29 U.S.C. ''794 and
794d, as amended, to ensure the accessibility of its programs and activities
to individuals with disabilities, specifically its obligation to acquire
accessible electronic and information technology. Therefore, when selecting
computer hardware and software applications for use within the Department's
computing environment, the Department will evaluate the hardware and
software to determine its accessibility by users with disabilities.
The purpose of this document is to convey the accessibility needs of the
Department to the developers and suppliers of computer applications. It
addresses the minimum accessibility requirements software applications must
meet in order to be used by all Department employees and customers. These
requirements are offered to demonstrate the accessibility needs that must be
considered when designing and developing software for the Department of
Education. They address proven techniques for the design of universally
accessible software that can be used by individuals with or without a
disability. Software considered for use by the Department must execute in
the standard operating environment at the time of offering and be compatible
with the accessibility tools, both hardware and software, in use by
individuals with disabilities at the Department.
While a product that meets these requirements ensures minimum accessibility
for individuals with disabilities, the Department of Education encourages
software and technology developers to be creative and maximize their design
of software that is universally accessible. More specific recommendations
for how to design universally accessible software can be obtained from the
Assistive Technology Team in the Office of the Chief Information Officer
(OCIO) Technology Center, (202) 708-7298 (voice), (202) 401-8510 (TTY),
Internet: [log in to unmask]
Functional Specifications
Keyboard Access
1. The software program must provide keyboard access to all functions of the
application. All actions required or available by the program must be
available with keystrokes. (i.e., keyboard equivalents for all mouse actions
including ,but not limited to, buttons, scroll windows, text entry fields
and pop-up menus.)
2. Clear and precise instructions for the use of all keyboard functions
shall be provided as part of the user documentation.
3. The software must have a logical tabbing order among fields, text boxes
and focal points.
4. The focus must follow the keystroke. (E.g., using the arrow keys to
navigate through a list followed by pressing the ENTER key or spacebar to
select the desired item.
5. The software shall not interfere with existing accessibility features
built into the operating system. (Such as Sticky keys, Slow Keys, Repeat
Keys in Microsoft Windows 95.)
6. Avoid using timed responses if possible. If used, the ability to modify
the timing parameter, by individual user, is necessary.
7. Selectable visual and auditory indication of key status for the Number
Lock, Shift/Caps Lock, and Scroll Lock keys.
Icons
1. All icons shall have clear precise text labels included on the focus or
provide a user-selected option of text-only buttons.
2. The use of icons shall be consistent throughout the application.
3. Provide pull-down menu equivalents for Icon functions (menu, tool and
format bar).
4. Provide keyboard access to all pull-down menus.
5. Painted text is not accessible to all users. Use system text drawing
tools so that screen reader software can interpret the text.
Sounds
1. Provide a visual cue for all audio alerts.
2. Support the Sounds feature where built into the operating system. (Such
as Microsoft Windows 95 show sounds feature.)
3.      Allow the user to disable or adjust sound volume.
4.      Wherever and whenever information is presented in audio format it
shall be capable of being displayed by the user in text format, either as
closed captioning, a pop-up window, or other means, in parallel with the
audio information.
Display
1. Do not use Color-coding as the only means of conveying information or
indicating an action. Always provide an alternative or parallel method that
can be used by individuals who do not possess the ability to identify
colors.
2. The application must support user defined color settings system-wide.
Highlighting should also be viewable with inverted colors.
3. Do not use patterned backgrounds behind text or important graphics.
4. Individual user override of application default fonts for printing and
text displays are required.
5. Allow user adjustment of, or allow user to disable flashing, rotating or
moving displays to the extent that it does not interfere with the purpose of
the application.
Field Labeling
1. Position the descriptions or labels for data fields immediately next to
the field, so that it is easy for screen reading software, used by
individuals that are blind, to associate the labels with the corresponding
fields. The preferred position would be flush against the left side of the
field with a colon:
Documentation
1.      Provide all manuals and documentation in electronic format as an
ASCII text file. This should include including text descriptions of any
charts and/or graphs or pictures or graphics of any nature. This is done to
ensure that the information presented in charts or graphs is available to
screen readers and/or in Braille versions of the text.
2. Any reports that the application generates must be available in a "print
to ASCII file" format.
Common Accessibility Aids
The Department of Education commonly uses, but is not limited to the
following assistive technology aids:
* Artic Technologies Win Vision Screen Reading Software.
* AiSquared Zoom Text for Windows.
* Dragon Systems, Inc. DragonDictate Voice Recognition Software.
* Productivity Plus Word Prediction Software.
This document is available in alternate formats upon request by contacting
the Technology Center. 202-401-0028.