I'm forwarding this message from Greg Lowney of
Microsoft. He would like reviews by Friday May 12, 1995.
(published with permission)
From: Gregory C. Lowney, Microsoft Corp.
To: List
Date: 5/8/95
Subject: Draft accessibility guidelines
Please review the following document and let me know any suggestions,
complaints or (if a miracle occurs) positive comments by Friday,
May 12.
This document should not be confused with the separate document that
I sent around for review during late 1994; that one was a chapter of
The Windows Interface Software Design Guidelines (known as the
user interface style guide). This document is a chapter of the
Programmer's Guide to Microsoft Windows 95 (known as the programmer's
guide) and will also be made available as a stand-alone whitepaper.
The first document is a subset of this document concentrating on
user interface design, and was written by another author based on
earlier drafts of this document you have just received.
We really do want any feedback; the earlier they are received the
better the chance that we can get them incorporated. We would
also like comments on the overall style, approach, and expected
effectiveness of this document.
This zipfile contains two copies of the document, one in Word for
Windows 6.0 format and the other a straight ASCII text file that
was created from the former.
Please send any comments to me directly or, if you're on the
internet, to enable@microsoft.com.
Thanks very much for your help in this project.
Greg Lowney
Senior Program Manager
Accessibility and Disabilities Group
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
voice: 206-936-8510
tt/tdd: 206-936-2627
fax: 206-936-7329
internet: greglo@microsoft.com (preferred)
compuserve: 70714,1542 (binary files only please)
Designing Accessible Applications
Considerations in the design of applications for the Microsoft(R)
Windows(R) operating system in order to make them more accessible
to individuals who have disabilities or who are aging.
Microsoft Corporation
Draft Version 15 May 8, 1995
Draft
Table of Contents
1. Introduction 1
1.1. Overview 1
1.2. Using this document 1
2. Summary of guidelines 2
3. Background 4
3.1. Why you should care about accessibility 4
3.2. What are disabilities? 4
Visual Impairments 5
Hearing Impairments 5
Movement Impairments 5
Cognitive and Language Impairments 5
Seizure Disorders 5
Speech Impairments 5
3.3. What is Accessibility? 5
3.4. Types of accessibility aids 6
Screen enlargement utilities 6
Screen review utilities 6
Voice input utilities 6
On-screen keyboards 7
Keyboard filters 7
3.5. Designing accessible applications 7
4. Keyboard access 7
4.1. Choose a familiar keyboard interface 7
4.1.1. Example: Commands through menus and dialog boxes 7
4.1.2. Example: Manipulating objects with property sheets 8
4.1.3. Example: Navigating through objects with TAB 8
4.1.4. Example: Moving between panes and windows with F6 8
4.2. Providing keyboard accelerators 8
4.3. Using logical keyboard order 9
4.4. Document your keyboard interface 9
4.5. How much is enough? 9
4.6. Support the Keyboard Preference flag 9
5. Indicating the user's point of focus 10
5.1. Indicate focus by moving the system caret 10
5.2. What is the focus? 10
5.2.1. Example: Focus as a text insertion bar 10
5.2.2. Example: Focus on a graphic object 11
5.2.3. Example: Focus location in extended selection 11
5.2.4. Example: Focus location in discontiguous selection 11
5.2.5. Example: Focus among custom controls 11
5.2.6. Example: Focus location in a spreadsheet 11
6. Controls and Menus 11
6.1. Standard controls 12
6.2. Owner-draw controls 12
6.3. Subclassed standard controls 12
6.4. Custom controls 13
6.5. OLE Controls 13
6.6. Owner-draw menus 13
6.7. Use appropriate controls for displaying values 14
7. Drawing Techniques 14
7.1. Draw with the standard Windows API 15
7.2. Avoid using bitmapped text 15
7.3. Avoid directly manipulating pixels or bitmap bits 15
7.4. Identifying separate screen areas 16
8. Identifying Windows 16
8.1. Identifying windows for the end user 16
8.2. Identifying windows for accessibility aids 16
9. Timings and Navigational Interfaces 17
9.1. Avoid having messages time out 17
9.2. Don't trigger events by pointer location 17
9.3. Don't trigger events by focus location 17
10. Color 18
10.1. The importance of customizability 18
10.2. Don't convey information by color alone 18
10.3. Use standard system colors where appropriate 18
10.4. Use colors in proper combination 19
10.5. Make custom colors customizable 19
10.6. Coloring graphic objects 19
10.7. Prevent backgrounds from obscuring text 20
10.8. High Contrast Mode 20
11. Size 21
11.1. Selectable font sizes are user-friendly 21
11.2. Provide alternatives to WYSIWYG 21
11.2.1. Draft mode 21
11.2.2. Zoom features 22
11.3. Scaling non-document regions 22
11.4. Be compatible with system size metrics 22
11.5. How wide is a line? 22
11.6. Be compatible with global scaling 22
11.7. Adjust images for different sizes 23
11.7.1. Alternatives to bitmaps 23
11.7.2. Accommodating bitmaps when changing size 23
12. Sound 23
12.1. Support the ShowSounds flag 24
12.1.1. Example: New mail arriving 24
12.1.2. Example: Beeping on bad input 24
12.1.3. Example: Playing a video clip 24
12.2. Allow the user to turn off sounds 25
13. Layout 25
13.1. Attach textual labels to all controls and graphic objects 25
13.2. Labeling icons 25
13.3. Label controls clearly 25
13.4. Position related items near each other 26
13.5. Use consistent and expected screen layouts 26
13.6. Don't tune to a specific font 26
14. Making sure your product is really usable 26
14.1. Test for compatibility with accessibility aids 26
14.2. Include accessibility sites in beta tests 27
14.3. Include people with disabilities in usability testing 27
14.4. Test against the accessibility guidelines 27
14.5. Try it! 27
Appendix A. Additional Resources 28
A.1. General Resources 28
A.2. Additional accessibility guidelines 28
A.3. Customizing Windows or Windows NT 28
Appendix B: Documentation, packaging and support 30
B.1. Provide documentation in alternative formats 30
B.2. Bind documents to lie flat 30
B.3. Don't convey information by color and graphics alone 30
B.4. Make packaging easy to open 31
B.5. Provide customer support via text telephone and modem 31
Appendix C: Windows 3.x Considerations 32
C.1. Colors in on-line help 32
C.2. Testing accessibility flags 32
1. Introduction
1.1. Overview
Personal computers are powerful tools that enable people to work,
create, and communicate in ways that might otherwise be difficult or
impossible. The vision of making computers easier to use for everyone
can be realized only if people with disabilities have equal access to
the powerful world of personal computing.
The issue of computer accessibility in the home and workplace for people
with disabilities is becoming increasingly important. Seven to nine out
of every ten major corporations employ people with disabilities who may
need to use computers as part of their jobs. In the U.S. alone, an
estimated 30+ million people have disabilities that can be affected by
the design of computer software.. Additionally, as the population ages,
more people experience functional limitations, causing the issue of
computer accessibility to become important to the population as a whole.
Legislation, such as the Americans with Disabilities Act (which affects
private businesses with more than 15 employees) and Section 508 of the
Rehabilitation Act (which addresses government spending), also brings
accessibility issues to the forefront in both the public and private
sectors. Accessibility is also being incorporated into official and
international standards for usability such as ANSI 200.
Microsoft Windows 95 incorporates many new features and enhancements
designed to make the operating system more accessible to people with
disabilities, but applications also need to follow accessible design
practices in order to make computing in the home, schools and workplace
accessible to everyone.
This document is designed to answer questions about computer
accessibility for people with disabilities and the design and production
of computer software that accommodates users with disabilities.
1.2. Using this document
This document provides the following areas:
1. A quick checklist of recommended accessibility features and
programming techniques
2. Background information on disabilities and accessibility aids
3. Detailed descriptions of features and programming techniques that
make applications more accessible or be compatible with
accessibility aids
4. A list of additional resources, including further readings,
accessibility aids and their manufacturers
The guidelines discussed are all just that, guidelines, rather than hard
and fast rules. However, we strongly urge you to adapt or adopt as many
as you can to your own applications, or find additional ways to achieve
the same goals.
Product designers often start by asking which of these guidelines are
the most important, but instead we encourage you to make this
determination yourself based on the current state of your own
application. First, determine which of these areas your application is
already handling correctly and which remain as problems. Second,
determine which of the problems you can address in the version of your
product currently under development. Third, when you begin working on
the next version of your product, design in corrections to the remaining
problems. In this way you can make a considerable difference in the
near term and demonstrate your desire to "do the right thing" in the
long term.
2. Summary of guidelines
The following is a checklist summary of the guidelines for accessible
software design. For detailed explanations of the individual
recommendations, see the later sections of this document.
Keyboard
* Provide keyboard access to all features.
* When possible, model your keyboard interface on a familiar
application or control.
* Provide keyboard accelerators for all controls and menu commands.
* Use logical keyboard navigation order.
* Fully document your keyboard user interface.
* If you normally hide some keyboard user interface, display it
when the Keyboard Preference flag is set.
Visual Focus
* If you draw the keyboard or visual focus indicator, move the
system caret invisibly to track that location.
Controls and Menus
* Use standard controls where possible
* If you use owner-draw controls, define correct text labels even
when they won't be visible.
* If you use subclassed controls, include the original class name.
* If you use custom controls, make the OLE Controls.
* If you use custom controls that aren't OLE controls, identify
them using invisible text.
* If you use owner-draw menus, provide a textual alternative.
* Display text using the appropriate edit, read-only edit, status
or static text controls.
Drawing Techniques
* Draw text with standard text output GDI functions such as
ExtTextOut.
* If you use DCI or WinG or in other ways bypass GDI drawing
functions, provide an option to revert to standard behavior.
* If using bitmapped text, draw the name over it invisibly when a
screen review utility is present.
* Clear text and graphics using standard GDI functions such as
PatBlt rather than modifying memory directly.
Windows
* If you display a single image representing several objects,
identify the separate areas using ToolTips or by drawing
invisibly.
* Provide user-friendly titles for all windows, even if the title
is not visible.
* Give functionally unique windows unique window classes.
Timings and Navigational Interfaces
* If you have messages that time out, allow the user to turn off
that time out behavior.
* Don't trigger actions or messages by cursor location.
* Don't trigger actions or messages by focus location.
Color
* When screen elements correspond with standard elements, use the
system colors chosen in Control Panel.
* When screen elements don't correspond with elements in Control
Panel, allow the user to customize those colors.
* Make sure graphic objects are drawn to contrast with the current
background color.
* If displaying complex backgrounds behind text or objects, allow
the user to select a plain background.
* If you use private colors or complex backgrounds, omit them when
the High Contrast flag is set.
Size
* Allow the user to select font sizes for displayed information.
* If feasible, provide a zoom feature.
* Draw objects using the sizes (screen metrics) selected in Control
Panel.
* If you draw lines, determine the proper width rather than using a
fixed value.
* Make sure you test with display scaling ratios using the Custom
Font Size feature.
Sound
* If you provide information by sound alone, present it visually
when the ShowSounds flag is set.
* If you generate sounds, provide a way to turn them off.
Layout
* Follow guidelines for unambiguously attaching text labels to
controls.
* Attach labels to icons where possible, or label with ToolTips.
* Attempt to clearly label controls without relying heavily on
context
* Use consistent screen layouts follow the Windows UI guidelines.
* Use logical keyboard navigation order.
* Avoid tuning to a specific font.
Verification
* Test for compatibility with common accessibility aids.
* Include people with disabilities and software vendors in your
beta tests.
* Include people with disabilities in your usability tests.
* Determine where your application does or does not follow these
guidelines.
3. Background
3.1. Why you should care about accessibility
There are many reasons why accessibility should be included as part of
your application development process.
* Potential market. There are approximately 49 million people with
disabilities in the United States alone, of whom 30-35 million can
be directly affected by the accessibility of computer software.
If you consider the international market the numbers are much
higher.
* When you build accessible applications you are not just targeting
people with disabilities, but also their family and friends, their
coworkers and their employers. Large organizations today employ
people with disabilities and expect their mainstream computer
applications to accommodate all members of their staff.
* Legislation requires employers to make reasonable accommodation
for employees with disabilities. The Americans with Disabilities
Act affects all employers with 15 or more employees, and section
508 of the Rehabilitation Act affects the federal government and
organizations that receive government funding.
* Accessibility is being incorporated into upcoming standards for
usability such as ANSI 200.
* Many people, including your own employees, will develop permanent
or temporary disabilities. Repetitive stress injury caused by
typing or using a mouse is increasingly common in the computer
industry, and as a person ages they are very likely to go through
periods with disabilities.
* Accessible design actually improves usability for everyone, not
just people with disabilities. It also assists in automating
tasks and test automation, and makes your application compatible
with future interface technologies such as voice recognition.
And of course, many people believe that accessibility is simply the
right thing to do in order to allow each individual to make their
maximum contribution to society.
3.2. What are disabilities?
Individuals are not disabled--rather, some people have difficulties
performing certain tasks, such as using a mouse or reading small print.
When these difficulties are serious enough to impact the person's
performance, they are referred to as "disabilities." Disabilities can
be divided into the following general categories:
* Visual Impairments
* Hearing Impairments
* Movement Impairments
* Cognitive or Language Impairments
* Seizure Disorders
* Speech Impairments
These categories describe groups of disabilities covering a broad range
of people with widely different levels of needs.
Visual Impairments
Visual impairments range from slightly reduced visual acuity to total
blindness. Millions of people have vision that's only slightly
impaired, making it difficult to read small print or black text on a
gray background, or just having eyestrain at the end of long computing
sessions--such individuals usually don't consider themselves to have a
disability. If the person's vision can't be corrected to better than
20/80, then they are described as having low vision, they probably
require text to be larger than normal, and they often require especially
high contrast between foreground text and the background. A person is
described as being blind when their vision can't be corrected better
than 20/200, and they usually require output to be translated into
spoken text or Braille. Other types of impairments include reduced
field of vision allowing them to focus only on a small area at time, and
color blindness, a condition affecting up to 1 male in 10 which makes it
difficult or impossible to distinguish certain color combinations.
Hearing Impairments
Some individuals cannot notice beeps or recognize spoken words. These
users may require a program to prompt them in a different manner, such
as a screen flash or displaying spoken messages as text. Keep in mind
that any person can find themselves in this situation when they're
working in a very noisy environment, or working in a quiet environment
such as a library where they've been requested to turn off the sound, or
working on a machine with broken or missing speakers.
Movement Impairments
Some users may be unable to perform certain manual tasks. These can
range from difficulty using a mouse to the inability to type two keys at
the same time. Other individuals may have a tendency to hit multiple
keys, or "bounce" fingers off keys, or be unable to hold a printed book.
Many individuals require keyboards and mouse functions to be adapted to
their requirements, or rely exclusively on a single input device.
Cognitive and Language Impairments
Cognitive impairments take many forms, including short- and long-term
memory impairments, perceptual differences, and severe conditions such
as Downs Syndrome. Language impairments are very common, including
people with forms of dyslexia that affect reading or spelling,
illiteracy, or even people learning as a second language the language
used by their computer software. Proper software design can help
increase the number of people with mild cognitive and language
impairments who can use computers.
Seizure Disorders
People with some forms of epilepsy and similar disorders may experience
minor or severe seizures when exposed to visual signals flashing at
certain rates, or certain types of random or repetitive sounds.
Speech Impairments
Difficulty speaking does not often affect one's ability to use a
computer today, but it is a problem in using telecommunications and
voice menus, and in the future it may affect normal computer usage if
voice recognition becomes a common form of input.
3.3. What is Accessibility?
Accessibility means designing computer software to accommodate a wide
range of users, including users with disabilities. Nothing is
accessible to everyone, but a few simple steps can greatly reduce the
number of people who are barred from using your application.
Special needs can be addressed in several ways:
* New features that are built into hardware and operating systems
that help make them accessible to users with and without
specialized needs. This solution is preferred because the features
are available on all workstations and can be used with all well-
behaved applications.
* Accessibility aids, utilities that modify the system to help make
it more usable by more people. Like the first category, these work
with all well-behaved applications, but they aren't available when
the user moves to a new machine and many people who could benefit
from them will never obtain them.
* Specialized applications, such as a word processor designed to
integrate voice and text to help individuals with limited reading
and writing skills. There are a few of these available, but in
general people with disabilities have to rely on mainstream
applications the same way their coworkers do.
* Usability features that can be built into mainstream applications,
making them easier to use for people with disabilities. Examples
include customizable colors and keyboard accelerators, and as
these examples show, often these features also benefit people who
don't have disabilities. In addition, mainstream applications can
take steps to ensure that they are compatible with accessibility
aids.
3.4. Types of accessibility aids
These are brief descriptions of some of the more common types of
accessibility aids--utilities added to the system to make it more
accessible to people with some types of disabilities. Not all people
with disabilities use tools like these, but being familiar with them and
how they work can help you to design and build applications that work
with them, instead of shutting out those customers.
Screen enlargement utilities
Screen enlargers (also called screen magnifiers or large print programs)
are products which allow the user to magnify a portion of their screen,
effectively turning the computer monitor into a window showing a portion
of an enlarged virtual display. The user can use the mouse or keyboard
commands to move this window to view different areas of the virtual
display. Enlargers also need to track where the user is working so they
can automatically keep the active area in view.
Screen review utilities
People who are blind use the computer with the aid of a screen review
utility (also called a blind access utility or a screen reader). Screen
review utilities take the information displayed visually on the screen
and make it available through alternative, non-visual media, such as
synthesized speech or a refreshable Braille display. Since both of
those media present only text, not graphics, the utility needs to render
screen elements as text, such as by assigning a user-friendly name to
each graphic object. They also need to track what the user is doing and
the location of the focus in order to be able to describe the important
aspects of what is happening on the screen. In Windows and other
graphical environments these utilities work by watching all operations
that draw information to the screen. They then build up an "off-screen
model", a database of the objects on the screen, their properties and
spatial relationships. Some information will automatically be read to
the user when it changes on the screen, and other information will be
found when the user requests it. Screen review utilities often accept
configuration files (also called set files or profiles) which tell them
how to work correctly with particular applications.
Voice input utilities
People with severe mobility impairments will often use a voice input
utility (also called speech recognition programs) in order to control
the computer with their voice instead of the mouse and keyboard. These
utilities are increasingly being used to boost productivity of people
who do not have disabilities. Like screen review utilities, voice input
systems try to identify objects on the screen which can be manipulated
and determine appropriate names for them, thus allowing the user to
activate an object with a single phrase. They also need to be able to
manipulate controls programmatically, and be aware of what the user is
doing and the changes that result.
On-screen keyboards
Some individuals with motion impairments cannot use a standard keyboard,
but they may be able to control a switch or a pointing device. An on-
screen keyboard is a program which displays a list of commands to the
user and allows them to choose and execute these commands using a
variety of input methods. A common use of this technique is to display
a picture of a keyboard, and allow the user to point and click on keys
to type into the system. Variations include Morse-code input systems
and single- or double-switch systems. Using a single-switch system, for
example, the on-screen keyboard would successively highlight groups of
commands until the user selected one group by pressing the switch. The
utility would then successively highlight smaller groups of commands
within that selected group, and so forth until the user selected the
specific command to execute. As another example, a person using a head-
pointer may be able to point but not click, so they could activate a
command simply by pausing the pointer over it for a certain amount of
time.
Keyboard filters
There are many ways in which impaired movement may make it difficult,
but not impossible, to use a standard keyboard. There are features
built into Windows 95 to compensate for erratic motion, tremors, slow
response time and similar disabilities. However, in most cases it isn't
possible to apply the same corrections to pointing devices such as the
mouse, so these users are restricted to keyboard input. Other types of
keyboard filters include typing aids such as word prediction and
abbreviation expansion utilities, and add-on spelling checkers.
3.5. Designing accessible applications
The remainder of this document describes specific considerations that
can be used when designing a mainstream application in order to make it
usable by individuals with disabilities. They fall into two categories:
end-user features that make the product more usable, and programming
techniques that make the product compatible with accessibility aids.
These design guidelines expand on the checklist provided earlier in this
document.
4. Keyboard access
It is important to design your application so that a mouse is not
required for its use.
Providing a good keyboard interface is one of the most important, and
most visible aspects of software accessibility. It is important because
it affects users with a wide range of disabilities. For example, a
keyboard interface may be the only option for users who are blind or use
voice input or keyboard macro utilities, as well as those who cannot use
a mouse. (The Accessibility Options in Windows 95 can often compensate
for users who have difficulty using the keyboard, but it is more
difficult to compensate for problems relating to mice and other pointing
devices. Similarly, while Windows provides the ability to move the
mouse pointer using the keyboard, this is not usable by everyone and is
extremely cumbersome at best.)
In addition, many experienced typists prefer to avoid taking their hands
off the keyboard to use a mouse, pointing devices can be inconvenient on
many laptop systems, and anyone can find themselves on a system without
a working mouse.
4.1. Choose a familiar keyboard interface
The key in defining a good keyboard interface is to adapt models already
familiar to the user, meaning that it should be keystroke-compatible
with a familiar application or control.
4.1.1. Example: Commands through menus and dialog boxes
Menus are one of the most common and standardized user interface
elements, and can be used by the keyboard. Putting commands on the menu
is always a safe option, but it may make the menus large and unwieldy.
In those cases you can provide a default configuration that hides most
of these options, and only show them when the user explicitly requests
them through your own option or by setting the Keyboard Preference flag
(discussed below).
It is usually possible to provide dialog boxes or property sheets that
provide access to functionality normally used by the mouse.
4.1.2. Example: Manipulating objects with property sheets
One alternative to direct manipulation is shown by the Microsoft Visual
Basic(R) programming system, which lets the user directly manipulate
controls but also allows the user to adjust their location and size
through the object's property sheet.
Another model for moving and sizing is that used for manipulating
windows. Most windows have Move... and Size... commands on their system
menu which let the user perform these operations with the keyboard, and
the same commands with the same user interface could be provided for
application-specific objects, on the normal menu bar and on the object's
context menu.
4.1.3. Example: Navigating through objects with TAB
Another commonly used model is that used by Windows Help. Windows Help
allows the user to press TAB to move the focus through a list of "hot
spots" or active regions, and press ENTER to choose the currently
selected active region. SHIFT+TAB is also used to move backwards
through the list, and arrow keys to move in specific directions
(especially useful if the items are arranged in two dimensions). The
application can also allow the user to type one or more letters to move
to the next active region whose label starts with those letters, just as
one moves through entries in a standard list-box.
4.1.4. Example: Moving between panes and windows with F6
Two other models that can be useful are panes and child Multiple
Document Interface (MDI) child-windows. Some applications divide their
window into two or more panes, separate areas showing different
information which can be switched between using a simple keystroke. For
example, the Windows Explorer can display a single window with three
panes. TAB or SHIFT+TAB move the focus between the Tree pane, the
Directory pane and the Drive Bar, and the arrow keys move around within
a pane. MDI follows another convention by using F6 and CTRL+F6 to move
focus between panes and child windows, and also presents a list of these
windows and allows the user to move between them using the Windows menu.
Some applications use CTRL+TAB or CTRL+PGDN to shift through groups of
panes or pages.
4.2. Providing keyboard accelerators
You should provide underlined keyboard accelerators (also called
shortcut keys or quick-access characters) for all menu items and
controls.
[Insert illustration here]
Once a person becomes familiar with an application, they become more
likely to use keyboard accelerators to speed up common operations. This
is even more common among people who don't use a mouse, including those
who are blind. Because screen review utilities present the user
interface sequentially, the user would have to press TAB and read or
listen to find out what they had reached before deciding whether they
needed to press TAB again. This mechanism slows down the process of
locating the correct destination, and so makes use of keyboard
accelerators much more attractive.
There are two exceptions where you can omit keyboard accelerators:
* You can omit accelerators when you simply can't find any unused
characters in the label to use. In this case you can rename the
control or omit the accelerator, depending on how often or
repetitively the command would be used. An example is the
standard Sort Options dialog box., which had identical sets of
controls for each of the three sort criteria.
* You can omit accelerators when the set of commands is very
dynamic and can't be predicted by the user. For example, the
standard OK, Cancel and Apply buttons used in all property sheets
can't be allowed to conflict with controls on a particular page,
and the property sheet control has no idea what controls those
might be. so the decision was made not to provide accelerators for
the standard buttons. Another example is context menus whose
commands might vary from one instance to another. Context menu
commands can have accelerators when it is clear they will not
conflict, but they can be omitted when they might conflict with
each other or when the user might expect a letter to be associated
with one command and find, unpleasantly, that in this instance it
triggered another.
A side benefit of providing accelerators for dialog-box controls is that
this ensures that a static text control immediately precedes the object
it's labeling in the TAB order, which helps screen review utilities
determine the relationship between the two.
4.3. Using logical keyboard order
Make sure that dialog boxes and similar groups of objects can be
traversed with the keyboard in a logical order, normally from right to
left and top to bottom. If the order does not follow this convention it
can be very confusing to users who are traversing the form using the
keyboard. It is especially confusing for people who are blind and rely
on screen review utilities. Since they explore the dialog box
sequentially, rather than being able to get an overview as the sighted
user would, random TAB order can make the dialog box nearly unusable.
4.4. Document your keyboard interface
Be sure to provide complete documentation on your keyboard user
interface. Some applications provide keyboard commands and mechanisms
but fail to document them for the end user, which means these features
are essentially useless. If the burden of space is a problem, you can
describe the keyboard mechanisms in a separate document and simply refer
users to that in your primary documentation. However, avoid
categorizing keyboard access as a niche or specialty feature, because it
is used and relied on by so many people.
4.5. How much is enough?
The general goal is to provide usable keyboard access to all features in
an application. However, it is admitted that there may be instances
where it is simply not feasible. In some cases it might be too
cumbersome for the user and too challenging for the application
designers, especially if the particular feature being considered will be
used only rarely. There are also rare cases where a dialog box is so
complex that one cannot assign unique accelerators. In these cases one
can use common sense in deciding where tradeoffs need to be made.
In such cases some users can fall back on tools that let them simulate
mouse input using the keyboard or other input mechanism, but these
should not be considered a substitute for good keyboard interface
design. Even simulating a simple drag and drop operation using the
keyboard might require 40 or more keystrokes, which might make the
application accessible but would certainly not be considered usable nor
user friendly. And performing such a visual operation can still be
impossible for a user who is blind. Application designers can design
much more efficient, comprehensive keyboard interfaces for their own
applications and should make every effort to do so.
4.6. Support the Keyboard Preference flag
If your application would normally hide some keyboard user interface
elements, or omit keyboard mechanisms altogether, you should present
these when the Keyboard Preference flag is set. This flag is set by the
user in Control Panel and advises applications that the user relies on
the keyboard, not a pointing device, and so any additional support
should be provided where appropriate. Applications can test this flag
by calling SystemParametersInfo with the SPI_GETKEYBOARDPREF value.
5. Indicating the user's point of focus
Many accessibility aids need to know where the user is working. For
example, a screen review utility wants to convey to the user the
information at that point on the screen, and a screen enlarger would
want to pan it's viewport to make sure the user's focus is always kept
on the visible portion of the screen.
There are many cases where the operating system moves the focus, such as
when entering or leaving menu mode, when moving between standard Windows
controls, or when activating a window. An accessibility aid can already
detect and follow each of these. The difficulty is when an application
has its own, private method of indicating the visual focus within its
own window such as a highlighted cell in a spreadsheet or an insertion
bar that is drawn using non-standard mechanisms.
5.1. Indicate focus by moving the system caret
In these cases the application must expose the focus location to
accessibility aids using the system caret functions. This is not
difficult; simply call CreateCaret when your window receives activation
and DestroyCaret when it loses activation, and while active call
SetCaretPos to move the caret to track the visual focus indicator. The
caret can be left invisible (which is its default state) so that it
won't interfere with the visual presentation on the screen, but its
location will still be known to any utility that needs to track the
focus.
The caret location is specified as an arbitrary rectangle, which allows
it to be reshaped as a single point, a vertical line (which is the
normal appearance of the caret) or a larger rectangular region depending
on the nature and shape of the object that has the focus.
5.2. What is the focus?
Sometimes it can be confusing to decide exactly what is the "active
region" that should be indicated. For example, in a multiple-selection
list the user might select several discontiguous entries by clicking the
mouse while holding down the CTRL key; each selected entry would be
shown using the selected text color and selection background color.
Then the user might then hold down the CTRL key while pressing arrow
keys, in order to put the focus on an entry without selecting it; this
would normally be indicated by moving a dotted rectangle around the
"focus" entry. In that case, when several different locations are
visually indicated by different mechanisms, which should be indicated by
the system caret?
Another point of confusion is extended selection: if the user is editing
a text field and holds down the SHIFT key while pressing the arrow keys,
the result is a string of characters that are all selected; in this case
where is the appropriate location for the caret?
The answer is actually simple. When the user moves the focus, whether
selecting or not, the caret should track this location. Even though in
this example other entries are visually highlighted, when the user moved
the focus manually the caret should track that location. That is where
the user is working; the other selected areas are interesting, and may
be related to the user's current task, but they are not what they are
looking at the moment. It is almost always possible to identify the
single location on the screen that is the primary focus of the user's
attention.
The following examples can help you determine the nature and location of
the visual focus in your own application.
[Restructure this section as a table or
"situation:hint" pairs?]
[Add art examples to each example.]
5.2.1. Example: Focus as a text insertion bar
The simplest example is when the user is moving the insertion point
within a text field; it's often drawn with the real system caret anyway.
When focus is in a text field and indicated by a custom-drawn insertion
bars (for example, to make it appear slanted when in italic text) the
application should still call the system Caret functions to move the
caret within its window, tracking the location of the visible insertion
bar.
5.2.2. Example: Focus on a graphic object
Applications that draw their focus indication in a non-standard form,
such as a highlighted spreadsheet cell or graphic object, should also
move the system caret invisibly to track the active area. In fact, when
the system caret is invisible it can convey more information than just a
single point. The system caret's location is always defined by a
rectangle, and while this is normally the size of the flashing insertion
bar, when the caret is invisible the rectangle can cover the entire
active object. This lets a screen review utility know precisely what
text is part of the active region.
5.2.3. Example: Focus location in extended selection
Let's say the user is editing in a text field: the caret is at the place
where the next character will appear if one is typed. Now the user
holds down the shift key while pressing the left arrow three times:
there are now three characters selected. At the right of this selection
region is the "anchor" location, where the user started the selection
by pressing SHIFT. At the left is the moving end of the selection,
where the selection will grow or shrink by a character. This moving, or
"active" end of the selection is the user's point of focus and the point
you should indicate with the system caret.
Note that all applications should display a flashing insertion bar at
the active end of a text selection , as standard Windows text controls
do this, and it is very useful for all users, as well as for
accessibility aids.
5.2.4. Example: Focus location in discontiguous selection
Let's say the user is working in a listbox which supports multiple,
discontiguous selection. (This would also be true on the Windows 95
desktop, items in a spreadsheet, or in any folder view.) The user uses
the arrow key to select the first entry, then holds down the CTRL key
and uses an arrow key to put the keyboard focus on the third entry; the
first entry is still selected, as indicated by the highlight color, but
the third entry now has the keyboard focus, as indicated by a dotted
rectangle. As in the previous example, it is the latter that would move
if the arrow key is pressed again, so that is the "active" location
which should be indicated by the system caret. In this case, the system
caret could be left invisible, but enlarged to correspond with the
boundaries of the item that has the keyboard focus.
5.2.5. Example: Focus among custom controls
If an application is drawing custom controls that don't have their own
window, it is necessary to explicitly tell accessibility aids where the
focus is. When focus is placed on a custom control that behaves like a
pushbutton, the focus is assigned to the control as a whole, so the
system caret should be assigned to the rectangle containing the control.
When focus is placed on a complex control, such as a listbox, that can
place the focus on individual elements within the larger control, the
system caret should be used to indicate the rectangle of the item that
has the focus.
5.2.6. Example: Focus location in a spreadsheet
A spreadsheet can be considered a complex custom control containing
multiple elements (cells), and the focus is normally placed on an entire
cell. In that case, the system caret should be set to the outline of
the entire cell that has the focus.
6. Controls and Menus
A sighted user can often usually identify a control such as a pushbutton
or checkbox by its appearance, but a person who is blind has to rely on
their screen review utility to describe the object to them in words.
The utility presents the user with the name, type and state of the
control. For example, tabbing to a checkbox might say "Quick printing
checkbox checked". Obviously it can only do this if it can determine
all those properties programmatically. Voice input utilities have
similar requirements, needing to identify and name specific controls,
and also how to manipulate the control in response to the user's
commands. In some cases, the user of non-standard controls can render
the application completely unusable for people who are blind or use
voice input utilities.
We can divide controls into the following categories, each of which will
be discussed in turn:
* Standard Windows controls (including Window Common Controls)
* Owner-draw controls that behave like standard controls but have
customized appearance
* Subclassed controls that add customized behavior to a standard
Windows control
* Custom controls that are implemented by the application without
using the normal Windows mechanisms
* OLE Controls, which are custom controls designed to a standard
programmatic interface
* Owner-draw menus
6.1. Standard controls
You should use standard controls whenever possible because they are the
most compatible with accessibility aids.
Each standard Windows control is a separate window of a specific class,
so the accessibility aid can get notified when the focus moves to a new
window, and can find out the window's class. The class tells it what
additional messages it can send to the control to query or alter the
state. They can also identify all the child controls contained within a
parent window, and identify the parent of any control.
The Windows 95 Common Controls Library provides standardized
implementations of many controls that aren't supported by Windows
itself, and these are all architected to be compatible with
accessibility aids.
6.2. Owner-draw controls
Owner-draw controls can be quite accessible as long as a few precautions
are taken in their use.
Owner-draw controls are one subclass of standard controls, where the
program alters only the visual appearance. Some applications use custom
controls only to change the appearance of the control when owner-draw
controls would be an acceptable, and more accessible option. For
example, they might want a checkbox to have an actual check-mark instead
of an X, or might want a pushbutton to be labeled with a picture
instead of a word. Using a standard Windows control with the OWNERDRAW
style would make the control appear normally to accessibility aids , but
still allows the application to give them a customized appearance.
You should define the label for an owner-draw control even if that text
will not be visible on the screen. When creating an owner-draw control
where the normal caption won't be visible (for example, a button with a
graphic face) the developer might simply leave the caption as a blank
string, but that would prevent the aid from querying the caption with a
WM_GETTEXT message and using it to identify the control. Be sure that
your owner-draw control handles all the other class-specific text
retrieval messages, such as CB_GETKBTEXT, LB_GETTEXT and so forth, and
set the appropriate style bits (such as LBS_HASSTRINGS) to indicate that
your owner-draw control supports these messages.
6.3. Subclassed standard controls
Some applications use standard controls but alter their behavior by a
technique known as subclassing. In this case basic control functions
are still handled by the underlying system code for the standard control
type, but the application adds its own special behavior. When using
these controls:
* Be sure they still respond to the normal messages for their
class.
* Use recognizable class names. Since subclassed controls normally
have a unique class name, make sure the control's class name
identifies the base class by including the normal class name as a
substring. For example, a subclassed BUTTON could be given a
class name like "MyAppButton", and accessibility aids seeing this
would then assume that the control is a subclassed button.
* Similarly, don't create class names that include the names of
standard control classes, lest accessibility aids mistakenly
assume that they are related to that class.
6.4. Custom controls
In general, you should avoid using "fake" or custom controls because
they will not be fully usable with screen review or voice recognition
utilities. Custom controls present a number of problems, because
accessibility aids cannot identify the type of the control or its state,
and if the control doesn't even have its own window they will not be
able to watch it getting and losing focus.
At this time there is no standard way for applications using non-
standard controls to work well with accessibility aids. However, there
are some techniques that can be used as short-term solutions.
* If the custom control has its own window, you can return a
descriptive string when queried with the WM_GETTEXT message. For
example, a control that appeared as a button with the label Print
could be return the string "Print button" to convey both the
control type and the label, and the same string would be
appropriate if the control looked like a button with a graphic
rather than a textual label. Similarly, a custom control that
behaved like a checkbox might return a caption string "Printing
Enabled checkbox checked".
* If the control has no window, you can associate a descriptive
string with the control by using the techniques described in
section 7.2, "Avoid using bitmapped text". This string can follow
the same conventions described in the previous paragraph.
* If the control lacks its own window, you can convey the focus
location to accessibility aids by moving the system caret as
described in section 5, "Indicating the user's point of focus".
6.5. OLE Controls
The preferred method of creating custom controls is to use the OLE
Controls architecture. OLE Controls are an extension of the model used
in the Microsoft Visual Basic programming system. Each control is an
OLE object with many standardized properties and methods. Future
versions of the OLE libraries will support a method to obtain Interface
Pointers (object handles) to each object in a window or region of a
window by querying with a window message. Once you have an interface
pointer, you can make calls to the object to get or set properties,
including location, name, and primary value.
As an application that will host OLE Controls, be sure to support the
IOLEContainer interface, which allows enumeration of embedded controls
and other objects.
6.6. Owner-draw menus
You should always provide an alternative to owner-draw menus, especially
if they present a purely graphical appearance.
Owner-draw menus are a flexible means to present customized appearance,
either by making a menu item a combination of graphics and text or
graphics alone. For example, a menu might let the user select from a
series of colored rectangles, or select a line thickness by seeing
examples, which is easier to understand than a purely textual
representation such as "3 pt".
However, owner-draw menus can be incompatible with screen review
utilities as well if they display graphics instead of text, and they are
always incompatible with voice input utilities.
Luckily, it is fairly easy to reach a compromise in this situation, and
in fact several are possible:
* Menu items can be redesigned to include both the graphic and
text. For example, a menu item for selecting line width might
show a sample of the line followed by text showing the width.
This could also prove useful for a sighted person doing layout
based on a written standard which might specify that lines should
be of a particular thickness.
* Allow the user to choose whether they want graphical choices or
textual, and when they choose textual revert to standard rather
than owner-draw menus. This would be a good use for the Screen
Reader Present flag, a global flag which tells all applications
when the user is relying on a screen review utility. When that
flag is set, the application could simply use the textual values
instead of (or in addition to) the graphical presentation.
[Show examples here]
6.7. Use appropriate controls for displaying values
Windows provides a number of controls for displaying information to the
user, but making the proper choice can improve the keyboard access to
your application as well as its compatibility with accessibility aids.
Use the following guidelines in choosing the control that's appropriate
for the user's interaction with the information.
[[Illustration]]
[Replace with illustration that has a status
control as well.]
* Use static text controls for labels. In this example, the words
"Current file name" and "New file name:" both identify
accompanying controls, and so are displayed as static text
controls.
* Use read-write edit controls for values which the user can edit
directly. In this example, the new file name is an edit control
which starts with a default value, but which the user can freely
change. Read-write edit controls should always have visible
borders.
* Use read-only edit controls for values which the user cannot
edit. In this example, the current filename is actually
represented by a read-only edit control. This allows the user to
select the text and copy it to the clipboard, or drag it to
another document. This field is also included in the TAB order so
that a user can navigate to it using the keyboard. (However, the
label for this field does not have an accelerator because the user
would not normally need to access the read-only value, and having
an accelerator would call undue attention to the fact that the
value is manipulatable.)
* Use status field controls from the Common Controls Library to
display values which may change dynamically as the user watches.
In addition to being consistent with other applications, this
provides hints to screen review utilities that might notify the
user when this value changes.
7. Drawing Techniques
Drawing techniques are primarily important to insure compatibility with
screen review utilities. Screen review utilities watch these calls and
remember what text has been drawn and at what location, as well as its
attributes such as font, size, whether it's bold or italic, and so
forth. They also watch information being copied from one location to
another, being erased or being overwritten by other graphics or text.
These utilities rely on being able to see the normal Windows drawing
operations.
7.1. Draw with the standard Windows API
You should always draw text with the normal Windows API calls such as
ExtTextOut so it can be seen by screen review utilities. This is true
whether you're drawing to a screen or to an off-screen bitmap. By
watching every API call that creates a bitmap, draws to it or copies
from it, text can be tracked until it is displayed to the user.
However, there are two techniques that bypass the normal system calls
and prevent a screen review utility from working, such as the use of
bitmapped text and directly manipulating pixels.
7.2. Avoid using bitmapped text
Some applications ship pre-created bitmaps either as resources or in
separate files shipped with the application. The screen review utility
can watch these bitmapped images being loaded, manipulated and copied to
the screen, but it has not way of understanding the contents of the
bitmap. If it contains text, that text would be visible to the sighted
user but could not be presented to the user who is blind. We refer to
such bitmaps as "bitmapped text", because the text starts out as part of
the bitmap and the text is never available to the system.
You should draw text using the standard Windows API, but there may still
be cases where it is necessary to display text as a hand-tuned bitmap
such as a corporate logo. In these cases, there is a simple way that
the application can inform the screen review utility of the text
associated with the bitmap. The application can easily carry the text
along with the bitmap, most likely as entry in the application's string
table resource. When the bitmap is loaded from disk using the
LoadBitmap function, the application can also load the text using
LoadText. It can then inform the screen review utility of the
relationship between the two by drawing the text over the bitmap
invisibly, so that it will not be seen by the sighted viewer but will be
noted by the screen review utility.
To perform this operation, create a temporary screen-compatible bitmap
and an associated memory DC. Draw the text into the bitmap using
ExtTextOut, and then use BitBlt or StretchBlt to copy the bitmap onto
the destination location, specifying the NOP rasterop. The destination
can be either the screen or another off-screen bitmap. It is easiest to
do this when the bitmap is first loaded into memory, and the aid will
keep track of the information thereafter.
It is only necessary to perform this extra task when a screen review
utility is running. You can determine this by calling
SystemParametersInfo with the SPI_GETSCREENREADER flag.
7.3. Avoid directly manipulating pixels or bitmap bits
Use standard system calls for erasing text and other graphic object, and
for copying bitmap memory. If you must use alternative means, provide
an option of reverting to standard behavior.
Some applications directly manipulate the memory associated with a DC,
bypassing the Windows API altogether. This is most commonly done with
monochrome or device independent bitmaps.
In these cases the screen review utility cannot be aware of the changes
taking place. For example, if text is drawn into a bitmap using a
Windows function call and the application later erases it by simply
clearing the bitmap memory, the screen review utility will believe that
the text is still present. If the bitmap is used again for another
operation the text might be read to the user even though it was no
longer visible. Similarly, if the bits comprising one bitmap are copied
directly into another without using the Windows API, the screen review
utility won't be aware of it and text displayed visually might be unseen
by the screen review utility.
The Windows API provides several means of manipulating bitmap or display
pixels directly, such as DCI, WinG and CreateDIBSection. Using these
will bypass screen review utilities. If your application relies on
these techniques for performance, make sure that you also support more
conventional techniques, and use the conventional techniques when a
screen review utility is running in the system. This can be determined
by calling SystemParametersInfo with the SPI_GETSCREENREADER value.
7.4. Identifying separate screen areas
Anything that is drawn using a single operation appears to a screen
review utility as a single object. Therefore, a bitmap appears as one
object, even if it might appear as several distinct objects to the
sighted user.
For example, an application might use a custom control that looks like
an array of buttons, but is really a single bitmapped image. A screen
review utility would describe the entire array as a single object and
the user would have no way to manipulate the individual buttons.
In such cases the application should use a ToolTips control to identify
each separate region. The ToolTip control is one of the Windows Common
Controls introduced in Windows 95, and it has the advantage that it
identifies not only the region but also a textual label to associate
with it. In addition, it provides this information to the sighted user
in a way that is consistent with the rest of the Windows interface.
If for some reason you cannot use ToolTips there are two other
techniques you can use to identify regions of the screen. However, both
are less functional and less standardized than the ToolTips approach.
* First, the application could simply draw each component object as
a separate bitmap. Normally this would not incur any significant
cost for performance, memory or disk space. They can be drawn to
an off-screen bitmap and then copied to the screen in a single
operation.
* Second, the application could keep the array as a single bitmap,
but identify the separate regions for a screen review utility by
drawing shapes over it invisibly, using the NOP rasterop. This
technique is described in section 7.2, "Avoid using bitmapped
text".
It is only necessary to perform these extra tasks when screen review
software is running, which can be determined by calling
SystemParametersInfo with the SPI_GETSCREENREADER value.
8. Identifying Windows
Windows need to be identified in two ways: for the end user, and for
accessibility aids.
8.1. Identifying windows for the end user
Try to assign a user-friendly caption to every window, whether or not
it's visible on the screen.
Every window can have a caption, whether or not they have visible
caption bars. Screen review utilities query this text by sending a
WM_GETTEXT message, and use it to identify the window to a blind user
when the window receives focus or when the user issues a "What window am
I working in?" query. But for this to work the application developer
has to provide appropriate text when the window is created or by calling
the SetWindowText function.
Note that this applies not only to top-level windows, but also to child
windows such as floating palettes and toolbars, and even to panes within
the same window frame when these are implemented as separate windows.
8.2. Identifying windows for accessibility aids
Try to give different types of windows separate, unique window classes
so that accessibility aids can identify their function.
Accessibility aids sometimes need to special case their handling of
different windows within the same application. For example, an
application which has both a word-processing and a spreadsheet window
might draw the visual focus indication in very different ways. The
screen review utility may also have separate instructions for handling
these windows, such as identifying areas of the window which should
automatically be read to the user whenever they change.
While a human being can identify a window by its title, this is not a
reliable mechanism for accessibility aids because many window titles
change dynamically with the document or the status, or are localized
into different languages. Window class name does not change under
either circumstance.
9. Timings and Navigational Interfaces
There are several cases where an application can make it more difficult
for people with some disabilities to access information because of when
and for how long it is displayed. In general, allow users to customize
timings, and avoid having normal actions create unexpected side effects.
9.1. Avoid having messages time out
Avoid having messages time out, and if you must, provide an option to
disable the timeouts.
There are many reasons why a person may not spot a warning that is only
displayed for a brief period of time. For example, the person might be
using a screen enlarger and may have to reposition the viewport or
adjust other attributes in order to read the text correctly. They may
take a longer time to type in an answer than you would normally assume,
or it may take them longer than average to read and understand the
message. Or the person might simply have stepped away from their desk
for a moment.
If a message is actually important, the best way to make sure it is seen
it to display it until the user consciously dismisses it. Even if the
message is unimportant consider how disconcerting it is to have a
message disappear before you finish reading it. And if the user didn't
have time to fully read it, how can they be sure that it wasn't
important?
9.2. Don't trigger events by pointer location
Avoid having events triggered by simply moving the mouse pointer over or
off a special area, and if you must, make it optional.
Some accessibility aids require the user to move the mouse pointer in
order to explore the information on the screen. For example, a screen
review utility may move the mouse to follow the words being read, or the
user may need to move the mouse to enlarge certain text.
This can be a problem if moving the mouse causes side effects. For
example, if some text appears when the mouse moves over an object, and
disappears when you move the mouse off of it, then it would essentially
disappear each time you tried to read it!
There are two exceptions where it is acceptable to trigger changes based
on pointer movement, because these are already understood by
accessibility aids and handled appropriately:
* It is acceptable to change the shape of the mouse pointer itself
as it is moved. For example, you can change the shape to indicate
whether or not an object is a valid drop target.
* It is acceptable, and in fact encouraged, to use ToolTips to
display an object's name or other explanatory information when the
pointer is paused over that object.
9.3. Don't trigger events by focus location
Avoid having events triggered by simply moving the keyboard focus, and
if you must, make it optional.
In order to allow the user to "read" or explore a window's contents,
keyboard mechanisms should allow one to change focus to a control or
area without triggering some unexpected action. This is especially
important because users who are blind need to browse through the objects
on the screen sequentially, rather than being able to take them all in
with a single glance. It is typical for a user who is blind to use TAB
to move through all the controls in a dialog box as a means of exploring
it, before they go back and do any actual work. In the Windows
operating system the TAB and SHIFT+TAB keys generally move the focus
without triggering any other action, and applications which change this
behavior may are confuse many users and pose difficulties for users with
disabilities.
There are exceptions to this rule, primarily in cases where behavior is
standardized and mechanisms exist for accessibility aids to work with
this information:
* It is acceptable to display explanatory text while processing
menu messages, in order to show details about the function of the
menu. It is preferable to draw this in a status bar to be
consistent with other applications, but any text drawn during menu
processing will be assumed to serve this function.
* It is acceptable to automatically change the value of option
controls (radio buttons) and tab controls during keyboard
navigation. This behavior is actually a problem for keyboard
users, but is necessary for backwards compatibility.
* If you take some action when the focus moves, provide an
alternative way to move the focus without any extra effect. For
example, in the context pane of the Windows Explorer you can move
focus between directories using up and down arrow keys, but doing
so automatically selects that entry, reads the location's contents
and displays it in the results pane. This is a case where the
user should be allowed to move with CTRL+UP and CTRL+DOWN to move
the focus without changing the selection and so avoid the side-
effects.
10. Color
Appropriate use of color can greatly enhance a user interface, but only
if used appropriately. In general, don't convey information by color
alone because some people won't be able to perceive it. Color should
only be used to enhance, emphasize or reiterate information shown in
other means. If you must convey information through color, make sure it
is also made available through an alternative form.
10.1. The importance of customizability
For many people, color is just a matter of preference. They may use
Control Panel to choose a personal color scheme that they enjoy, but
they don't mind and probably don't even notice if an application always
draws its elements in a fixed color.
But for some users with visual impairments, color is critical. Many
people require reasonably high contrast between text and the background
in order to be able to read. They may even need a particular scheme,
such as white text on a black background, which would prevent the
background from "bleeding" over and obscuring the foreground text. Some
people consider the default color scheme quite legible but find that it
causes eyestrain over longer periods of time. Still others, nearly 10%
of males and 1% of females, have some form of color blindness that makes
certain color combinations unreadable.
10.2. Don't convey information by color alone
If you convery information by color alone, some users won't be able to
make use of this information. Even allowing the user to customize the
colors is insufficient if the user can only read white text on a black
background, of if you're running on a hand-held computer with a
monochrome display. For these situations the application should also
make the information available through means other than color.
10.3. Use standard system colors where appropriate
When possible, an application should use the standard system colors that
the user has selected through Control Panel. This is easiest when an
element in the application's window corresponds with a usage handled by
Control Panel, such as window text, button face, dialog box text, and so
forth. By using the color combinations that the user has explicitly
chosen, you reduce the chance that your choice of colors will make your
application unusable and ensure its pleasing to the user without having
to provide your own user interface for adjusting colors.
The correspondence between your use for the color and the use described
in Control Panel does not need to be exact; for example, the user's
choice of window text color and background is probably a safe
combination to use for any purpose.
10.4. Use colors in proper combination
Always use system colors in their proper foreground-background
combinations to ensure that they have reasonable contrast. The user
will never choose a ButtonText color that is the same as their
ButtonFace color so these will always be legible when used together, but
the user can alter the color scheme so that system colors that normally
contrast, such as ButtonText and WindowBackground, might actually be
the same color on their systems. If you draw using colors which are not
specifically designed to be used in combination, the information may be
completely invisible.
Similarly, always draw foreground objects in foreground colors and fill
backgrounds with background colors. Many users require specific high-
contrast combinations, such as white text on a black background, and
drawing these reversed, as black on white, would cause the background to
"bleed" over the foreground and make reading difficult or even painful.
The following tables show some combinations that are safe to use, and
others which are not.
Safe:
* WindowText on WindowBackground
* ButtonText on ButtonFace
Unsafe mixing combinations:
* WindowText on ButtonFace
* ButtonText on WindowBackground
Unsafe reversing foreground and background:
* WindowBackground on WindowText
* ButtonFace on ButtonText
10.5. Make custom colors customizable
If you use colors for elements that don't correspond to system colors
selected in Control Panel, provide your own means to adjust these
colors.. For example, a calendar application might use different
background colors to indicate different types of events. This is an
example of colors which need to be defined by the application, because
these additional color elements are not covered by the color schemes in
Control Panel. When using application-specific colors in this way, allow
the user to assign their own choice of colors to these functions.
Historically, some applications have had fixed colors because they
didn't want the user to select an "ugly" color scheme that would make
their application look bad. But remember: no one complains about a
color scheme that they themselves choose, but you cannot please everyone
by forcing a single scheme upon them.
Another option to keep in mind is that of providing patterns as an
alternative to colors. In the example of the calendar application, the
user could be allowed to choose a pattern along with the color for each
type of scheduled event; then they could choose a color combination that
works for their eyes and supply the additional information by a
background pattern.
10.6. Coloring graphic objects
Graphical objects present special challenges. For example, some
application displays buttons that have pictures on them instead of, or
in addition to, text. Can the colors defined in Control Panel be
applied to this case?
If the picture on the button is monochrome, then the solution is quite
simple. The button face should always be drawn in the standard system
color (COLOR_BTNFACE aka COLOR_3DFACE) and the foreground image should
be drawn in the standard button text color (COLOR_BTNTEXT). If the
image is drawn inside a window rather than on a button, it would be more
appropriate to use COLOR_WINDOW and COLOR_WINDOWTEXT instead of the
button colors.
If the picture is multicolored, it presents more of a problem. The
easiest solution would be to also carry along a monochrome image which
could be used on monochrome displays and when the user has chosen a non-
default button face color or has requested High Contrast Mode (described
below).
If it is not possible to carry monochrome images, you can attempt to
create them on the fly from the multi-colored images by identifying
light and dark areas as foreground and background. For example, if you
have a bitmap which has a multicolored object on a white background, you
could map all colors other than white to the appropriate system
foreground color, and white to the system background color. You could
reverse these colors for images designed with a dark background.
[Insert code fragment to illustrate this
technique.]
[Need to document a test for determining whether
the "foreground" of a bitmap is the dark or
light portions? How does one determine that
you're on a monochrome display?]
10.7. Prevent backgrounds from obscuring text
If you draw text over a varied background such as a wash of colors or a
bitmap it may make the text illegible for some viewers, so always
provide an option to omit the image and revert to a plain background.
Text is most legible when drawn against a plain background of a
contrasting color, and many users with low vision won't be able to read
text if the background is irregular.
Instead of providing your own option, you can simply omit the background
in response to the High Contrast setting, which is discussed in the
following section. You should also omit the background if the
foreground color changes. For example, you may draw text over a very
light bitmap image, and they may be quite legible with the default color
scheme but become unreadable when the user chooses a light foreground
text color.
When you are using a complex background, you can keep it reasonably
legible by making sure the background image contrasts well with the
text. If the foreground text is black, and it is drawn over areas of
the image which are a brown or other dark colors, many users will find
it harder to read.
10.8. High Contrast Mode
If an application uses standard system colors, or allows the user to
choose colors which are not defined by the system, that should take care
of all basic color-related needs. However, Windows 95 introduces a new
feature called High Contrast Mode, which the user can activate through
Control Panel to advise applications that they need high contrast
visuals.
Applications can check this setting by calling SystemParametersInfo with
the SPI_GETHIGHCONTRAST value. Applications should query this value
during initialization and when processing WM_COLORCHANGE messages.
When the High Contrast Mode flag is set the application can take
additional steps to make its display friendly for users who require high
contrast. Here are some examples of behaviors that should be adopted
when the High Contrast Mode is on:
* Omit bitmapped images or other complex backgrounds behind text and
controls.
* Draw images in monochrome instead of multiple colors, and draw
them using standard foreground and background colors.
* Replace application-specific colors with standard system colors
defined through Control Panel, and try to use as few color
combinations as possible.
11. Size
Many people appreciate the ability to crowd the maximum amount of
information onto a single screen, but there are also many millions of
people who find small type inconvenient or uncomfortable.. A person
with a severe visual impairment will likely choose an accessibility aid
to help them use the computer, such as a screen enlarger to allow them
to zoom in on a portion of the screen. But there is a much larger
number of computer users whose vision is only slightly worse than the
average 20-year old. They may have no trouble reading 12 pt text on the
computer screen, but find it difficult to read text in smaller sizes.
Others may not have trouble reading, but suffer from headaches and
eyestrain at the end of a day. They don't view small type as a problem
of one of accessibility--they view it of one of usability.
It is also important to note that an application might work fine for a
user on one machine, only to become unusable on another system. Far too
many application are designed to look good at standard resolution, only
to have their information shrink to near invisibility when run on a high
resolution monitor, or position information inaccessibly off the screen
when run on a small, pen-based computer.
11.1. Selectable font sizes are user-friendly
The best way to satisfy customers who prefer small type and those who
require larger type is to allow the user to choose the typeface and size
that best fit their needs. This simple feature can make applications
seem much more user-friendly.
The preferred approach is to provide a menu option or property sheet
where the user can choose the font with the standard font selection
dialog. A second approach is to automatically resize the fonts when the
user resizes the window, but this is less flexible because they can't
use a large font in a small window with scroll bars.
Let's look at an example. The FaxFire application is used to drive a
fax card connected to the user's PC. It has a window which shows a list
of all the faxes that the user has sent of received during the last
month, with each line showing information about a single fax: it's date,
the destination, and so forth. The line has a maximum length of 50
characters, and since it is always drawn in a 10 pt font the window is a
fixed size. But some of the user's have complained about the fixed font
size. What can the developer do? With a minimal amount of work, a
Font... command could be added to one of the menus, and it could let the
user choose a font using the standard Font Selection dialog provided in
the Windows Common Dialogs Library. When the application is drawing its
text, it can easily use the font the user has requested. In case the
font selection makes some of the information extend beyond the edge of
the window, the window can be changed to resizable, and it can also be
given scroll bars. The total amount of work has been quite reasonable.
11.2. Provide alternatives to WYSIWYG
Some applications try to present a WYSIWYG ("what you see is what you
get") view of a document, making the text on the screen reflect the
appearance the text will have on the printed page.
But it is easy to appreciate the feelings of a person who says "I want
this to print in a tiny font, but I don't want to drive myself crazy
trying to edit it when it's that small." In reality, size of the type
on screen need not be linked to the size that the text will be when
printed. It is easy to allow the user to adjust the size of information
on the screen through several methods, such as a draft or zoom modes,
which are described in the following sections.
11.2.1. Draft mode
One method for allowing the user to bypass WYSIWYG is to provide a draft
mode wherein a single font is used for all information. In those cases
it is customary to use a single type of annotation, such as underlining,
to indicate characters that would normally be drawn with any form of
additional formatting, such as bold or italics. (Draft mode also
provides an added benefit for users running on extremely slow systems or
with little free memory, as it typically performs better in those
situations.)
Ideally you should allow the user to choose the draft font; using the
system font may be the best way to conserve memory, but because it's
harder to customize it might not be the best for the user's vision.
11.2.2. Zoom features
An extremely valuable feature that applications can support is a "zoom"
facility, wherein everything in the document is scaled to a user-
selected ratio. Many applications, such as Microsoft Word and Microsoft
Excel, offer this feature and it is of benefit to many users who don't
consider themselves to have disabilities, as well as those who do. Use
of the TrueType(R) scalable font technology ensures that characters will
remain clearly defined at almost any size.
11.3. Scaling non-document regions
Most applications display information in more ways than just text.
Buttons, rulers, and graphic images all can pose the same trap for
people: if the object is a fixed size (especially a small size), many
people will appreciate the ability to make it larger.
Many applications' windows contain two types of information: an image of
a document created by the user and one or more panes presented by the
application itself. A good example of that would be a word processor
with a toolbar of command buttons. If the Zoom command were to apply
only to the document, and not to the surrounding information, then the
user could still find themselves unable to easily use the application,
or suffer the constant annoyance of "tiny button syndrome". The
application could have a single zoom factor applied to both types of
information, but one would not want to have the size of your buttons
change just because you've had to turn on zoom to edit some 8 pt text.
Similarly much of the benefit of a toolbar is lost if you have to scroll
to reach some of the buttons.
A more powerful mechanism would be to allow the user to independently
select the zoom ratio for each pane, whether a document or non-document
region. Fro example, "Toolbar Size" can be provided as a separate
option, and a single setting can apply to all toolbars. It is often
more convenient to provide a simple option to let the user choose from a
range of sizes instead of a more general scaling factor.
11.4. Be compatible with system size metrics
It is also extremely important that applications drawing their own
screen elements pick up the size settings that the user has selected in
Control Panel. For example, if using a private dialog manager that
draws "fake" dialog boxes, be sure it uses the dialog font the user has
selected for the rest of the system. The same would apply for scroll
bars, custom menus and so on.
11.5. How wide is a line?
One example of maintaining compatibility with system metrics deserves
special attention. Many applications draw lines with a fixed width of
one pixel, but not only does that disappear on high-resolution monitors,
it may also be invisible to a person with low vision.
Instead, applications should determine the proper thickness of a line by
calling GetSystemMetrics with the SM_CXBORDER and SM_CYBORDER constants.
These constants are defined appropriately for the resolution of the
monitor, and in future operating systems the user will also be able to
adjust these to suit their vision.
11.6. Be compatible with global scaling
Windows 95 provides a Custom Font Size option--the ability to globally
scale all fonts and most other visual elements on the screen by changing
the number of pixels used to represent a "logical inch". In order to be
compatible with this feature, applications should avoid drawing in
MM_TEXT mode, which bypasses logical scaling. If an element of the
application's user interface uses MM_TEXT while the rest does not, that
one element will be drawn our of proportion to all the rest of the
screen elements.
It is also important to note that bitmaps are not automatically scaled
by this factor. Bitmaps are discussed further in the next section.
11.7. Adjust images for different sizes
There are several circumstances where you might need to accommodate a
graphic image to a different amount of space than you originally
intended. For example, the user may adjust the global scaling constant
with the Custom Font Size feature, or the application might itself allow
the user to choose a differently sized font. In these cases, an
application might draw an image that turns out to be unexpectedly out of
scale with the surrounding text or other window elements.
11.7.1. Alternatives to bitmaps
This is especially a problem when drawing bitmaps, which are not
automatically scaled and usually don't look good when stretched. The
cleanest solution is to avoid using bitmaps altogether, and instead use
something that is designed to scale well:
* Metafiles are a convenient way to encapsulate an image for easy
playback, and they can automatically scale to fit the destination
rectangle and normally look good at almost any size. (Of course,
the benefit is lost if the metafile itself contains things that
don't scale, such as bitmaps.)
* If the image is simple and you don't need to encapsulate it for
easy storage and playback, you can simply create a routine to draw
it on the fly using Windows graphic primitives.
* You can create TrueType glyphs to represent the image. This can
be expensive if you don't have the expertise in-house, but allows
the image to optimize itself for any size.
11.7.2. Accommodating bitmaps when changing size
If you have to use a bitmap, there are several methods by which you can
accommodate it to different size regions:
* You can scale your bitmap manually using the StretchBlt function
so that it fits its space in your window.
* In cases where the surrounding elements appear disproportionately
larger than your bitmap, normally it is not a problem since you
simply have extra blank space around the bitmap. To insure that
the blank region around your bitmap isn't left with bits of older
information lying around, be sure to erase the region to the
appropriate background color. Specify the size of the region
using a drawing method other than MM_TEXT so that it will
automatically adjust to any global scaling factor.
* In cases where the surrounding elements appear disproportionately
smaller than your bitmap, make sure that the bitmap is properly
clipped to the surrounding rectangle. For example, when the
Custom Font Size feature is used to select a global scaling ratio
of less than 100%.
12. Sound
You should avoid conveying important information by sound alone, because
some user's won't be able to hear or recognize it. The user may be deaf
or hard-of-hearing, or may simply be using the computer in a very noisy
environment such as a workshop, or a very quiet environment where
they've been asked to turn off their computer's sound.
Applications make sounds for a variety of different reasons:
1. Important sounds which convey information that is not presented
visually and which is important to the operation of the
application. Examples include playing an audio wavefile with
narrated instructions, or playing a sound to notify the user that
new mail has arrived.
2. Redundant alerts, which accompany a visual presentation of the
information, yet serve an additional function by attracting the
attention of a user who is not looking directly at the computer
screen. An example is the optional beep that can accompany a
messagebox.
3. Redundant sounds, which are redundant with information already
presented visually, and thus are not required for proper operation
of the application. An examples is playing an error sound or beep
when the user tries to move beyond the end of a listbox.
4. Decorative sounds, which enhance the appearance or presentation
but which are not required for the operation of the application.
Examples include the sound effects that accompany minimizing a
window or activating a menu, and background sounds used to
establish a mood in many multimedia games.
For the last two types of sounds, the user who cannot hear the sounds is
not disadvantaged, but the first two categories do require special
concern.
Windows 95 and other utilities provide the ability to detect when the
computer is making noise and display a generic visual indicator to the
user. This feature is referred to as "SoundSentry". This works
reasonably well in cases where the sound is just a generic beep, warning
the user or trying to attract their attention. But it is of limited use
with applications that use different sounds to convey more complex
information. Conveying complex information requires the cooperation of
the application.
12.1. Support the ShowSounds flag
In order to convey complex information to users who cannot rely on
audible forms, the computer industry has standardized on a concept
called "ShowSounds". ShowSounds is a global flag that can be set by the
user to indicate that they need important information displayed by
visual means. Effectively, it is asking applications to display closed
captions for their sounds.
Applications can query the ShowSounds flag by calling
SystemParametersInfo with the SPI_GETSHOWSOUNDS value.
This does not mean that sounds can't be presented normally, and in fact
redundant use of sound and visuals generally increases the usability.
The user should be able to request visual feedback independently of
whether they want audible feedback as well.
ShowSounds flag is only meaningful to applications that would normally
present important information by sound alone, and it's up to the
application to decide how best to convey this same information in visual
form. The following examples can help you determine the behavior
appropriate to your situation.
12.1.1. Example: New mail arriving
In order to attract the user's attention when new email arrives, the
application might:
* Flash it's title bar using the FlashWindow function. If the
window is not visible it will automatically flash the
application's button on the TaskBar.
* Put up a messagebox that steals the activation and keyboard
focus. This should be avoided if the user might be typing into
another application at the time.
* Display a status indicator on the notification area of the
TaskBar.
12.1.2. Example: Beeping on bad input
Applications often make a sound to indicate an error status, such as
typing an invalid character. In these cases the application might Flash
it's title bar using the FlashWindow function. If the window is not
visible it will automatically flash the application's button on the
TaskBar.
12.1.3. Example: Playing a video clip
Applications that display multimedia animation of video clips should
support the ShowSounds flag with true closed captioning. Microsoft
Video for Windows supports creating a separate, synchronized data stream
for captioning information, although the application is responsible for
displaying this information on the screen.
12.2. Allow the user to turn off sounds
Support the ability to turn off sounds your application makes, because
such sounds can be distracting or annoying for some people, such as
those who are deaf or hard-of-hearing, or in some environments such as
crowded or public spaces. This is especially true of decorative sounds
or sounds that are redundant to information on the screen.
If you do not want to provide your own option to turn off sounds, you
can check the SM_BEEP option using the GetSystemMetrics function. If
this option is FALSE then the user has chosen to turn of the standard
system beep, and you can infer that they also want other sounds
disabled.
13. Layout
There are several ways in which the visual design of your application
can improve its accessibility.
13.1. Attach textual labels to all controls and graphic objects
Some types of controls, such as buttons, have their own textual labels;
screen review utilities have no trouble describing such a control to the
user, and voice input utilities can recognize the name when it's spoken
as a command. But other objects, such as edit controls or graphical
objects, are typically labeled by placing a static text control nearby.
The Windows Interface Guidelines for Software Design describes
guidelines for the placement of such labels so that they are consistent
across all applications. This helps makes the interface more consistent
between applications and more usable for everyone, and it also helps
accessibility aids. Proper labeling allows a screen review utility to
infer the relationship between a static text element and the control
that it labels. If a static text field ends in a colon, the screen
review utility knows it is a label and looks for an unlabelled control
either to its right or directly below it. When it wishes to describe
that control to the user, it can use the label from the static text
field.
If the label and the control it refers to are not arranged in the
standard pattern, it may be difficult for both sighted users and screen
review utilities to determine which label applies to which control, or
even that the two are related. The control and its label should not be
separated by too great a distance, and a text label should not have
unlabelled controls both beneath and to the right of it.
[Insert illustrations]
13.2. Labeling icons
If your application uses icons or any type of graphic to represent
objects or controls, you should also display a textual label with the
icon. This arrangement is already familiar to users, and the
combination of text and graphics helps shorten the learning curve for a
new user. It helps screen review utilities describe the object to a
user who's blind, and it helps users associate a name with the control
to activate or navigate to it by voice or other alternative input
systems.
Following the normal guidelines, text should generally be placed
immediately beneath a large icon, or to the right of a small icon. When
you place a text label beneath an icon, use the font and size defined
for icon titles in Control Panel to make it consistent with other
applications, and also allow a user to customize the appearance if they
need to.
[Insert illustrations]
13.3. Label controls clearly
Label controls and similar objects with names that convey information
without relying on spatial context.
When a user is blind or has low vision, they use the computer much like
a person looking through a hollow tube: they can only read a small
portion of the screen at a time. A user who has tunnel vision or uses a
screen enlarger will see a control and perhaps its immediate
surroundings, while a blind user examining a control will have only its
name, its type, and the name of the window and any groupbox its in.
They won't have any of the context provided by spatial arrangements. You
should ask yourself: if you were presented only with the name and type
of this one control, would you understand how to use it?
This does not mean that labels have to be long and detailed, but, for
example, having several buttons with identical labels can be confusing
if they are only distinguished by position. This can be mitigated
somewhat if their position in the TAB order makes their association
clear, or if they are within separately labeled group boxes.
13.4. Position related items near each other
Try to arrange information and other objects so that related items are
near each other. Since a person with low vision or tunnel vision can
only see a portion of the screen at a time, it helps reduce the amount
of work they have to do to shift their gaze back and forth between
related items, and it also makes the relationship clearer to all users.
13.5. Use consistent and expected screen layouts
Customers who use software to enlarge a portion of the screen, or use a
screen review utility , cannot see the entire screen at once to get
oriented. Placing screen components such as buttons and toolbars
according to standard conventions will help these customers get familiar
with the product. It can also help screen reading software identify
status items and other components that need special handling.
For more information on layout conventions, see The Windows Interface: A
Guide for Applications.
13.6. Don't tune to a specific font
Some applications tune their dialog boxes so tightly that they look
awful if the user changes the dialog box font. Some users change this
font to make it easier for them to read, so leave enough white space in
your dialog box layouts that they can accommodate small changes in font
metrics. This will also make it easier to localize your application
into other languages.
Some developers initially fear that changing the font will completely
break their dialog boxes. but this is rarely a problem. Users typically
change only the size of the font, not the typeface, and Windows
automatically positions dialog box controls based on the size of the
dialog box font
The major places where this can be a problem is when an application
draws directly into elements of a dialog box. For example, some
applications create a static control and then draw over it to create a
custom design element--this can appear incorrectly if the size of the
static control is scaled to match a new dialog font size.
Also, some applications are now including specific fonts in their dialog
boxes, rather than relying on the system dialog box font. This is very
dangerous practice when the application does not allow the user to
adjust these font sizes. For a further discussion of these issues, see
the sections on the use of color and size earlier in this document.
14. Making sure your product is really usable
All the planning in the world will not ensure that your application is
really as accessible as it could be. There are a number of techniques
you can use to make sure you've achieved your objectives.
14.1. Test for compatibility with accessibility aids
One of the ways your application could be inaccessible is if it has
problems running with certain accessibility aids, such as screen review
utilities, screen enlarger utilities or alternative input devices.
If possible, you should try to include a sampling of such utilities in
any compatibility testing you perform. See appendix A, "Additional
Resources", to obtain a list of such vendors and their utilities.
14.2. Include accessibility sites in beta tests
The best way to find out if your product is really usable by people with
disabilities is to actively solicit their feedback. Include such people
in any beta or usability tests you run on your product, or employ them
on your staff. You can also send review copies to organizations which
represent or work with people with disabilities.
You should also try to include companies who develop accessibility aids
in your beta program. This will not only allow them to make sure their
product works with your own, but also prepare any special configuration
files or other means necessary to make the two products work well
together. To identify accessibility aid manufacturers, see Appendix A,
"Additional Resources".
14.3. Include people with disabilities in usability testing
If you perform usability testing, you can try to include subjects who
have disabilities. You do not necessarily have to design special tests
for this, but watch to see how these individuals approach and carry out
the ordinary tasks you are already testing. It can be a very
informative process helping you learn about the different ways in which
people work.
14.4. Test against the accessibility guidelines
Assign testing resources to go through this document and compare your
product against the guidelines.
14.5. Try it!
It is easy to test your application to see how well it addresses some of
the considerations discussed in this document. Some easy methods
include:
* Use your computer for a week after choosing a high contrast color
scheme in Control Panel, especially one that uses white text on a
black background such as Contrast Black. Are there any portions
of your application that become invisible or difficult to use or
recognize?
* Use your computer for a week without a mouse. Are there
operations you simply cannot perform? Was anything especially
awkward? Were the keyboard mechanisms adequately documented?
* Increase the size of your fonts using the Display property sheet.
(In Windows 3.1 edit the fonts.fon=, oemfonts.fon= and
fixedfon.fon entries in SYSTEM.INI to specify a larger font. It
is easy to test with the 8514*.fon files provided with Windows.
Does your application still look good? Can you adjust the fonts
in your application to be at least as large as the system font?
* Change the display scaling ratio using the Custom Font Size
feature in the Display property. Does your application appear
consistent or do various elements of the user interface appear
disproportionately large or small?
Appendix A. Additional Resources
A.1. General Resources
For more information on Microsoft products and services for people with
disabilities, or to obtain a listing a third-party accessibility aids
for Windows and Windows NT, or to obtain a listing of resources
available to help produce accessible documentation, contact:
Microsoft Sales
Information Center One
Microsoft Way Redmond,
WA 98052-6393
Voice
telephone: Text
telephone:
Fax:
(800) 426-9400
(800) 892-5234
(206) 635-6100
The Trace R&D Center at the University of Wisconsin-Madison produces a
book and a compact disc that describe products that help people with
disabilities use computers. The book, titled Trace ResourceBook,
provides descriptions and photographs of about 2,000 products. The
compact disc, titled CO-NET CD, provides a database of more than 18,000
products and other information for people with disabilities. It is
issued twice a year. To obtain these directories, contact:
Trace R&D Center S-151
Waisman Center 1500
Highland Avenue
Madison, WI 53705-2280
Voice telephone:
Text telephone:
Fax:
(608) 263-2309
(608) 263-5408
(608) 262-8848
For general information and recommendations on how computers can help
specific people, you should consult a trained evaluator who can best
match your needs with the available solutions. An assistive technology
program in your area will provide referrals to programs and services
that are available to you. To locate the assistive technology program
nearest you, you can contact:
National Information
System Center for
Developmental Disabilities
Benson Building University
of South Carolina
Columbia, SC 29208
Voice/text
telephone:
Fax:
(803) 777-4435
(803) 777-6058
A.2. Additional accessibility guidelines
This document is based on the white paper The Design of Software
Application Programs to Increase Their Accessibility for People with
Disabilities. That document was prepared by Gregg Vanderheiden of the
Trace R&D Center at the University of Wisconsin in conjunction with the
Information Technology Foundation (formerly ADAPSO Foundation). This
document and similar guidelines for other types of products are
available on the CO-NET CD or in print from:
Trace R&D Center S-151
Waisman Center 1500
Highland Avenue
Madison, WI 53705-2280
Voice telephone:
Text telephone:
Fax:
(608) 263-2309
(608) 263-5408
(608) 262-8848
The Windows Interface Guidelines for Software Design in the Win32
Software Development Kit and from Microsoft Press.
The Windows Interface: An Application Style Guide, published by
Microsoft Corporation and included with the Microsoft Windows Software
Development Kit version 3.1.
A.3. Customizing Windows or Windows NT
There are many ways you can adjust the appearance and behavior of
Windows or Windows NT to suit varying vision and motor abilities without
requiring any additional software or hardware. These include ways to
adjust the appearance as well as the behavior of the mouse and keyboard.
The specific methods available depend on which operating system you are
using. Application notes are available describing the specific methods
available for each operating system.
See the appropriate application note for information related to
customizing your operating system for people with disabilities.
Operating system
Application note
Microsoft Windows 3.0
WW0786.TXT
Microsoft Windows 3.1
WW0787.TXT
Microsoft Windows for
Workgroups 3.1
WG0788.TXT
Microsoft Windows NT 3.1
and 3.5
WN0789.EXE
Microsoft Windows 95
WN1062.TXT
These application notes are availabel for downloading from the following
network services:
* CompuServe(R)
* GEnie(TM)
* Microsoft OnLine
* Microsoft Download Service (MSDL), which you can reach by calling
(206) 936-6735 any time except between 1:00 A.M. and 2:30 A.M.
Pacific time. Use the following communications settings:
For this setting
Specify
Baud rate
1200, 2400, 9600, or
14400
Parity
None
Data bits
8
Stop bits
1
* Various user-group bulletin boards (such as the bulletin-board
services on the Association of PC User Groups network)
* In /SOFTLIB/MSLFILES on the Internet servers FTP.MICROSOFT.COM
and WWW.MICROSOFT.COM
People within the United States who do not have a modem can order the
Access Packs on disks by calling Microsoft Sales Information Center at
(800) 426-9400 (voice) or (800) 892-5234 (text telephone). In Canada,
you can call (905) 568-3503 or (905) 568-9641 (text telephone).
Appendix B: Documentation, packaging and support
While the majority of this document describes the process of designing
and building software, there are other aspects of producing, marketing
and supporting software products where accessibility can be addressed.
B.1. Provide documentation in alternative formats
Some customers have difficulty reading or holding conventionally printed
documentation, so documentation should also be provided in more
accessible formats such as on-line.
If the on-line documentation includes all or almost all of the
information in the printed versions, then this is not a problem as long
as that fact is made clear to the customer. It is acceptable to have
complete on-line documentation included only with a CD-ROM version of
your product, rather than on floppy disks. In either case, the user
should be able to easily determine if on-line documentation is
available, how complete it is and how to obtain it.
If the printed document contains information not available on-line in
the standard package, software vendors should allow customers to order
documentation on floppy disk. Electronic documentation is normally
provided as formatted ASCII text files, and this addresses a wide
variety of needs. For example, customers who are blind or have low
vision can then read them in their own word processor using screen
review or screen enlarger utilities, and customers with mobility
impairments can read them on-line without holding or turning the pages
of a physical book.
Documentation can also be provided in alternative formats such as large
print, Braille or audio tapes. Most companies don't provide
documentation in these formats, but you should consider licensing the
source files for your documents to users or organizations who want to
create accessible versions in these formats.
A list of resources who can provide additional information, or help in
translating or distributing your documentation in accessible format can
be found in Appendix A, "Additional Resources".
B.2. Bind documents to lie flat
Printed documentation can be bound in a large number of different ways,
but comb and spiral bindings are generally considered the most
accessible because they allow the document to lie flat. This is
important to people with motion or visual impairments; for example, a
person who is quadriplegic may lie the book flat and turn the pages with
a pencil, a person who is blind may run it through a flatbed scanner to
use optical-character recognition to convert it to an on-line format,
and a person with low vision might use a closed-caption television
system to enlarge the pages.
Generally the choice of binding is made on a purely economic basis, with
some method such as perfect (glue) binding being considerably cheaper
than other alternatives, but it is not particularly convenient for users
with disabilities. In fact, flat bindings are also preferred by people
who want to be able to type while reading.
B.3. Don't convey information by color and graphics alone
In general, accessible documentation design follows the same rules as
accessible visual design for software:
* Don't convey information by color or graphics alone. If printed
documentation relies on color or graphics to convey important
information, that information might not be available to some
customers. Some customers may rely on a variety of devices to
enlarge a document or translate it into ASCII text, speech or
Braille, and such mechanisms are often unable to preserve graphic
or color information.
* Using color and graphics redundantly to the text can often
improve documents.
For example, a reference work contains a list of function calls, giving
important information about each one. Some entries are printed in blue
ink, rather than black, in order to make it instantly obvious that they
are not supported on all systems. In this case, all the entries that
are shown in blue could also include a phrase such as "(platform
specific") in their description. If space is limited, each could simply
be marked with an asterisk. Such redundant use of information often
makes documentation easier to use for everyone.
This same mechanism could be used in cases where certain paragraphs were
called out with a graphic in the margin.
Note that modifying your text in this way will also make it easier for
you, or another organization working on your behalf, to translate your
documentation into alternative formats such as Braille or on-line
documentation.
B.4. Make packaging easy to open
Customers with mobility impairments may have trouble opening some
packages. It can be useful to examine your packaging with this in mind,
and see if they could be made easier for everyone to use. For example,
shrink-wrapped packages can have an easy-opening tab where two layers
overlap.
B.5. Provide customer support via text telephone and modem
Customers who are deaf or hard-of-hearing, or who have speech
impairments, may not be able to use standard voice telephones to access
your customer information and support services. Therefor you should
make these services available through a text telephone (also known at
TT, or TDD) and standard ASCII modems. Standalone text telephones are
available with a wide range of features, and combination TT/ASCII modems
can also be attached to standard PCs, although specialized software is
normally used to get full answering-machine functionality. See Appendix
A, "Additional Resources"for additional information, including lists of
vendors supplying text telephone hardware and software.
Appendix C: Windows 3.x Considerations
C.1. Colors in on-line help
When a help author is designing a help topic, they have the option of
specifying foreground and background colors, or of using the color
scheme chosen by the user through Control Panel. If they specify their
own color scheme, the user running Windows 3.x or Windows NT 3.x has no
way to override this and use a different set of colors, and so some
users who require high-contrast colors schemes will not be able to make
use of the help topic. (In Windows 95 the help system provides a user
option to use only Control Panel colors. However, this still leads to
having the topic appear different from the designer's preference.)
If you want your on-line help to be usable to as many customers as
possible, you should generally allow the user to choose their own color
scheme rather than hard-coding in one of your own choosing.
C.2. Testing accessibility flags
Windows 95 provides four new flags that advise applications when they
should adjust their behavior to accomodate users with disabilities.
Each can be tested using SystemParametersInfo, but this mechanism is not
supported under earlier versions of Windows or Windows NT. If you would
like to make this behavior available under earlier operating systems you
can test for these flags as WIN.INI settings. These settings are not
used by Windows itself, but can be set manually by users who want this
behavior. The recommended WIN.INI settings are shown here:
SystemParametersInfo WIN.INI setting in earlier operating systems
SPI_SHOWSOUNDS [Windows] ShowSounds=TRUE
SPI_KEYBOARDPREF [Windows] KeyboardPref=TRUE
SPI_SCREENREADER [Windows] ScreenReader=TRUE
SPI_HIGHCONTRAST [Windows] HighContrast=TRUE
(C)1993,1994,1995 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Visual Basic and Windows are registered trademarks
and Windows NT is a trademark of Microsoft Corporation.
TrueType is a registered trademark of Apple Computer, Inc.
CompuServe is a registered trademark of CompuServe, Inc.
GEnie is a trademark of General Electric Corporation.
The information contained in this document represents the current view
of Microsoft Corporation on the issues discussed as of the date of
publication. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the part
of Microsoft, and Microsoft cannot guarantee the accuracy of any
information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO
WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
This archive was generated by hypermail 2b29 : Sun Dec 02 2012 - 01:30:03 PST