Following is the latest version of the requirements the U.S.
Department of Education will utilize in evaluating future software
purchases.
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: Joe_Tozzi@ed.gov
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.
This archive was generated by hypermail 2b29 : Sun Dec 02 2012 - 01:30:04 PST