- From: Charles McCathieNevile <charles@w3.org>
- Date: Wed, 19 May 1999 14:04:38 -0400 (EDT)
- To: WAI AU Guidelines <w3c-wai-au@w3.org>
(This is a lynx dump)
[1]Microsoft Accessibility Home [2]All Products | [3]Support |
[4]Search | [5]microsoft.com Home
[6]Microsoft
[7]Home
[8]Text-only Home
[9]About Accessibility & Microsoft
[10]Microsoft Products
[11]Keyboard & Product Assistance
[12]Accessibility Aids & Resources
[13]For Developers, Writers & Designers
[14]News & Events
[15]Downloads
[16]For Developers, Writers and Designers: [17]For Applications
Designers:
Checklist of Accessibility Design Guidelines
This checklist is a summary of accessibility design guidelines. For
details, see [18]The Microsoft Windows Guidelines for Accessible
Software Design. The recommendations fall into the following areas:
* [19]Keyboard Access
* [20]Exposing the Keyboard Focus
* [21]Exposing Screen Elements
* [22]Color
* [23]Size
* [24]Sound
* [25]Timings
* [26]Unexpected Side Effects
* [27]Mouse Input
* [28]Customizable User Interface
* [29]Layout
* [30]Verification
* [31]Documentation
Basic Principles
You should follow these basic principles when designing an accessible
application:
* Flexibility. Provide a flexible, customizable user interface for
your application that can accommodate the user's needs and
preferences. For example, you should allow the user to choose font
sizes, reduce visual complexity, and customize the arrangement of
menus.
* Choice of input methods. Support the user's choice of input
methods by providing keyboard access to all features and by
providing access to common tasks using simple mouse operations.
* Choice of output modalities. Support the user's choice of output
methods through the use of sound and visuals and of visual text
and graphics. You should combine these output methods redundantly
or allow the user to choose his or her preferred output method.
* Compatibility with accessibility aids. Use programming techniques
and user-interface elements that are compatible with accessibility
aids, such as blind access, screen magnification, and voice input
utilities.
* Consistency. Make your application's behavior consistent with
other Windows-based applications and with system standards. For
example, you should support Control Panel settings for colors and
sizes and use standard keyboard behavior.
Keyboard Access
Providing a good keyboard user interface is key to designing an
accessible application.
* Provide keyboard access to all features. (Logo Requirement)
* Fully document your keyboard user interface. (Logo Requirement)
* When possible, model your keyboard interface on a familiar
application or control.
* Provide underlined access keys for all menu items and controls.
* Use logical keyboard navigation order.
* If you normally hide some keyboard user interface elements,
display them when the Keyboard Preference flag is set.
* Allow the user to select text with the keyboard.
* Avoid using the GetAsynchKeyState function.
* If possible, provide customizable keyboard shortcuts.
Exposing the Keyboard Focus
Many accessibility aids need to know where the user is working.
* Expose the location of the keyboard focus within a window, either
by moving the system caret or by using Active Accessibility.
(Logo Requirement)
Exposing Screen Elements
Many accessibility aids need to identify or manipulate the objects on
the screen.
* Allow other software to identify and manipulate all screen
elements that the user interacts with, using Microsoft Active
Accessibility (which is already supported by standard window
classes and controls).
1. Ensure that every object, window, and graphic is properly
named. Define correct text labels for all controls, and give
every window a user-friendly caption, even if the text is not
visible on the screen.
2. Support the WM_GETDLGCODE message in all custom controls that
have their own window, to identify your control type and
keyboard interface.
3. Provide an alternative to any owner-drawn menus.
4. Display text using appropriate read-write edit, read-only
edit, status, static, or HTML controls.
5. Make sure that dialog boxes define the correct tab order.
6. Uniquely identify every type of window.
7. Expose names or descriptions for all images and bitmapped
text.
8. Give objects labels that are unique within their context and
are unambiguous when taken out of context.
9. If screen contents are not exposed in other ways, support
standard drawing techniques that can be monitored and
recorded. Provide alternatives to operations that directly
manipulate bitmap or screen pixels.
Color
Color should be used to enhance, emphasize, or reiterate information.
* The application must respond properly when the High Contrast
option is True. (Logo Requirement)
1. Use only colors that the user can customize, ideally through
Control Panel.
2. Use colors in their proper foreground/background
combinations.
3. Omit background images drawn behind text.
* Where possible, allow the use to customize all colors through
Control Panel or through its own user interface.
* When screen elements correspond with standard elements, use the
appropriate system colors chosen in Control Panel.
* Always use colors in their proper foreground/background
combinations.
* If possible, be prepared to draw monochrome images that contrast
with the background color.
* Avoid conveying important information by color alone, or make it
optional.
* Draw graphic objects to contrast with the current background
color.
* Provide an option to omit complex or shaded backgrounds drawn
behind text.
Size
The size of text and graphics affects usability as well as
accessibility.
* The application must be compatible with system settings for sizes
and fonts. (Logo Requirement)
* Avoid hard coding any font sizes smaller than 10 points.
* If you draw lines, determine the proper width rather than using a
fixed value.
* Allow the user to select font and font sizes for displayed
information.
* Allow the user to adjust the size of non-document elements such as
toolbars.
* Make sure the application is compatible with changes to the system
font size and the number of pixels per logical inch.
* If feasible, provide a draft mode, zoom, and wrap to window
features.
* Stretch, shrink, pad, or crop images appropriately when their
space changes.
* Avoid tuning your application too tightly to a single font.
Sound
* Do not convey important information by sound alone, or if you do,
provide an option to convey this information by visual means.
* Display important information visually when the ShowSounds option
is True.
* Provide closed captions for all audio content rendered through
DirectPlay.
* Define many custom sound events, even if they are silent in the
default sound scheme.
* Trigger standard sound events when carrying out equivalent
actions.
* If you generate sounds, provide a way to turn them off.
Timings
* Allow the user to customize all user interface timings.
* Allow the user to avoid having messages time out.
* Allow slowing down or disabling any rapid screen updates or
flashing.
Unexpected Side Effects
* Moving the mouse should not trigger unexpected side effects.
* Navigating with the keyboard should not trigger unexpected side
effects.
Mouse Input
* Applications must be compatible with specified system settings for
mouse input. (Logo Requirement)
* Provide mouse shortcuts for commonly used features.
* Make toolbars customizable.
* Emphasize simple mouse operations that require only single clicks.
Customizable User Interface
* If possible, allow the user to administrator to customize the
application to meet specific needs.
Layout
Visual design and layout can make an application more usability, and
more accessible for people with cognitive or visual impairments:
* Make it easy to recognize the label for each control or object.
1. Place a text label immediately to the left of or above its
control.
2. Do not separate a control and its label by too great a
distance.
3. Do not place unlabeled controls both to the left of and
beneath a label.
4. All text labels should end with colons, and static text
controls that do not label other controls should not end in
colons.
* Follow conventions for labeling icons, with text below or to the
right of the icon, or displayed as a tooltip.
* Try to position related objects near each other.
Verifying Accessibility
* Test the application against this guidelines checklist.
* Test with the High Contrast option and high contrast appearance
schemes.
* Test compatibility with extra-large appearance schemes.
* Verify that all features can be used without a mouse.
* Verify that all keyboard user interface methods are documented.
* Test with the Inspect Objects tool to verify that all screen
elements are exposed and properly labeled.
* Test with the Microsoft Magnifier to verify that the keyboard
focus location is properly exposed during navigation and editing.
* Test with commercial accessibility aids.
* Test with changes to the system font size and number of pixels per
logical inch.
* Include people with disabilities and accessibility software
vendors in your beta tests.
* Include people with disabilities in your usability tests.
* Conduct surveys of your users who have disabilities.
* Distribute free evaluation copies of your product to individuals
with disabilities, disability organizations, and accessibility
software vendors.
Documentation
* Provide documentation in accessible format, such as ASCII text or
HTML.
* Accessible documentation should contain descriptions of
illustrations and tables.
* Do not convey important information by color or graphics alone.
Use color and graphics redundantly to the text.
* Maintain high contrast between the text and its background.
* Do not use text smaller than 10 points in size.
* If possible, bind printed documentation to lie flat.
[32]Text-only version of this page
© 1997-1999 Microsoft Corporation. All rights reserved.
[33]Legal Notices.
Last updated on April 28, 1999.
References
1. file://localhost/enable/default.htm
2. file://localhost/isapi/gomscom.asp?target=/products/
3. file://localhost/isapi/gomscom.asp?target=/support/
4. file://localhost/isapi/gosearch.asp?target=/
5. file://localhost/isapi/gomscom.asp?target=/
6. file://localhost/isapi/gomscom.asp?target=/
7. file://localhost/enable/default.htm
8. file://localhost/enable/default-u.htm
9. file://localhost/enable/microsoft/default.htm
10. file://localhost/enable/products/default.htm
11. file://localhost/enable/products/keyboard.htm
12. http://msdnisv.microsoft.com/enable/aids/default.asp?mode=format
13. file://localhost/enable/dev/default.htm
14. file://localhost/enable/news/default.htm
15. file://localhost/enable/download/default.htm
16. file://localhost/enable/dev/default.htm
17. file://localhost/enable/dev/apps.htm
18. file://localhost/enable/download/winapp23.exe
19. file://localhost/home/charles/gl/ms.html#Keyboard
20. file://localhost/home/charles/gl/ms.html#Focus
21. file://localhost/home/charles/gl/ms.html#Elements
22. file://localhost/home/charles/gl/ms.html#Color
23. file://localhost/home/charles/gl/ms.html#Size
24. file://localhost/home/charles/gl/ms.html#Sound
25. file://localhost/home/charles/gl/ms.html#Timings
26. file://localhost/home/charles/gl/ms.html#SideEffects
27. file://localhost/home/charles/gl/ms.html#Mouse
28. file://localhost/home/charles/gl/ms.html#Customizing
29. file://localhost/home/charles/gl/ms.html#Layout
30. file://localhost/home/charles/gl/ms.html#Verification
31. file://localhost/home/charles/gl/ms.html#Documentation
32. file://localhost/home/charles/gl/ms.html
33. file://localhost/misc/cpyright.htm
--Charles McCathieNevile mailto:charles@w3.org
phone: +1 617 258 0992 http://www.w3.org/People/Charles
W3C Web Accessibility Initiative http://www.w3.org/WAI
MIT/LCS - 545 Technology sq., Cambridge MA, 02139, USA
Received on Wednesday, 19 May 1999 14:04:40 UTC