- From: Charles McCathieNevile <charles@w3.org>
- Date: Wed, 19 May 1999 14:07:55 -0400 (EDT)
- To: WAI AU Guidelines <w3c-wai-au@w3.org>
(This is a lynx dump)
BGCOLOR="#000000"
[1]skip navigation links
[2]Home [3]Solutions [4]Partners [5]Resources [6]Events [7]Guidelines
[opened door to accessibility] Software accessibility
Software comes in tremendous variety. There are editors, integrated
development environments, presentation tools, word processors, spread
sheets, notes database applications and web based solutions, to
mention just a few. This document will provide the information that
software developers need to make their software accessible to people
who have disabilities.
Table of Contents:
[8]Overview of accessible software
[9]Principles of accessible software
[10]Checklist for accessible software
[11]References and resources
Overview of accessible software
It is not surprising that most software developers have never stopped
to imagine a blind person using their product. It is inconceivable.
How about a person who has no arms? No way! But these people and many
others with an a tremendous variety of disabilities expect to use this
tremendous variety of software just as their non disabled colleagues
do.
The key to the mystery of how people with severe disabilities could
use a computer application is that they use what is called assistive
technology. As a developer you don't have to worry about making your
application talk, the blind user will have a screen reader, and the
screen reader will do the talking. But, and it is a big 'but,' you do
have to make sure that the screen reader can find the information that
it needs to do the talking. A blind person can't use a mouse, so
you'll need to make sure that anyone can use your software with just
the keyboard. Unplug the mouse and try! There is some work that you
the programmer will have to do to provide access from the keyboard and
to be sure that all the necessary information is available to the
screen reader.
As an application software developer, you don't have to figure out how
a person without arms will provide input to your application. There is
assistive technology that the disabled person can use to provide
keyboard input to your program. Speech input is another choice, and
for that, all program features must be easily accessible from the
keyboard. Keyboard access is essential for blind users, mobility
impaired, and those choosing to use voice input.
Sometimes assistive technology is unnecessary. Did you know that
people with some forms of limited vision may be absolutely incapable
of reading text on the usual black and white screen and yet be able to
read the screen with the colors reversed, or even better, with yellow
letters on a blue background? Such people don't need assistive
technology if they can just change the background and foreground
colors in the software.
Most of the recommendations for accessibility are recommendations for
good user interface design.
Principles of accessible software
These 3 basic principles should be followed when developing software.
Choice of input methods
Support the user's choice of input methods including keyboard,
mouse, voice, and assistive devices via the serial port. The
primary requirement is to provide keyboard access (mouseless
operation) to all features and functions of the software
application. The operating system usually provides support for
input via the serial port, keyboard movement of the mouse
pointer, and other keyboard enhancements.
Choice of output methods
Support the user's choice of output methods including display,
sound, and print. The primary requirement is to provide text
labels for icons, graphics, and user interface elements and to
support visual indications for sounds. Implementing the
accessibility APIs (e.g., [12]Java Accessibility, Microsoft
Active Accessibility, etc.) for the target platform will meet
this principle.
Consistency and flexibility
Make the application consistent with the user's choice of
system behavior, colors, fonts sizes, and keyboard settings.
Provide a user interface that can be customized to accommodate
the user's needs and preferences including fonts, colors , and
display layout.
Checklist for accessible software
Version 1.1 April 15, 1999
This checklist has been updated based on the "[13]Requirements for
Accessible Software Design," Version 1.1, March 6, 1997, published by
the US Department of Education:
http://ocfo.ed.gov/coninfo/clibrary/software.htm.
Follow this checklist to make your software accessible. The best first
step towards providing accessible applications is to use platform
supported tools that promote accessibility.
Guideline
Y/N
N/A
Comments
1.0 Keyboard Access
[INLINE] 1.1
Provide keyboard equivalents for all mouse actions. Make all actions
required or available by the program available from the keyboard. . .
[INLINE] 1.2
Provide logical interaction with interface objects (logical tab order
between buttons, lists, etc.). . .
[INLINE] 1.3
Define accelerator, mnemonics or shortcut keys for tasks that are
frequently performed (e.g., Ctrl+P for print, Escape for cancel). . .
[INLINE] 1.4
Document all keyboard access with the product and/or follow documented
operating system conventions. . .
2.0 Accessibility Features
[INLINE] 2.1
The software shall not interfere with existing accessibility features
built into the operating system (e.g., Sticky Keys, Show Sounds,
Serial Keys) . .
3.0 Object Information
[INLINE] 3.1
Provide a well defined visual focus indicator that moves among
interactive objects as the input focus changes. This focus indication
must be programmatically exposed to assistive technology. . .
[INLINE] 3.2
Provide sufficient information about user objects such that assistive
technology can understand how the objects are used (e.g., the object
is a text box with a label "enter password," or a check box which is
checked). . .
4.0 Icons
[INLINE] 4.1
Assistive technology must be able to associate text with icons. For
example, the program can have text next to the icon, like the desktop
icons in Windows 95 or the program can make text available as text
pop-ups, tool-tips, or bubble help. . .
[INLINE] 4.2
Provide consistent use of icons throughout the application. For
example, if the application uses folders in several places, the folder
icon should be the same for all of them. . .
5.0 Layout
[INLINE] 5.1
Associate labels clearly and/or programmatically with controls or
objects . .
[INLINE] 5.2
Position related objects near each other. . .
6.0 Sounds
[INLINE] 6.1
Provide a visual cue for all audio alerts. . .
[INLINE] 6.2
If 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 and/or in
synchrony with the audio content. . .
[INLINE] 6.3
Allow the user to disable sound and adjust the volume. . .
[INLINE] 6.4
If important information is provided in video format, then the same
information must be provided in an accessible format. For example,
provide a video description for the video. . .
7.0 Display
[INLINE] 7.1
Use system text drawing tools or provide text through an API
(application programming interface) supporting interaction with
assistive technology. The minimum information that must be available
to an assistive technology is text content, text input caret location,
and text attributes. . .
[INLINE] 7.2
Do not use color as the only way to convey information or indicate an
action. The software shall provide another way to display the
information for individuals who cannot identify or distinguish colors.
. .
[INLINE] 7.3
Provide a wide variety of user selectable color and font settings to
better allow for high contrast color schemes, different background
colors, large fonts and different font styles. Inherit and respect
system-wide color settings the user has defined. . .
[INLINE] 7.4
Provide the capability for users to turn off patterned backgrounds
behind text or graphics. . .
8.0 Timing
[INLINE] 8.1
If timed responses or timed instructions are used by the software,
then allow the user to adjust the response time or allow the
instruction to persist. The software should allow the response time to
be at least 5 times the average response time. . .
[INLINE] 8.2
Allow the user to either slow down or disable rapid screen updates or
flashing. For example, avoid seizure-inducing blinking or flashing
rates for text or graphical elements at frequencies between 10-25 Hz.
. .
9.0 Documentation
[INLINE] 9.1
Provide clear and precise documentation on all accessibility features.
. .
[INLINE] 9.2
Provide documentation in an accessible format, such as ASCII text or
HTML. . .
10.0 Verify Accessibility
[INLINE] 10.1
Test the software against this checklist . .
[INLINE] 10.2
Test the software to ensure to ensure all actions are available from
the keyboard. . .
[INLINE] 10.3
Test the software using assistive technologies (e.g., accessibility
test tools, screen readers, screen magnifiers, high contrast schemes,
or show sounds options) and/or include people with disabilities in
beta tests and usability tests of the software. . .
References and resources
"EITACC Desktop Software standards":
Electronic Information Technology Access Advisory (EITACC)
Committee.
[14]trace.wisc.edu/docs/eitacc_desktop_software_standards/deskt
op_software_standards.htm
"Requirements for Accessible Software Design":
US Department of Education, version 1.1 March 6, 1997.
[15]ocfo.ed.gov/coninfo/clibrary/software.htm.
"Java accessibility guidelines and checklist":
IBM Special Needs Systems.
[16]www.austin.ibm.com/sns/accessjava.html. This site contains
detailed guidelines for the Java environment.
"Windows accessibility guidelines":
Microsoft. [17]www.microsoft.com/enable/dev/guidelines.htm.
This site contains detailed guidelines specific to the
Microsoft Windows software environment.
"Web accessibility guidelines and checklist":
IBM Special Needs Systems.
[18]www.austin.ibm.com/sns/accessweb.html. This site contains
detailed guidelines for the Web and HTML.
"Lotus Notes accessibility guidelines":
IBM Special Needs Systems.
[19]www.austin.ibm.com/sns/accessnotes.html. This site contains
detailed guidelines for accessible Lotus Notes applications.
"What is Accessible Software":
James W. Thatcher, Ph.D., IBM, 1997.
[20]www.austin.ibm.com/sns/software.html. The paper discusses
problems encountered by computer user who have disabilities and
what developers can do to make their software accessible.
"Making the GUI Talk":
Richard S. Schwerdtfeger, IBM, 1993.
[21]ftp.software.ibm.com/sns/sr-os2/sr2doc/guitalk.txt. This
paper discusses "Off-Screen Model" technology and GUI Screen
Readers.
"Towards Accessible Human-Computer Interaction":
Eric Bergman, Earl Johnson, Sun Microsytems 1995.
[22]www.sun.com/tech/access/updt.HCI.advance.html. This paper
discusses accessible user interfaces.
[23]Home [24]Solutions [25]Partners [26]Resources [27]Events
[28]Accessibility guidelines [29]IBM Home [30]IBM Legal
[31]Valid HTML 4.0! [32]Bobby approved!
©1998 IBM Corporation
www.austin.ibm.com/sns
References
1. file://localhost/home/charles/gl/accesssoftware.html#navskip
2. file://localhost/home/charles/gl/index.html
3. file://localhost/home/charles/gl/solutions.htm
4. file://localhost/home/charles/gl/partners.htm
5. file://localhost/home/charles/gl/resources.htm
6. file://localhost/home/charles/gl/events.htm
7. file://localhost/home/charles/gl/guidelines.htm
8. file://localhost/home/charles/gl/accesssoftware.html#summary
9. file://localhost/home/charles/gl/accesssoftware.html#principles
10. file://localhost/home/charles/gl/accesssoftware.html#checklist
11. file://localhost/home/charles/gl/accesssoftware.html#references
12. file://localhost/home/charles/gl/accessjava.html
13. http://ocfo.ed.gov/coninfo/clibrary/software.htm
14. http://trace.wisc.edu/docs/eitacc_desktop_software_standards/desktop_software_standards.htm
15. http://ocfo.ed.gov/coninfo/clibrary/software.htm
16. http://www.austin.ibm.com/sns/accessjava.html
17. http://www.microsoft.com/enable/dev/guidelines.htm
18. http://www.austin.ibm.com/sns/accessweb.html
19. http://www.austin.ibm.com/sns/accessnotes.html
20. file://localhost/home/charles/gl/software.html
21. ftp://ftp.software.ibm.com/sns/sr-os2/sr2doc/guitalk.txt
22. http://www.sun.com/tech/access/updt.HCI.advance.html
23. file://localhost/home/charles/gl/index.html
24. file://localhost/home/charles/gl/solutions.htm
25. file://localhost/home/charles/gl/partners.htm
26. file://localhost/home/charles/gl/resources.htm
27. file://localhost/home/charles/gl/events.htm
28. file://localhost/home/charles/gl/guidelines.htm
29. http://www.ibm.com/
30. http://www.ibm.com/legal
31. http://validator.w3.org/
32. http://www.cast.org/bobby
--Charles McCathieNevile mailto:charles@w3.org
phone: +1 617 258 0992 http://www.w3.org/People/Charles
W3C Web Accessibility Initiative http://www.w3.org/WAI
MIT/LCS - 545 Technology sq., Cambridge MA, 02139, USA
Received on Wednesday, 19 May 1999 14:07:58 UTC