- 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