The following letter was signed by Judith E. Heumann, and sent out
today to the individuals listed below.
Mr. Paul Edwards
President
American Council of the Blind
1155 15th Street, N.W., Suite
720
Washington, DC 20036
Ms. Kathleen Megivern
Executive Director Association for the Education
and Rehabilitation of the Blind and Visually Impaired
4600 Duke Street
Suite 430
Alexandria, Virginia 22304
Mr. Arthur Matthews, Jr.
Director of Government Affairs
Blinded Veterans Association
477 H Street, N.W.
Washington, DC 20001
Mr. Scott Marshall
Vice President
Governmental Relations
American Foundation for the
Blind
1615 M Street, N.W., Suite 250
Washington, DC 20036
Ms. Judith Moore
President
National Industries for
the Blind
1901 North Beauregard Street
Suite 200
Alexandria, Virginia 22311-1727
Dear [Name appears here]
This is in response to your recent letter addressed to my attention,
jointly signed by representatives of five major national organizations
representing the interests of blind individuals. In this letter, you
expressed deep concern over the Department's use of Lotus Notes as an
application-development tool. As referenced in your letter, serious
problems exist with regard to the accessibility of applications
developed in the Notes environment. I am sending an identical response
to the other four individuals who signed the February 3 letter.
I am sure you are aware that as Assistant Secretary for the Office of
Special Education and Rehabilitative Services (OSERS), I unfortunately
do not have direct responsibility for, or control over, the evaluation
and purchase of computer-related materials used throughout the
Department. However, those of you who know me also know that I
sincerely believe that this lack of direct responsibility does not in
any way recuse me from doing everything I possibly can to mitigate
this serious situation.
Because we currently lack a fully functioning Department- wide
accessibility requirement governing all of our acquisitions, purchases
are still being made from time to time that might not be considered as
meeting basic accessibility criteria. Fortunately, this is changing.
The requirements regarding accessibility in terms of the purchase of
software applications within the Department have been taking positive
shape over a period of recent months. For example, the Department now
has, in the Office of the Chief Information Officer (OCIO), an
assistive technology program which includes a full-time person under
contract who is responsible for providing guidance to the Chief
Information Officer regarding the accessibility of software being
evaluated for purchase or development. Unfortunately, the decision to
purchase Lotus Notes as a developmental tool was made prior to the
more recent decision to adopt a consistent and binding Department-wide
requirement that whenever software is purchased for use throughout the
Department, it must be accessible to ED staff who have sensory or
motor impairments.
I have taken the following steps, which I hope will yield a positive
outcome and hopefully provide a solution that will allow our visually
impaired employees to utilize Lotus Notes in a satisfactory manner:
1. I have asked OSERS Deputy Assistant Secretary Howard Moses, in
conjunction with OCIO, to schedule a meeting with representatives of
the Lotus Development Corporation, in order to make them fully aware
of the difficulties we are having with their software. This meeting
is tentatively scheduled for March 18, and will be attended by Howard
Moses, top-level managers from the OCIO, and Lotus.
2. I have asked the Department's =A7504 Program Implementation Team,
which has responsibility for implementing the recommendations
resulting from our recently completed Department-wide =A7504 self-
evaluation, to clarify ED's position on the acquisition of accessible
software packages. I am pleased to report that as of this writing, the
OCIO, the Office of the General Counsel, and the Grants and Contracts
Services office have approved for inclusion in all future statements
of work, written requirements which set forth very specific criteria
that contractors must meet in their development of software
applications. I have attached a copy of this document, which will go
into effect in the very near future, for your review (the actual
implementation date is presently under discussion).
Regarding your request that I not permit OSERS staff to use
inaccessible applications developed under Notes or other software
packages, I am fully committed to ensuring that every employee with a
sensory impairment has all of the equipment they need to perform their
jobs effectively. I also believe that there are indeed some instances
in which such a prohibition would have a positive effect in making a
statement about what we will and will not accept. In fact, there have
been at least two occasions within the past six months on which I
determined that OSERS would not participate in a given Department-wide
project because of the inaccessibility of the project software. On the
other hand, I don't want to inadvertently create a situation that
could result in further discrimination and non- performance of job
tasks by virtue of a decision not to use a given product.
I will provide each of you with follow-up information that results
from our meeting with the Lotus Development Corporation. Thank you for
ensuring that this matter was brought to my attention. I am optimistic
that we will have a positive outcome to this situation, and appreciate
the support from you and your organizations.
Sincerely,
(signed)
Judith E. Heumann
Attachment
REQUIREMENTS FOR ACCESSIBLE SOFTWARE DESIGN
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.
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