The Microsoft Windows Guidelines for Accessible Software Design Creating Applications That Are Usable by People with Disabilities Includes Concise Summary of Requirements and Recommendations May 7, 1997 Edition Please send comments or suggestions to: Accessibility and Disabilities Group One Microsoft Way Redmond, WA 98052-6399 http://microsoft.com/enable/ (c) 1993-1997 Microsoft Corporation. All rights reserved. Microsoft, MS-DOS, Visual Basic, Win32, Windows, and Windows NT are registered trademarks, and ActiveX is a trademark of Microsoft 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. Section 1 Introduction 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 for everyone to use, however, can only be realized if people with disabilities have equal access to personal computing. Microsoft(R) Windows(R) 95 and Windows NT(R) incorporate many features and enhancements designed to make computers more accessible to people with disabilities. However, applications must also follow accessible design practices to make computing in the home, schools, and workplace more accessible to everyone. This document discusses how computers can be made accessible for people with disabilities and describes how to design and produce computer software that accommodates users with disabilities. Following these guidelines can help remove barriers that prevent people from using your application. For additional information on this topic, see the Web site http://microsoft.com/enable/. Audience This document is aimed at people who design, build, test, or document software applications for the Windows 95 and Windows NT operating systems. About This Document This document contains the following sections: * Background information about disabilities, accessibility aids, and the reasons for making software accessible. * Summary of accessibility features and programming techniques. * Creating accessible applications, or how to put these guidelines into practice. * Detailed descriptions of features and programming techniques that make applications more accessible or compatible with accessibility aids. * Appendices * Additional resources for information about accessibility aids and their manufacturers * Accessible documentation * Accessible packaging * Customer service * Windows version 3. x guidelines Section 2 Summary of Recommendations This section summarizes the techniques for making software applications accessible to people with disabilities. These are described in more detail later in this document. 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). * 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. * Support the WM_GETDLGCODE message in all custom controls that have their own window, to identify your control type and keyboard interface. * Provide an alternative to any owner-drawn menus. * Display text using appropriate read-write edit, read-only edit, status, static, or HTML controls. * Make sure that dialog boxes define the correct tab order. * Uniquely identify every type of window. * Expose names or descriptions for all images and bitmapped text. * Give objects labels that are unique within their context and are unambiguous when taken out of context. * 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) * Use only colors that the user can customize, ideally through Control Panel. * Use colors in their proper foreground/background combinations. * 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. * Place a text label immediately to the left of or above its control. * Do not separate a control and its label by too great a distance. * Do not place unlabeled controls both to the left of and beneath a label. * 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. Section 3 Background on Accessibility This section provides background on accessibility, including the different types of accessibility aids available and the basic principles underlying accessibility design. This section discusses: * Reasons for accessibility * Categories of disabilities * How computers become accessible * Types of accessibility aids * What makes applications accessible Reasons for Accessibility Accessible design is important to all of us in the computer industry. It is important to you and your organization because: * It enables your application to qualify for the "Designed for Windows NT and Windows 95" Logo. The logo handbook currently lists four requirements that are designed to help make applications more accessible, and a number of recommendations that will be come requirements in future updates to the program. * It enables your business customers to comply with the Americans with Disabilities Act, which requires that they provide reasonable accommodation for employees with disabilities. Large organizations expect computer applications to accommodate all members of their staff, so failing to meet the needs of a small group of users with disabilities can affect sales to the entire organization. * It enables government agencies, schools, and organizations receiving federal funding to comply with sections 508 and 504 of the Rehabilitation Act, which requires them to purchase office equipment that is usable by people with disabilities. * It enables customers to comply with a range of other legal requirements outside of the United States, such as the Disability Discrimination Act in the United Kingdom, and upcoming legislation in the European Community. * The FCC is currently evaluating the Telecommunications Act, and may determine that it mandates certain levels of accessibility for all commercial materials distributed over the Internet. * It enables over 30 million people in the United States alone who have disabilities to use your products, along with households that include people with disabilities and the average of five friends and relatives who care deeply about each such person. * It enables employers to benefit by keeping valuable employees even when they receive a permanent or temporary disability (such as repetitive strain injury associated with typing or using a mouse), or experience functional limitations as a natural part of aging. * It enables the use of sophisticated automation tools, including testing tools, task automation tools such as intelligent agents, and new input methods such as voice input. Such tools function exactly like accessibility aids. * It enables your customers to purchase software that meets standards for usability, such as HFES/ANSI 200 and ISO 9241. Such standards are currently in draft form and will probably incorporate high-level requirements for accessibility. * And of course, it is simply the right thing to do. When each individual can live, work, study, and play independently, each can make his or her maximum contribution to society. Categories of Disabilities Individuals are not disabled-rather some people have difficulties performing certain tasks, such as using a mouse or reading small print. When these limitations 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 * Mobility impairments * Cognitive and language impairments * Seizure disorders * Speech impairments These categories describe groups of disabilities covering a broad range of people with widely different levels of need. Visual impairments Visual impairments range from slightly reduced visual acuity to total blindness. Millions of people have vision that is only slightly impaired. They find it difficult to read small print or black text on a gray background, or they experience eyestrain at the end of long computing sessions. These individuals usually do not consider themselves to have a disability, but computing can be a more comfortable and less frustrating experience if applications accommodate their needs. People whose vision cannot be corrected to better than about 20/80 are described as having low vision. They probably require text to be larger than normal, and they often require a higher contrast between foreground text and the background. When people's vision cannot be corrected well enough to rely on visual information alone - that is, about 20/200 or higher - they are generally considered to be blind and require displayed information to be converted into spoken text or Braille. Other types of visual impairments include reduced field of vision, a condition that limits a person's focus to only a small area at time, and color blindness, a condition that makes it difficult or impossible for a person to distinguish certain color combinations. Color blindness affects nearly 10% of males and 1% of females. Hearing impairments Some people cannot hear or distinguish different beeps, or recognize spoken words. They may require a program to prompt them in a different manner - for example, through a screen flash or spoken messages displayed as text. Anyone can find themselves in this situation when working in a very noisy environment, working in a quiet environment (such as a library) where sound would disturb other people, or working on a machine with broken or missing speakers. Mobility impairments Some users are unable to perform certain manual tasks, such as using a mouse or typing two keys at the same time. Others may have a tendency to hit multiple keys, "bounce" fingers off keys, or be unable to hold a printed book. Many users need 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 loss, perceptual differences, and developmental disabilities. Language impairments, such as dyslexia or illiteracy, are also very common. Even people learning the language used by their computer software as a second language can be considered to have a form of language impairment. Proper software design can help increase the number of people with mild cognitive and language impairments who can use computers. It can also help children learning to read. Seizure disorders People with some forms of epilepsy may experience minor or severe seizures when they see images change rapidly or at certain rates, or hear certain types of random or repetitive sounds. Speech impairments Computers can be a great benefit to people who have difficulty speaking, allowing them to communicate with others easily and fluently through electronic mail, postings, and online chat. They can also type or select words and have them spoken aloud through synthesized speech. Although difficulty speaking does not normally affect a person's ability to use a computer today, it can be a problem in using telecommunications and voice menus. Difficulty speaking may affect normal computer usage more if voice recognition becomes a common form of input in the future. How Computers Become Accessible A few simple steps can greatly increase the number of people who can use your application. Accessibility means designing computer software to accommodate a wide range of users, including users with disabilities. Although no software can be accessible to everyone, a few simple steps can greatly increase the number of people who can use your application. Special needs can be addressed in the following ways: * New features can be built into hardware and operating systems that help make them more 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 most or all "well-behaved" applications. * Accessibility aids can modify the system to make it usable by more people. These aids work with most applications, but they are not available when the user moves to a new computer, they are often expensive, and many people who could benefit from such aids never obtain them. * Specialized applications, such as word processors, can be optimized for people with specific disabilities. For example, there are Internet browsers designed to read pages to people who are blind, and some word processors integrate voice and text to help individuals with limited reading and writing skills. A few of these applications are available, but in general, people with disabilities need to use mainstream applications to cooperate with their coworkers and to take advantage of the latest mainstream features. * Usability features can be built into mainstream applications, making them easier for people with disabilities to use. Examples include customizable colors and access keys, which can only be provided by the application itself. Often, these features also benefit people who do not have disabilities. Mainstream applications also need to be compatible with accessibility aids. Types of Accessibility Aids The following sections describe some of the more common types of accessibility aids-utilities that are added to a computer to make it more accessible to people with certain disabilities. Not all people with disabilities use tools like these, but they are critical for those who do, and their effectiveness depends on the cooperation of application software. Try out some of these utilities, many of which are available free on the World Wide Web. You can try out some of these utilities, many of which are available free on the World Wide Web. For a catalog of accessibility aids, see http://microsoft.com/enable/. Screen enlargement utilities A screen enlarger (also called a screen magnifier or large print program) is a utility that allows the user to magnify a portion of his or her screen, turning the computer monitor into a window that shows a portion of an enlarged virtual display. An enlarger needs to track where the user is working, so it can automatically keep the active area in view. The user can also use mouse or keyboard commands to move the window to view different areas of the virtual display. Screen review utilities People who are blind or have reading difficulties rely on screen review utilities (also called a blind-access utilities, or screen readers). A screen review utility takes the information displayed visually on the screen and makes it available through alternative, nonvisual media, such as synthesized speech or a refreshable Braille display. Because both of those media present only text, not graphics, the utility needs to render screen elements as text - for example, by assigning a user-friendly name to each control or graphic object. The utility also needs to track what the user is doing and the location of the focus to be able to describe the important aspects of what is happening on the screen. Blind-access utilities automatically announce some things when they change on the screen, or when the keyboard focus moves to a new word, control, or window. Other information will be read when the user requests it. For example, pressing a shortcut key might cause the aid to describe where the user is working, such as "Cancel push button, Open dialog box, Excel". Imagine having the computer speak and tell you-or a child-what it's doing People who have dyslexia or other reading difficulties use similar tools, often called reading aids. These might read a word or when the user points to it with the mouse, or read an entire document. In graphical environments such as Windows, these utilities gather information by a variety of means. Some information is available through the Win32(R) API, such as window messages supported by standard windows and controls. Other information is intentionally provided by the application itself, using protocols like Microsoft Active Accessibility. As a last resort, some utilities watch all operations that draw information to the screen and try to infer its meaning. Voice input utilities People with severe mobility impairments often use voice input utilities (also called speech recognition programs) to control the computer with their voice instead of the mouse and keyboard. However, most people using voice input do not have disabilities, using the products simply to boost their productivity or because they work in a situation where their hands are busy. Like screen review utilities, voice input utilities need to identify and manipulate objects on the screen, so the user can activate objects with a single phrase. On-screen keyboards Some people cannot use a standard keyboard, but can use other input methods, such as switches or pointing devices. On-screen keyboard utilities display a list of commands and let the user to choose and execute those commands using a variety of input methods. They often display a set of keys that the user can point at or click to choose commands, activate objects, or type into the computer. Utilities can also let the user choose commands using one or more switches. If a single-switch system is used, an on-screen keyboard successively highlights groups of commands until the user selects one group by pressing a switch. Then the utility successively highlights smaller groups of commands within the selected group until the user selects the specific command to run. If a user can point but not click, he or she can activate a command using a head pointer by pausing the pointer over the command for a certain amount of time. An on-screen keyboard is also commonly used to display buttons with all the commands available at a given time. To display them, the utility needs to identify, name, and activate controls much the way a voice input utility does. Keyboard filters Individuals with impaired dexterity may have difficulty using a standard keyboard, but keyboard filters built into Windows can help compensate for erratic motion, tremors, slow response time, and similar conditions. These corrections are harder to make for pointing devices like a mouse, so users with impaired dexterity usually rely on the keyboard. For information about these options, see the Accessibility Options section in the Windows Control Panel. Other types of keyboard filters include typing aids, such as word prediction and abbreviation expansion utilities, and add-on spelling checkers. People who don't have disabilities are increasingly using these utilities to improve their typing speed and accuracy. What Makes Applications Accessible Two things contribute to the accessibility of an application: * End-user features that make the application more usable * Programming techniques that make the application compatible with accessibility aids. The guidelines in this document address both types of needs. Section 4 Creating Accessible Applications This section describes the general procedure for creating accessible applications: * The product development cycle * Basic principles of accessible design * Prioritizing potential tasks The Product Development Cycle Generally, the process of creating an application can be divided up into different phases, or tasks, and accessibility can be addressed in each phase. Accessibility can be addressed throughout the product development process Planning * Gathering Customer Feedback. You can include people with disabilities, and organizations who employ them, in your feedback process. For more information, see "Verifying Accessibility" later in this document. * Market Analysis. The process of deciding on the high-level goals for this product. In this phase you should take into account the factors described in "Reasons for Accessibility", earlier in this document. * Writing Specifications. During the feature design phase, you should consider whether new features may positively or negatively affect users with disabilities. We recommend that this be called out in each feature specification. Testing * Testing Previous Versions. During the planning phase you should evaluate the accessibility of your current version, in order to help identify and prioritize enhancements for the next version. * Internal Testing. If you train your testing staff to recognize accessibility issues, they can identify problems quite easily. You can allocate specific time for this type of testing, or it can be factored into general testing of the product's features. In particular, assign one or more testers to make a pass through your product, comparing it with these guidelines. It also helps to track which issues are of especially importance to users with disabilities. * Usability testing. If you perform usability testing, try including subjects who have disabilities. You do not necessarily have to design special tests for these subjects, but you should watch to see how these individuals approach and perform 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. * Beta testing. Include people with disabilities and developers of accessibility aids in any field or beta tests you run on your product. Implementation * Coding. During the actual coding phase, individual programmers and designers can make decisions that unintentionally build in barriers to accessibility. You can avoid this by making sure your staff has at least a basic familiarity with these guidelines. * Fixing Bugs. When it becomes necessary to prioritize bugs for fixing, take into account that some bugs are of especial importance to users with disabilities, out of proportion to their impact on the average user. * Documenting. Ways to address accessibility in the documentation process are discussed in the "Accessible Documentation" appendix. Customer Service * Technical Support and Customer Service. Ways to help work more effectively with your customers with disabilities are discussed in an appendix to this document. The key is to identify issues, prioritize them, and address those that you reasonably can Basic Principles It is impossible for any written guidelines to cover every situation, so it is worth restating the basic principles that underlie accessible design: * Flexible, customizable user interfaces 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. * Be compatible with accessibility aids, such as blind-access, screen magnification, and voice input utilities. This is achieved by using standard programming techniques and user-interface elements, or by supporting Active Accessibility. * 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. * 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. * Consistency with other Windows-based applications and with system standards makes it easier for users to learn and use the application. It also ensures that you support system accessibility features. For example, you should support Control Panel settings for colors and sizes and use standard keyboard behavior. By keeping these principles in mind and by following the specific recommendations in this document, you should be able to address most issues encountered when designing an application for accessibility. Prioritizing Only you can determine how these recommendations apply to your application, and their priorities The guidelines discussed in this document are not hard and fast rules. However, it is recommended that you adapt or adopt as many as you can to your own applications, or find additional ways to achieve the same goals. To help you prioritize issues, we have used a star rating to indicate the relative important of each item in the detailed guidelines section of this document. However, as a designer, only you can determine the priorities for your own application. The key is the process: * Determine which of the areas your application is already handling correctly and which remain problems. * Decide which problems you can address in the version of your application currently under development. * When you start on the next version of your application, design in corrections to any remaining problems. In this way, you can demonstrate your desire to do "the right thing" in the near term and make a considerable difference in the long term. When prioritizing features, we recommend you take the following factors into account: * Number of users. Give higher priority to features that affect large number of users. Generally, features related to viewing documents affect more people than those related to authoring documents. * Frequency of use. Give higher priority to features that are used frequently by those customers who use them. * Urgency of use. Give higher priority to features that are an integral and necessary part of the product, rather than optional or ease-of-use features. Section 5 Detailed Design Guidelines This section includes detailed discussions of the individual guidelines. Specific requirements and recommendations are called out in boxes. Each guideline box shows you at a glance the priority of the recommendation, and what types of disabilities it affects. Priority is rated from zero to four stars (), based on the number of people affected, how severely it affects their ability to use the software, and how easy it is for applications to handle it correctly. Comments and summaries are occasionally called out in italic type. This section discusses recommendations in the following areas: * Keyboard Access * Exposing the Keyboard Focus * Exposing Screen Elements * Color * Size * Sound * Timings * Unexpected Side Effects * Mouse Input * Customizable User Interface * Layout Keyboard Access Provide keyboard access to all features. * The keyboard user interface must be fully documented. Logo Requirement Blindness Dexterity All applications should be designed so that mice are not required for their use. Providing a good keyboard interface is one of the most important and most visible aspects of software accessibility, because it affects users with a wide range of disabilities. It is also a usability feature for many people who do not have disabilities. Benefits * Blindness: Users of blind access utilities rely almost entirely on the keyboard rather than a pointing device, especially for moving in free space. Often it is clear to a sighted user how to manipulate objects using the mouse, but it is not clear to blind access utilities. * Dexterity: Many people with impaired dexterity can use the keyboard with software adjustments, but cannot use pointing devices. Also, many people cannot use a mouse because of repetitive strain injuries. Users relying on voice-input, keyboard macro packages, or on-screen keyboard utilities also find it impossible or extremely cumbersome to simulate mouse input. * General Usability: Many experienced typists prefer to leave their hands on the keyboard, rather than switching back and forth between keyboard and mouse. In addition, pointing devices on laptop computers can be inconvenient to use, and a working mouse may not always be available. Choosing a Keyboard Interface The key to defining a good keyboard interface is to adapt models already familiar to the user. To accomplish that, you should make the interface keystroke-compatible with other familiar applications or controls. The Microsoft Windows Keyboard Guide documents the keyboard user interface conventions used and recommended for Windows-based applications. This can serve as a valuable reference when designing any keyboard user interface. You can download this document from http://microsoft.com/enable/. Here are some examples showing how the user can move and resize objects using the keyboard: * Menus and Dialog Boxes. Menus are one of the most common and standardized user interface elements. Putting commands on the menu is always a safe option. However, doing so consistently may make menus large and unwieldy. To prevent these types of problems, you can provide a default configuration that hides most of the menu items for your application's commands and only shows them when the user explicitly requests them through an option in your application or when the user sets the Keyboard Preference flag in Control Panel (discussed later in this document). It is usually possible to provide dialog boxes or property sheets with the same functionality used by the mouse. * Property Sheets. The user can directly manipulate controls to adjust their location and size using the object's property sheet. This method is used by the Microsoft Visual Basic(R) programming system. The following examples show some navigational techniques that you may be able to adopt and adapt to your application: * Move and Size Commands. Most windows have Move and Size commands on their system menu, which enable the user to perform those operations using the keyboard. The same commands with the same user interface can also be provided for application-specific objects, either on the normal menu bar or on the object's context menu. * Navigating Between Objects. Windows Help uses a common method for navigating between objects. Windows Help allows the user to press the TAB key to move the focus through a list of "hot spots" or active regions, and to press the ENTER key to choose the currently selected active region. The SHIFT+TAB key combination is used to move backwards through the list, and arrow keys are used to move in specific directions (this capability is especially useful if the items are arranged in two dimensions). An application using this method can also allow the user to type one or more letters to move to the next active region whose label starts with those letters, much like the user can move through entries in a standard list box. * Navigating Between Window Areas. Some applications divide their window into two or more panes, separate areas showing different information that the user can move between using a simple keystroke. For example, Windows Explorer can display a single window with three panes. The TAB key or the SHIFT+TAB key combination moves the focus between the panes (that is, the tree view pane, the folder pane, and the tool bar), and the arrow keys move the focus around within a pane. Multiple Document Interface (MDI) follows another convention, the use of the F6 key and the CTRL+F6 key combination to move the focus between panes and child windows; it also presents a list of windows and allows the user to move between them using the Windows menu. Some applications use the CTRL+TAB or CTRL+PAGE DOWN key combination to shift through groups of panes or pages. Exceptions for Keyboard Access Usable keyboard access should be provided for all features in an application, but it is not always possible. In some cases, it might be too cumbersome for users to use and too challenging for the application designers to implement, especially if the particular feature being considered will be used only occasionally. There are also rare cases where a dialog box is so complex that unique access keys cannot be assigned. In these cases, common sense should dictate where tradeoffs need to be made. Users can fall back on tools that enable them to simulate mouse input using the keyboard or other input mechanism, but these tools should not be considered a substitute for good keyboard interface design. For example, a simple drag and drop operation might require 40 or more keystrokes. Operations using that many keystrokes might make an application accessible, but it would certainly not be considered usable or user-friendly. In any case, a user who is blind might still find it difficult to perform such a visual operation using keystrokes. Application designers can design efficient, comprehensive keyboard interfaces for their applications and should make every effort to do so. Documenting the Keyboard Interface Fully document the keyboard user interface. * You do not need to document accepted Windows conventions. Logo Requirement Blindness Dexterity Complete documentation for the keyboard user interface should be included with an application. If an application provides keyboard commands and mechanisms, but lacks appropriate documentation for them, the features become essentially useless. If space is a problem, the keyboard interface can be described in another place, and cross-references to the information can be included in the primary documentation. However, keyboard access should not be categorized as a niche or specialty feature, because it is used and relied on by so many people. It is not necessary to document elements that simply follow the accepted Windows conventions, such as standard menus and controls. Underlined Access Keys Provide underlined access keys for all menus and controls. * Only required when the Keyboard Preference options is True. * Not required when names change dynamically or no unique characters remain unused. Future Logo Requirement Blindness Dexterity Underlined letters on a menu or control, known as access keys (also called shortcut keys or quick-access characters), should exist for all menu items and controls. The following illustration shows some access keys on a File menu. [Illustration redundant to the text.] Once users become familiar with an application, they become more likely to use access keys to speed up common operations. This tendency is even more common among users who do not use a mouse, including those who are blind. For example, screen review utilities present the user interface sequentially, so a user has to press the TAB key and read or listen to find out what he or she has reached before deciding whether to press the TAB key again. This mechanism slows down the process of locating the correct destination and makes use of access keys much more attractive. You can omit access keys in these two situations: * There are not any unused characters in the label to use. In this case, you can either rename the control or omit the access key, depending on how often or how repetitively the command will be used. An example is the standard Sort Options dialog box; it has identical sets of controls for each of the three sort criteria, which makes it difficult to assign unique access keys to each. * The set of commands is very dynamic and cannot be predicted by the user. For example, the standard OK, Cancel, and Apply buttons used in all property sheets cannot be allowed to conflict with controls on a particular page. Because there is no way to predict what controls might be on a page, access keys are not provided for the standard buttons. Another example is a context menu whose commands might vary from one instance to another. Context menu commands can have access keys 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 a particular instance it triggers another. Another benefit of providing access keys for dialog box controls is that it ensures that a static text control immediately precedes the object it is labeling in the tab order; this ordering helps screen review utilities determine the relationship between the control and its object. Proper Navigation Order Use logical keyboard navigation order. * Normally this is left-to-right and top-to-bottom. Blindness Dexterity Cognitive A logical keyboard navigation order should be used to ensure that dialog boxes and similar groups of objects can be traversed in a logical order using the keyboard, 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 navigate using the keyboard. It is especially confusing for people who are blind and rely on screen review utilities. Users who are blind explore a dialog box sequentially, instead of scanning the entire box as sighted users would, so random tab order can make the dialog box nearly unusable. The Keyboard Preference Flag If keyboard methods are normally hidden, display them when the Keyboard Preference option is True. | Dexterity Cognitive The Keyboard Preference option in Control Panel indicates that the user relies on the keyboard instead of the mouse Users who rely on the keyboard benefit from seeing underlined access keys and other hints and reminders about the keyboard shortcuts that are available. This also helps individuals with cognitive disabilities who may have difficulty remembering the shortcuts. An application that normally hides some keyboard user interface elements or omits some keyboard mechanisms altogether should present them when the Keyboard Preference flag is set. This flag, which is set by the user in Control Panel, advises an application that the user relies on the keyboard rather than a pointing device, so additional support should be provided where appropriate. An application can test for this flag by calling the SystemParametersInfo function with the SPI_GETKEYBOARDPREF value. Selecting Text Allow the user to select text with the keyboard. * Use appropriate controls for displaying text. Dexterity Choosing the proper text control can improve the keyboard access to your application as well as its compatibility with accessibility aids. To choose a control that is appropriate for the user's interaction with the information, follow these guidelines: * Static Controls. Use static controls only for labeling other controls. In the illustration that follows, the words "Server:," "Comment:," and "Current Users:" identify accompanying controls and are displayed as static controls. * Read-Write Edit Controls. Use read-write edit controls for values that the user can edit directly. In the illustration that follows, the server name is an edit control that starts with a default value, which the user can freely change. Read-write edit controls should always have visible borders. * Read-Only Edit Controls. Use read-only edit controls for values or descriptions that the user cannot edit. Always use read-only rather than static text controls, except when labeling other controls. In the illustration that follows, the comment about the server is represented by a read-only edit control, which allows the user to select the text and copy it to the clipboard or to drag it to another document. This control should be included in the tab order so that a user can navigate to it using the keyboard. (Note that the label for read-only edit controls is not required to have underlined access keys.) * Status Controls. Use status controls from the common controls library to display values that may change dynamically as the user watches. In the illustration that follows, the number of current users can change. In addition to being consistent with other applications, these controls provide information to screen review utilities, which may notify the user when values change. * HTML Controls. Use the standard Windows HTML control whenever you need to display richly formatted text. The following illustration shows the static, read-only edit, write-only edit, and status controls described in the preceding list. [Illustration redundant to the text.] Reading the Keyboard State Avoid using the GetAsynchKeyState function. | Dexterity Avoid using the GetAsynchKeyState function to retrieve the state of a key or a mouse button, except when absolutely necessary. This function queries the hardware driver to determine the physical key or button state, but ignores any keys being artificially held down or simulated by accessibility aids. When possible, you should use the GetKeyState function, which correctly reflects any simulated input. GetAsynchKeyState can, however, be called in certain cases, such as when the user types a key to interrupt a lengthy processing task. When handling mouse drag operations, you should avoid using GetAsynchKeyState to detect when a mouse button has been lifted. Instead, you should use the SetCapture function and wait for a button-up message. If you use GetAsynchKeyState, the results might differ from those obtained using other Windows functions and messages. This can cause your application to behave inconsistently with other software on the system. Customizable Keyboard Shortcuts If possible, provide customizable keyboard shortcuts. | Recommendation Only Dexterity Customizable menus and shortcut keys can be a great convenience for users who type slowly Allowing the user to customize keyboard shortcuts can make the application much easier to use. For example, users who enter keystrokes slowly (either through the keyboard or other input devices) can benefit from assigning simple key combinations to lengthy, repetitive tasks. * Customizable shortcut keys allow the use to assign a key combination to commands they use frequently. * Customizable menus can provide easy keyboard access. You can allow the user to add their own commands, or supply a selection of menus with different levels of complexity, such as novice, intermediate, and advanced menu configurations. * Keyboard macros can provide the greatest flexibility, by allowing one to execute multiple commands with a single keystroke. Exposing the Keyboard Focus Expose the location of the keyboard focus within a window. * Automatic for objects that are separate windows. * Within a window, use Active Accessibility or move the system caret to cover the object's bounding rectangle. Logo Requirement Blindness Low Vision Dexterity Cognitive Language Many accessibility aids need to identify the "focus point" where the user is working. For example, blind-access utilities describe the text or object that the user is working on, and screen-magnification utilities pan to enlarge whatever is at that portion of the screen. Utilities also rearrange windows to avoid covering up "where the action is." Sometimes it is easy for an accessibility aid to determine this location; the operating system tells them when the focus moves to a window, menu, or standard control. It is more difficult to determine the location when an application uses its own method of indicating the visual focus within its window, such as highlighting a cell in a spreadsheet, an icon, or a windowless custom control. In these cases, to be accessible, the application must make its focus location available to other programs in the system. It can do this using Active Accessibility, or by moving the system caret; both methods are described in more detail below. Benefits * Blindness: Screen review utilities need to be able to describe objects as the user creates, selects, or manipulate them, and describe the context in which the user is working. * Low vision: Screen magnification utilities need to pan to keep the keyboard focus in view. * Dexterity: Voice input and on-screen keyboard utilities need to know the commands available, which are dependent on the focus context. * Cognitive/Language: Reading aids for people with dyslexia or who are learning to read need to read or highlight words as the user types, selects, or manipulates them. Using Standard Windows and Controls Standard windows and controls already expose the keyboard focus Windows informs accessibility aids when windows get or lose the keyboard focus. It does this using Active Accessibility, Windows hooks, and window messages. This also applies to standard Windows controls, each of which has its own window. Therefore no additional work is required for standard Windows controls, or objects that occupy the entirety of a window. Using Active Accessibility to Expose the Focus Microsoft Active Accessibility is the preferred method of exposing the keyboard focus location. The application must call NotifyWinEvent whenever the focus moves to an object that does not correspond to an entire window. It must handle the WM_GETOBJECT message when that is used to query the focus object. COM objects representing screen elements must also support the accSelection property. For more information on Active Accessibility, see http://microsoft.com/enable/. Using the System Caret to Expose the Focus It is easy-and harmless-to expose the focus location by moving the system caret The system caret is the blinking vertical bar that the user sees when editing text, but it can be placed anywhere on the screen, made any shape or size, and even made invisible. If it is invisible, it can be moved to indicate the focus location to applications without disturbing what the user sees on the screen. Making the system caret invisible is easy: simply call the CreateCaret function to set the caret's size and shape and the SetCaretPos function to move it to wherever you are drawing the visual focus indicator (the highlighted cell, icon, button, and so on). Note that it is present but invisible, unless you explicitly make it visible. Each time the focus moves to a new object with a different size, the application should call DestroyCaret and then use CreateCaret to specify the size of the new object. The system caret must cover the bounding rectangle of the screen element, so that screen magnification tools can allow the user to zoom-in on the left, right, An application should only display focus and selection indicators when they are in the active window. When the window loses activation, the application should remove the visual indicator and also call the DestroyCaret function. (For Win32 applications, this step is not strictly necessary, but is still good practice.) Examples of Keyboard Focus Location Sometimes it may seem hard to decide what to indicate as the focus location. Extended and discontiguous selection often confuse the issue, but the keyboard focus location should be considered independent of selection, even if an application normally links the two. The following examples may clarify the distinction and help you learn to identify and indicate the keyboard focus location in your own application: * Insertion bars in text. When the user moves an insertion point within text, it is usually drawn with the real system caret. If the application chooses to draw its own insertion point, it should still move the system caret invisibly, tracking the location and size of the visible insertion bar. * Extended text selection. When the user makes an extended selection, one end of the selection is always the "active" or moving end, and that is the actual location of the keyboard focus. For example, to select three characters, you start with the insertion bar in an edit control, and then hold down the SHIFT key while pressing the right arrow twice. The end where you started is the "anchor," the stationary end; at the right, you should see the flashing caret marking the active end. If you hold down the SHIFT key and press another arrow key, it is the active end that moves, and that is where the system caret should be placed. You should display a visible insertion bar at the active end, because that is useful feedback for all users. * On graphic objects. When a user moves the keyboard focus to a graphic object, such as an icon or a bitmap, an application should place the system caret invisibly over the same object so that the caret's rectangle covers the entire image. If there is an adjacent label, the caret should cover that as well. * Within graphic objects. Sometimes, an application uses a single bitmap to represent several objects, such as a group of graphical buttons. The application usually indicates the focus by highlighting a portion of the bitmap, drawing a dotted rectangle over it, or even moving the mouse pointer. In addition to indicating the focus, the application should also place the system caret invisibly over the region of the bitmap that corresponds with the "hot spot" or object being referenced. * Simple controls. If an application is drawing simple custom controls, such as a custom push button, the keyboard focus is associated with the entire control, so the entire control should be covered by the system caret. (This is necessary only for windowless custom controls. If the control is a window, the window takes the keyboard focus, so it is not necessary to identify it using the system caret.) * Complex controls. A complex or composite control, such as a list box, can place the focus on individual elements within the larger control. In this case, an application should use the system caret to indicate the area of the particular item that has the focus. Even though the application might think of the collection of items as a single control, they should be treated as separate control elements when they are identified to external components. * Spreadsheets. When the user navigates within a spreadsheet, the focus is usually placed on an entire cell, rather than on content within the cell. Often, this is indicated by a bold cell border, and the application should place the system caret over the entire cell. If the user begins editing the contents of a cell, the application should indicate the focus appropriately for the content text or graphics. * Discontiguous selection. Discontiguous selection is usually supported among discrete items, rather than in text. There is always one item that has the keyboard focus or was most recently clicked by the mouse, and that object should be covered by the system caret. To see an example, select an item in a folder or in File Manager, and then hold down the CTRL key while pressing arrow keys to move the focus rectangle to a file that is not part of the selection. * Mouse-only objects. Although applications should provide keyboard access to all their functionality, some objects can only be manipulated or selected using the mouse. In this case, you should treat the object when it is selected as if it received the keyboard focus and use the system caret appropriately to indicate that it has the focus. Of course, if the real keyboard focus moves, you should follow it, because the mouse-only object is no longer the object of the user's attention. Verification The easiest way to verify this behavior is to use the Magnifier accessory included with the Active Accessibility SDK. This will be a standard accessory with future versions of Windows and Windows NT. Use your application with the keyboard and make sure that the place where you are working appears, magnified, in the Magnifier window. You can download the Active Accessibility SDK from http://microsoft.com/enable/. Exposing Screen Elements Allow other software to identify and manipulate all screen elements that the user interacts with. * Standard window classes and controls automatically support this mechanism. * Applications only need to add additional support when creating custom window classes or controls, or drawing content in their window client area. * Ensure that every object, window, and graphic is properly named. Future Logo Requirement Blindness Dexterity Cognitive Many types of accessibility aids need to identify or manipulate the objects on the screen. This includes discrete objects such as windows, controls, and menus, as well as documents elements such as words, paragraphs, images, worksheets, and tables. For example, a sighted user can usually identify controls by their appearance, but users who are blind rely on screen review utilities to describe objects in words. These utilities present the user with the name, type, and state of each control. For example, after the user has tabbed to a check box, a utility might say "Quick Printing check box, checked." Voice input utilities and on-screen keyboards have similar requirements; they need to identify and name specific controls and manipulate the control in response to the user's commands. Accessibility aids gather information about controls by looking at their window class. Standard controls also support Active Accessibility, which exposes all the relevant information through a single standard interface. However, use of nonstandard controls can render an application completely unusable for users who rely on accessibility aids unless care is taken to maintain compatibility. Screen review utilities have the additional problem of understanding a document's contents in order to communicate them to the user. This includes a document aloud, and also describing to the user where they are working within the document. For example, in a spreadsheet the sighted user can glance at the headings for rows and columns to identify the current cell, but a blind-access utility would need to speak "C5". In this case, a cell functions as a custom control embedded in a table, which itself functions as a very complex custom control. Benefits * Blindness: Blind-access utilities need to be able to describe objects on the screen, including the selection. They also need to describe the context of each item, and sometimes provide alternative user interface for manipulating these objects. * Dexterity: Voice-input and on-screen keyboard utilities need to be able to present the user with the names of command and objects they can manipulate, and activate those objects when the names are spoken or chosen from a list. * Cognitive/Language: Voice input utilities need to be able to present the names of command and activate them when the names are selected. Reading aids need to vocalize or highlight names, words, and phrases on the screen. Utilities for people with cognitive disabilities may add additional information to the screen, identifying or explaining objects, or may even hide or alter objects to reduce the complexity of the screen. Using Controls Nonstandard controls can render applications completely unusable by users with disabilities unless care or additional steps are taken In the following sections we will provide more detail on working with the following types of screen elements: * Standard Windows controls, including Windows common controls. * Owner-drawn controls, which behave like standard controls, but have a customized appearance. * Superclassed standard controls, which add customized behavior to a standard Windows control. * Custom controls, which are implemented by an application without using the normal Windows mechanisms. This includes Visual Basic, ActiveX, and Java controls. * Owner-drawn menus, which behave like normal menus but have customized appearance. * Text control, both in controls and in document areas. Using Standard Windows Controls Whenever possible, use standard Windows controls and those provided by the Windows Common Controls library, because they are fully 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 control. The aid can determine the control's window class, and that tells the aid what additional messages it can send to the control to query or alter the state. The aid can also identify all of the child controls contained within a parent window and identify the parent of any control. Use standard controls where possible, because the are fully compatible with accessibility aids Many of the Common Controls, such as the list view and tree view controls, are extremely flexible and can be used to replace a variety of custom and owner-drawn controls. For example, a list view can replace a list box that is owner-drawn in order to show a check box next to each item, and the new enhanced button control can display images as well as text, which used to be a common use for custom controls. Using Owner-Drawn Controls Owner-drawn controls can be accessible as long as care is taken in their use. Although owner-drawn controls behave like standard controls, they have a customized appearance. Some applications use custom controls to change the appearance of a control, but owner-drawn controls are a more accessible solution. For example, an application might use an owner-drawn control to display a check box with an actual check mark instead of an X, or to label a push button with a picture instead of a word. Using a standard Windows control with the owner-drawn style makes the control appear normal to accessibility aids and still supports Active Accessibility, but still allows the application to give control elements a customized appearance. Make sure you label owner-drawn controls, even if the label isn't visible You should define the label for all owner-drawn controls, even when the label will not be visible on the screen. If you create an owner-drawn control in which the normal caption will not be visible (for example, a button with a graphic face) and leave the caption as a blank string, the accessibility aid will not be able to get the caption and use it to identify the control. You should make sure that your owner-drawn control handles all the other class-specific text retrieval messages, such as CB_GETKBTEXT, LB_GETTEXT, and so on, and set the appropriate style bits (such as LBS_HASSTRINGS) to indicate that the owner-drawn control supports those messages. Using Superclassed Controls Some applications alter the behavior of standard controls through a technique known as superclassing. When an application uses superclassed standard controls, the application can add it's own special behavior, but basic control functions are still handled by the underlying system code for the standard control type, which continues to support Active Accessibility. Make sure that the superclassed controls respond to the normal messages for their class. As with owner-drawn controls, make sure you properly label each control, even if the label will not be visible on the screen. These steps allow the control to successfully support Active Accessibility. Using Custom Controls The term custom controls including ActiveX controls, Java controls, and many other shared and private mechanisms for displaying information or interacting with the user. Unfortunately, accessibility aids may have difficulty manipulating these custom controls, identifying their name, role, state, and location, and whether they have the keyboard focus or selection. Active Accessibility is the way to make custom controls compatible with accessibility aids Active Accessibility is the only effective way to make custom controls compatible with accessibility aids. That, in fact, is the primary reason for its existence. If you cannot support Active Accessibility at this time, the following steps can help make a control more compatible, but not fully compatible, with accessibility aids: * If the custom control has its own window, you can return a descriptive string when the control is queried using the WM_GETTEXT message. For example, a control that appears as a button with the label Print could return the string "Print button" to convey both the control type and the label. The same string would be appropriate if the control looked like a button, but had a graphic showing a printer rather than a textual label. Likewise, a custom control that behaves like a check box could return a caption string "Printing Enabled check box, checked." * If the custom controls has its own window, you should support the WM_GETDLGCODE message, which identifies the keyboard input that is supported and also the equivalent standard control if there is one. * If the custom control has no window, you can convey the focus location to accessibility aids by moving the system caret as described previously in "Visual Focus." Using Owner-Drawn Menus Owner-drawn menus are incompatible with most types of accessibility aids that need to identify the name of each menu item. Therefore, you should always provide an option to replace graphical menus with standard, textual menus when an accessibility aid is active. You can test this by calling SystemParametersInfo with the SPI_GETSCREENREADER option. Always provide an alternative to owner-drawn menus People with cognitive disabilities can also benefit from the option to show text instead of, or in addition to, menu graphics. For example, a menu item for selecting line width might display a sample of a line followed by text stating the width. This redundancy is also be useful for people trying to follow a written standards that spell out specific values. We recommend you make this the default, or allow the user to choose the text-menus option. This is the choice made by Microsoft Developer Studio. Using text and graphics to reinforce each other is the best solution for many users The following illustration contrasts the use of an owner-drawn menu using text and graphics with the use of a standard menu using only text. [Illustration redundant to the text] Using Text Controls Screen review utilities need to understand the text on the screen and in a document. Text is normally displayed using the Windows drawing functions, or by copying images directly to the screen, or by using one of many available text controls. Text controls are the easiest way to present rich or plain text that's compatible with accessibility aids The most accessible way to present text is to use one of the many text controls available that are fully compatible with accessibility aids. These include the standard Windows edit, static, status, and HTML controls, all of which use Active Accessibility to expose their text to accessibility aids. The HTML control is the best and easiest solution for displaying richly formatted text. Any of these can be used without a visible border, to seamlessly fit into your user interface. Choosing the proper text control can improve the keyboard access to your application as well as its compatibility with accessibility aids. For more information, see "Selecting Text" in the Keyboard section of this document. If you use graphic images that contain text, see "Identifying Images and Bitmapped Text" in this document. Using Dialog Boxes When using Windows dialog boxes, it is important to label all controls. Some types of controls, such as buttons, have their own textual labels. Accessibility aids have no trouble identifying these controls. However, objects such as edit controls, list boxes, and graphical objects are typically labeled by placing a static text control nearby. In order to expose the relationship between a control and the static text that labels it, the static text must immediately precede the named control in the dialog box TAB order. Defining the correct tab order in a dialog box provides a number of substantial and surprising benefits Correct tab order also allows the static text control to define an underlined access key for the control it labels, and of course, all controls should have those as well. Naming Windows Give every window a user-friendly caption, whether or not it is visible on the screen, so that accessibility aids can identify the window to the user. Give every window a user-friendly caption, even if the text is not visible on the screen Every window can have a caption, whether or not it has a visible caption bar. You set this string in your resource script, when calling CreateWindow or related functions, or by calling SetWindowText. Accessibility aids can then query the caption using Active Accessibility or the WM_GETTEXT message. This applies to all windows - not only top-level windows with visible frames, but also to child windows such as floating palettes, custom controls, toolbars, and panes within the a window when they are implemented as child windows. Identifying Windows by Function You should uniquely identify each type of window, either by using Active Accessibility or by giving them unique window classes. This identification should not change over time or between languages. You should uniquely identify each type of window Accessibility aids need this information to customize their handling of different windows within the same application. These aids may have separate instructions for handling these windows, such as announcing specific areas whenever the contents changes. While a human being can identify a window by its caption, accessibility aids need an identifier that won't change between documents or languages. Identifying Images and Bitmapped Text Exposing names or descriptions for all images helps users who are blind or have reading impairments Screen review utilities need to describe images to the user. This is especially important for images that convey important information or have bitmapped text. This is only required when a screen review utility is running, which can be determined by calling SystemParametersInfo with the SPI_GETSCREENREADER value. There are several ways to convey this information: * Use Active Accessibility to expose the name and description of each image. * Use the standard Windows tooltip control to apply a label to each image giving a name or a brief description. * Provide an option to replace the image with text. It is worth noting that Microsoft Internet Explorer supports all three mechanisms. Images that the user can manipulate should be treated like controls; for more information see "Identifying Images and Bitmapped Text" in this document. Labeling Objects Clearly When possible, label controls and other objects with names that make sense when taken out of context Users who have tunnel vision or use screen magnifiers can see an object and perhaps its immediate surroundings, while a blind user examining an object will have only its name, its type, and the name of the window and any group box it is in. They will not have any of the context provided by spatial arrangements. * Label objects with names that make sense when taken out of context. Labels do not have to be long and detailed, but should be descriptive. * Avoid having multiple objects with the same name; for example, two buttons with the same name on the same dialog. * If you cannot avoid duplicate names, place the objects in separate containers. For example, dialog box controls with the same name should be enclosed in separate group boxes with unique names. To see an example of handling multiple controls with the same name, display Keyboard page in the Accessibility Options section of Control Panel. Drawing to the Screen If screen contents are not exposed in other ways, support standard drawing techniques that can be monitored and recorded Ideally you should be exposing each window's contents using Active Accessibility or one the other methods described above. If you cannot do that, the steps described here can provide some degree of compatibility with screen review utilities. When an application doesn't support the mechanisms described earlier, screen review utilities attempt to infer what it's doing by watching calls to drawing functions and remembering what text and graphics have been drawn and where, and attributes such as font, size, color, and style. They also watch information being copied from one location to another and being erased or overwritten by other text or graphics. These utilities rely on being able to monitor normal Windows drawing operations. When possible, use the following techniques, or provide an option to do so: * Draw text using the standard Windows function calls, such as ExtTextOut, which can be seen by screen review utilities. * Use standard Windows functions to copy or erase text and graphics. These include BitBlt, PatBlt, and StretchBlt. This is true whether drawing is to a screen or to an off-screen bitmap, because utilities track the text and graphics from the time they are drawn until they are copied to the screen. * Avoid directly manipulating bitmaps. Some applications directly manipulate the memory associated with a DC, bypassing the Windows functions altogether. In these cases screen review utilities are not aware of the changes taking place. For example, if an application draws text into a bitmap using a Windows function call and then later erases it by clearing the bitmap memory, the screen review utility will assume 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 is no longer visible. Similarly, information copied from one bitmap to another without using the Windows functions may be displayed visually but unseen by the screen review utility. * Avoid directly modifying the screen. The Windows application programming interface (API) provides several means of manipulating bitmap or display pixels directly, such as DirectDraw, Display Control Interface (DCI), WinG, and the CreateDIBSection function. If your application uses any of these techniques for performance, you should also use conventional methods when a screen review utility is running. You can determine this by calling the SystemParametersInfo function with the SPI_GETSCREENREADER value. Verification Use the Inspect Objects tool included with the Active Accessibility SDK. Hover the mouse pointer over portions of your application and see if the tool can display a proper description. Compare it with standard windows and controls and see if they match. You should also test with real accessibility aids to see if they work properly with your application. Many utilities are available at no charge or in trial versions. For a catalog of these tools, see http://microsoft.com/enable/. Color The use of color can greatly enhance a user interface, but only if it is used appropriately. In general, your application should not convey information by color alone, because some people will not be able to see it. Use color only to enhance, emphasize, or reiterate information shown by other means. Most importantly, respond to the High Contrast setting in Control Panel, which indicates that the user needs visuals altered for greater legibility. Benefits * Blindness: blind access utilities need to be able to describe the selection and focus to the user. * Low vision: screen magnification utilities need to pan to keep the keyboard focus in view. * Dexterity: alternative input utilities need to know the commands available, which are dependent on the focus context. * Cognitive/Language: reading aids for people with dyslexia need to read or highlight words with selection or focus. High Contrast Mode When the High Contrast options is set, * Display only system colors selected through Control Panel or other colors that the user can customize. * Because documents are typically shared, a user must not be required to alter a document in order to adjust the colors drawn on the screen. * System colors must be used in their proper foreground/background combinations. * Omit background images drawn behind text. Logo Requirement High Contrast mode is one of the most important means of accommodating users with visual impairments An application that uses standard system colors or allows the user to choose colors that are not defined by the system has its basic color needs covered. However, this is not always appropriate for the default configuration. This is why the use can set the High Contrast option in Control Panel to indicate when they need high legibility. Required steps * Use only colors that the user can customize through Control Panel or through the application's own view options. Because document are often shared, it is not acceptable to make the user change a document in order to display it in different colors. * Use colors in their proper foreground/background combinations. * Omit background images or other complex backgrounds behind text and controls. Additional recommendations * Supplement any information that would normally be conveyed by color alone, with text, graphics, or patterns. * Draw images in monochrome instead of multiple colors, and draw them using standard foreground and background colors. * Replace application-specific colors with colors selected through Control Panel, and try to use as few color combinations as possible. Exceptions * Palettes where the user selects a color may continue to display their full range of fixed colors. * Applications are not responsible for changing the appearance of third-party controls or embedded objects, unless they ship those objects with their product. Hints * Applications can check for this setting by calling the SystemParametersInfo function with the SPI_GETHIGHCONTRAST value. Applications should query this value during initialization and when processing WM_COLORCHANGE messages. * Call GetSysColors to identify the colors chosen through Control Panel. Making Colors Customizable Allow the user to customize all colors, either through Control Panel or through your own user interface For many people, color is a matter of preference, but it is critical for many users with visual impairments. Many people require a reasonably high contrast between text and the background to be able to read. They may even need a particular scheme, such as white text on a black background, to 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. Some applications use fixed colors to prevent the user from selecting an "ugly" color scheme that would make the application look unattractive. However, a user will not complain about a color scheme that he or she chooses, but may about a fixed color scheme. Using Control Panel Colors Use colors selected through Control Panel where appropriate When possible, an application should use the standard system colors that the user has selected through Control Panel. This is easiest to accomplish when an element in the application's window corresponds to a usage handled by Control Panel, such as window text, button face, dialog box text, and so on. 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 you ensure that your application's colors are pleasing to the user without having to provide a user interface for adjusting colors. For a complete list of system colors, see the description of the GetSysColors function in the Microsoft Win32 Software Development Kit (SDK). Your use of the color and the use selected in Control Panel do not need to correspond exactly. For example, the user's choice of window text color and background is probably a safe combination to use for any purpose. Using Private Colors Allow the user to customize colors that are private to your application If you use colors for elements that do not correspond to system colors selected in Control Panel, you should provide your own means for adjusting the colors. For example, if you design a calendar application that uses different background colors to indicate various types of events, allow the user to select the colors used. If you cannot provide a user interface for customizing colors, support a registry key that selects the colors and provide a .REG file that the user can edit to adjust these settings. Using Proper Color Combinations Always use colors in proper foreground/background combinations Your application should always use system colors in their proper foreground-background combinations to ensure that they have reasonable contrast. The user will never choose a button text color that is the same as the button face color, so these will always be legible when used together. However, the user may alter the color scheme so that system colors that normally contrast, such as button text and window background, might be the same color on their systems. If your application draws using colors that are not specifically designed to be used in combination, the information may be completely invisible. Your application should 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 text on a white background, causes the background to "bleed" over the foreground. This combination can make reading difficult, or even painful, for some users. The following list shows some combinations that are safe to use and others that are not. Combination | Status Window Text on Window Background | Safe Button Text on Button Face | Safe Window Text on Button Face | Mixing unrelated colors is unsafe Button Text on Window Background | Mixing unrelated colors is unsafe Window Background on Window Text | Reversing colors is unsafe Button Face on Button Text | Reversing colors is unsafe The same rules apply when using private colors that the user can select in your application. Draw foreground objects in colors the user has selected for the foreground, and background objects in colors selected for the background. Coloring Graphic Objects When possible, be prepared to draw monochrome images that contrast with the background color Graphical objects present special challenges. For example, some application display buttons that have pictures on them instead of, or in addition to, text. Do the colors selected in Control Panel apply to this case? Monochrome images are easy. The button face should always be drawn in the standard system color (the COLOR_BTNFACE or COLOR_3DFACE button value), and the foreground image should be drawn in the standard button text color (the COLOR_BTNTEXT button value). If the image is drawn inside a window rather than on a button, it is more appropriate to use the COLOR_WINDOW and COLOR_WINDOWTEXT values instead of the button colors. Multicolored images present more problems. The easiest solution is to include a monochrome image that can be used on monochrome displays or that can be used when the user has chosen a nondefault button face color or has requested High Contrast Mode (described later in this document). If you cannot include monochrome images, you can try creating them on the fly from the multicolored images by identifying light and dark areas as foreground and background. For example, a bitmap that has a multicolored object on a white background could be mapped with all colors other than white in the appropriate system foreground color and with white in the system background color. These colors could be reversed for images designed with a dark background. Information Conveyed by Color Alone Avoid conveying important information by color alone. * Or, provide an option to convey this information by other means. Recommendation Blindness Low Vision Always provide an alternative to conveying information by color alone If your application conveys information by color alone, some users will not be able to make use of the information. Even allowing the user to customize the colors is insufficient if the user can only read white text on a black background or if the user is using a hand-held computer with a monochrome display. For these situations, the application should also make the information available through a means other than color, even when the user can choose the colors. One option is to provide patterns as an alternative to colors. In the case of the calendar application, users could be allowed to choose a pattern along with the color for each type of scheduled event. They could choose a color combination that works for their eyes and supply any additional information as a background pattern. This option works best when the pattern fills an object without interfering with the text. Backgrounds that Obscure Text Drawing text on a plain, contrasting background makes it much easier to read Text is most legible when drawn against a plain background of a contrasting color. Text drawn over a varied background, such as a wash of colors or a bitmap, may be illegible for many viewers, so you should always provide the user with the option to omit the image and revert to a plain background. * Provide a menu or dialog box option to omit complex backgrounds. * Omit the background in response to the High Contrast setting, which is discussed earlier in this section. * Omit the background if the foreground color changes or consists of mixed colors. For example, text drawn over a very light bitmap image might appear quite legible in the default color scheme, but be unreadable if the user chooses a light foreground text color. * Use backgrounds that contrast well with the text. For example, many users will find it hard to read black text drawn over gray, brown, or other dark backgrounds. This applies whenever you use backgrounds, even if you provide an option to omit them. Remember, small fonts and insufficient contrast are among the most frequent complaints to come out of usability testing. Size Some people like to fit a maximum amount of information onto a single screen, but millions of users have difficulty reading small text, seeing small objects, or targeting small objects with the mouse. Therefore you should be flexible when sizing objects on the screen. Benefits * Low Vision: Individuals with low vision usually require text and objects to be decently large, or in some cases very large, to be seen clearly. Note that the majority of users with visual impairments do not use screen magnification tools. * Dexterity: The larger an object on the screen, the easier it is for everyone to manipulate it. Individuals with impaired dexterity may need to have the object even larger than average. (Providing good keyboard access can mitigate these problems.) * Mainstream: Small fonts cause eye-strain and can make reading difficult or impossible for many people who do not have disabilities. To these users small sizes represent failed usability. Screen elements with fixed sizes may also be too small on high-resolution displays, or exceed the screen size on small, hand-held computers. System Size Settings The application must be compatible with specific system settings for sizes and fonts. | Logo Requirement Dexterity Low Vision Adjustable sizes increase the usability of any application It is important that applications drawing their own screen elements pick up the size settings that the user has selected in Control Panel. For example, a private dialog box manager that draws custom dialog boxes should use the dialog box font that the user has selected for the rest of the system. The same principle applies for scroll bars, custom menus, and so on. In order to qualify for the "Designed for Windows NT and Windows 95 Logo", applications must be compatible with the following system settings for font and size: Required Size Settings | SM_CYFIXEDFRAME | SM_CXFIXEDFRAME SM_CYDLGFRAME | SM_CXDLGFRAME SM_CYMENUSIZE | SM_CXMENUSIZE SM_CYSIZEFRAME | SM_CXSIZEFRAME SM_CYFRAME | SM_CXFRAME SM_CYVSCROLL | SM_CXVSCROLL SM_CYMENU | SM_CYCAPTION SPI_GETICONTITLELOGFONT | SM_CYSMCAPTION SPI_GETNONCLIENTMETRICS | SPI_GETBORDER SPI_GETWORKAREA | In addition to the required system settings listed above, applications should be compatible with the following recommended system size settings when applicable. Recommended Size Settings | SM_CXICONSPACING | SM_CYICONSPACING SM_CXMENUCHECK | SM_CYMENUCHECK SPI_ICONHORIZONTALSPACING | SPI_ICONVERTICALSPACING SM_CXICON | SM_CYICON SM_CXSIZE | SM_CYSIZE SM_CXSMSIZE | SM_CYSMSIZE SPI_GETICONTITLEWRAP | SPI_GETICONMETRICS For further information on these settings, see descriptions of the GetSystemMetrics and SystemParametersInfo functions in the Win32 SDK. Verification From the Appearance page in the Display section of Control Panel, choose the "Windows Default (extra-large)" appearance scheme. Then try using your computer normally. Are there any portions of your application that do not reflect the size settings? Is information cut off improperly? Is your application still usable? Avoiding Small Fixed Fonts Avoid hard coding any font sizes smaller than 10 points. | Future Logo Requirement Low Vision Remember, small fonts can cause eyestrain and are difficult for many people to read. Line Width Do not hard-code lines to be one pixel thick Although many applications draw lines with a fixed width of one pixel, those lines disappear on high-resolution monitors. They may also be invisible to a person with low vision. Instead of using fixed widths, applications should determine the proper thickness of a line by calling the GetSystemMetrics function with the SM_CXBORDER and SM_CYBORDER values. These values are defined appropriately for the resolution of the monitor, and in future operating systems the user will also be able to adjust them appropriately for their vision. Making Fonts Adjustable Allowing users to choose font face and size greatly increases their satisfaction The best way to satisfy users who prefer small type and those who require larger type is to allow them 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. Call ChooseFont to display the standard Font dialog box. When the application draws its text, it should use the font that the user has requested. If the font selection makes information extend beyond the edge of the window, make the window resizable and display scroll bars. A second approach is to automatically resize the fonts when the user resizes the window, but this prevents the user from selecting a large font in a small window with scroll bars. Scaling Non-document Regions If possible, allow the user to adjust the sizes of toolbar buttons and other non-document elements Many application windows contain two types of information: an image of a document created by the user and one or more panes belonging to the application itself. Buttons, rulers, toolbars, palettes, navigation bars, and status bars can also pose problems for people if the objects are of a fixed size. If possible, allow the user to independently select a size or zoom ratio for each type of non-document region. For example, a "Toolbar Size" option could let the user select the size of all toolbar buttons. Global Scaling The application should be compatible with changes to the system font size and changes to the number of pixels per logical inch. * Avoid drawing with the MM_TEXT mode. * Stretch, shrink, pad, or crop images to fit the available space. Future Logo Requirement Dexterity Low Vision Windows 95 provides a Custom Font Size feature in the Display section of Control Panel. This lets the user globally scale all fonts and most other visual elements on the screen by changing the number of pixels used to represent a "logical inch." 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 element will be drawn out of proportion to all the rest of the screen elements. It is important to note that bitmaps are not automatically scaled by this factor. Bitmaps are discussed in the section "Adjusting Images for Different Sizes," below. Alternatives to WYSIWYG Draft mode, zoom, and wrap to window features can greatly help many users 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 it will have on the printed page. While this is good for some tasks, it is not always appropriate or desired. Some people may want to print text in a tiny font, but not edit it when it is that small. It is easy to allow the user to adjust the size of information on the screen through several methods, such as draft and zoom modes: * Draft mode means providing an option to display all text in a single font and size. If possible, allow the user to choose the draft font and size. Use underlining or a similar form of highlighting to indicate text that should be drawn with special formatting, such as bold or italics. (Draft mode also improves performance when running on slow systems or with little free memory.) * Zoom features scale everything in the document to a user-selected ratio. Many applications, such as Microsoft Word and Microsoft Excel, offer this feature, and it benefits many users who do not consider themselves to have disabilities. Use of the TrueType scalable font technology ensures that characters will remain clearly defined at almost any size. * Wrap to window options are helpful when displaying text documents. When the user chooses this option, the application should not break lines on the screen as they would appear on the printed page. breaks as tand instead flow each paragraph They allow the user to ignore normal line breaks Adjusting Images for Different Sizes Stretch, shrink, pad, or crop images to fit different amounts of space Sometimes a graphic image needs to fit a different space than was originally intended. For example, a user may adjust the global scaling constant using the Custom Font Size feature, or an application might allow the user to choose a differently sized font. In these cases, an application might draw an image that appears out of scale with the rest of the window. You should handle these situations by changing the way the bitmap is drawn to the screen, or by using an alternative to bitmaps. Accommodating bitmaps when changing size Several methods can be used to accommodate a bitmap to differently sized regions: * Stretch or shrink it. You can scale your bitmap "at run time" using the StretchBlt function so that it will be sized appropriately for its screen location. * Pad it. If you do not stretch your bitmap for an enlarged space, you can draw it at its normal size and leave blank space around it. However, to ensure that the region around your bitmap does not have unrelated, older information lying around, you should erase the region to the appropriate background color. You should 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. * Crop it. If you do not shrink your bitmap to fit a smaller space, you should 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%. You should 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. Alternatives to bitmaps The following alternatives can be used in place of bitmaps, which can more easily adjust to different amounts of space: * Metafiles are a convenient way to encapsulate an image for easy playback. They can automatically be scaled to fit the destination rectangle and normally look good at almost any size. * Drawing on the fly. If the image is simple and you do not need to encapsulate it for easy storage and playback, you can create a routine that draws it on the fly using Windows graphic functions. * TrueType glyphs can represent the image. This solution can be expensive if the expertise to create glyphs is not available in-house. Custom TrueType glyphs will not be recognized by an accessibility aid, so you should label the graphic using the techniques described earlier in "Identifying Images and Bitmapped Text" in this document. Avoiding Font Dependencies Avoid tuning your application too tightly to a single font Some applications space their dialog boxes so tightly that they look unattractive if the user changes the dialog box font. Some users change the font to make the dialog box easier to read, so you should leave enough white space in your dialog box layouts that they can accommodate small changes in font metrics. Extra white space also makes an application easier to localize into other languages. Some developers fear that a change of 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 primary case where changing fonts 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 element can appear incorrectly if the size of the static control is scaled to match a new dialog box font size. However, the application can determine the proper location and size at run time to avoid these problems. Some applications now include specific fonts in their dialog boxes rather than relying on the system dialog box font. It is a dangerous practice, however, to not allow the user to adjust those font sizes. You may want to let the user select this font, or change its size to match the currently selected system font. For more information about these issues, see the sections on "Color" and "Size" in this document. Sound Proper use of sound can benefit people with a range of disabilities, but applications should not convey important information by sound alone. The user may be deaf or hard-of-hearing, or may be using the computer in a very noisy environment such as an airplane or workshop, or may be in a quiet environment where it is inappropriate for the computer to be making sounds. Benefits * Blindness: Additional audible cues can help blind individuals use applications more easily and efficiently; the application can often provide better cues to supplement a generic blind access utility. * Hearing: Individuals who are deaf or hard-of-hearing require information to be displayed visually, even if it would normally be presented by sound alone. They may also want to turn off the sound to avoid disturbing people in their surroundings. * Cognitive/Language: Redundant use of sound and visuals can assist people with some cognitive disabilities. Presenting text as spoken words can also help people with reading impairments, or who are learning to read. Alternatives to Sound Do not convey important information by sound alone. * Or, provide an option to convey this information by visual means. * Display all important information visually when the ShowSounds option is True. * Do not automatically turn off sounds. * Provide closed captions or transcripts for all audio content. Future Logo Requirement Hearing Cognitive Language Applications should not convey important information by sound alone. The user may be deaf or hard-of-hearing, or may be using the computer in a very noisy environment such as an airplane or workshop, or may be in a quiet environment where it is inappropriate for the computer to be making sounds. If the application does convey information by sound alone in the default configuration, provide an option to convey the information by visual means as well. Supporting the ShowSounds Option The ShowSounds option means the user needs all information displayed visually The user can choose the ShowSounds option from the Accessibility section of Control Panel to indicate that he or she needs important information displayed by visual means. When it is set, the application should display all information visually rather than by audio means alone. In effect, it asks applications to display the equivalent of closed captions for their sounds. Applications can check the ShowSounds flag by calling the SystemParametersInfo function with the SPI_GETSHOWSOUNDS value. Use of the ShowSounds flag does not mean that sounds cannot be presented normally. In fact, redundant use of sound and visuals generally increases the usability of an application. The user should be able to request visual feedback independently of whether they want audible feedback. The ShowSounds flag is only applicable to applications that would normally present important information by sound alone. The application is responsible for determining how to convey the information in visual form. Examples in the following sections can help you determine behavior appropriate to your situation. Types of Sounds Applications make sounds for a variety of reasons. We can divide these up into four general categories: * Important sounds, which convey information that is not presented visually and which is important to the operation of the application. Examples include an audio wave file with narrative instructions or a sound notifying the user that new mail has arrived. * Redundant alerts, which accompany a visual presentation of information, yet serve an additional purpose of 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 message box. * Redundant sounds, which repeat information already presented visually and are not required for proper operation of the application. An example is an error sound or beep that is heard when the user tries to move beyond the end of a list box. * Decorative sounds, which enhance the appearance or presentation of an application, but are not required for its operation. Examples include the sound effects that accompany minimizing a window or activating a menu and background sounds and music used to establish a mood in many multimedia games. The user who cannot hear redundant or decorative sounds is not disadvantaged, but the first two types of sound, important sounds and redundant alerts, do require special attention. For redundant alerts, the user can rely on the SoundSentry feature in the Windows operating systems. This 95 and other utilities displays a generic visual indicator have the capability to detect when the computer is making noise and to display a generic visual indicator to the user. This feature is referred to as "SoundSentry." This feature works reasonably well in cases where the sound is just a generic beep that is warning the user or trying to attract his or her attention. However, it is insufficient when of limited use with applications that use different sounds to convey more complex information. These Conveying important sounds and complex information requires the cooperation from of the application. Playing Audible Alerts To attract the user's attention, such as when new email arrives, an application might use the following techniques: * Flash its title bar by using the FlashWindow function. If the window is not visible, the function will automatically flash the application's button on the taskbar. * Display a message box that acquires the activation and keyboard focus. This technique 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. This indicator should also flash when initially displayed to help attract the user's attention. Playing Redundant Sounds Applications often make a sound to indicate an error status - for example, when the user types an invalid character. In these cases, the application might flash its title bar by using the FlashWindow function. If the window is not visible, it will automatically flash the application's button on the taskbar. Displaying Closed Captions for Video and Audio Provide closed captions or transcripts of all audio content-it's easy using DirectPlay Applications that display multimedia animation, video clips, or audio clips should support the ShowSounds flag with true closed captioning. Captioning is only necessary if the video clip has an audio track containing important information. There are four approaches to closed captioning: * Microsoft DirectPlay (formerly known as ActiveMovie 2.0) makes it easy to create and display closed captions for many types of digital media. For more information, see http://microsoft.com/directx/. * Microsoft Video for Windows, an older technology, supports creating a separate, synchronized data stream for captioning information, although the application is responsible for displaying the information on the screen. * Private mechanisms can be developed for applications that use their own technologies to play multimedia content. * Transcripts of audio content can be displayed separately, not synchronized with the audio track. This is fine for short audio pieces, but is not a good solution for longer pieces or pieces where the sound and video and closely integrated. Making Sounds Customizable Trigger as many sound events as possible, even if they are silent by default Through Control Panel, the user can associate sounds-or not sound-with specific events such as an error, warning, or selecting a menu item. Windows automatically plays these sounds when carrying out the associated event. This method lets users customize the sound scheme to play more or fewer sounds, as they prefer. Applications should call PlaySound to trigger sound events: * Always play sounds by specifying a registry entry. (Use the SND_ALIAS value.). This allows the user to customize the sound through Control Panel, and accessibility aids can use the name provided in the registry to describe the event to the user. * Trigger standard sound events when carrying out equivalent actions. For example, if you display the equivalent of an urgent message box, play the SND_ALIAS_SYSTEMEXCLAMATION event. This makes your application more consistent with the Windows environment. * Define as many application-specific sound events as possible. You can have most of your events generate no sounds by default, but the user who desires additional feedback can use Control Panel to add appropriate sounds. This is especially useful for people with visual and some types of cognitive impairments. * Avoid specifying sounds by filename or resource, because these cannot be customized through Control Panel, and because accessibility aids cannot determine the meaning of these sounds. For more information about playing sounds, see, "Playing Sounds Specified in the Registry," in the Win32 Software Development Kit (SDK). Reinforcing Sounds and Visuals Sound and visuals are most effective when they reinforce each another Redundant use of sound and visuals generally increases the usability of an application. For example, a status indicator on the screen can generate an audible cue when it changes. Similarly, a sound played when starting a particular application or Web page should be accompanied by some printed words or graphics. The user should be able to request visual feedback independently of whether they want audible feedback. Turning Off Sounds Provide an option to turn off your application's sounds You should give the user the option to turn off sounds that your application makes, because sounds can be distracting or annoying for some people, such as those who are deaf or hard-of-hearing, or be inappropriate 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. People who are deaf or hard-of-hearing also appreciate this so they can avoid unintentionally annoying people around them. 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, the user has chosen to turn off the standard system beep, and you can infer that they also want other sounds turned off as well. Sounds played by calling PlaySound and specifying a registry-based sound event do not require any additional work, because the user can turn off these sounds by changing the sound scheme in Control Panel. Timings Allow the user to customize user interface timings. * Provide an option to avoid having messages time out. * Allow slowing down or disabling any rapid screen updates or flashing. Future Logo Requirement Blindness Low Vision Dexterity Cognitive Language Some people have difficulty reading information if it is only displayed briefly, or performing tasks that require quick reflexes. Therefore, any timed behavior should be adjustable by the user. Benefits * Blindness: Blind individuals often respond more slowly because of delays imposed by their accessibility aids; it takes them longer to find and read prompts. * Low Vision: Individuals with low vision often respond more slowly because they can only see a small portion of the screen at a time, so it may take them longer to see or read prompts. * Cognitive/Language: Individuals with cognitive or language disabilities may read slowly, so it may take them longer to read prompts. Some may take longer to decide the correct response. * Seizures: Screen elements flashing at inappropriate rates can sometimes trigger epileptic seizures in susceptible individuals. Input Timings Let the use adjust timing requirements to compensate for slow reaction time Some individuals have relatively slow reaction times, and have difficulty using features that rely on fixed timings. Examples include automatic scrolling that takes place when the user drags towards the edge of a window or holds down the mouse button over a scroll bar. Another example, some applications react when the keyboard focus remains on an object for more than a fraction of a second, which can greatly inconvenience anyone who navigates more slowly than the average user. There are several ways to adjust your timing parameters: * Use a system setting. Your application can tie its own timed behavior to some related setting the user can specify through Control Panel. Examples of settings related to input timing include double-click speed and the time focus remains on a cascading menu before the child menu is displayed. * Provide a timing option. Your application can provide a menu or dialog box option to adjust the timing. The settings should be stored in the user-preferences section of the registry. * Provide a registry setting. If you cannot provide a user interface to allow the user to customize timings, support the option using a registry key and provide a .REG file that can edit to adjust this setting. Time Limits Avoid having messages time out, or provide an option to prevent them from timing out You should also avoid having messages time out. If you use time-outs, provide an option to disable them. There are many reasons why a user may not spot a message that is only displayed for a brief period of time. For example, some people read slowly because of lack of practice, cognitive disabilities, or because they are working in a second language. Users who rely on screen magnification utilities may take a while finding the information on the screen. Users may also take longer to respond because of impaired dexterity. If a message is important, you should display it until the user consciously dismisses it. Even if the message is unimportant, it is disconcerting to have the message disappear before it can be read, and how can the user know it was unimportant if he or she did not have a chance to read it? Rapid Flashing Allow the user to slow down or disable any rapid screen updates or flashing. | Recommendation Seizures Allow the user to slow down or disable any rapid screen updates or flashing Rapid visual changes can cause epileptic seizures in susceptible individuals. This includes flashing a visual signal on and off, or repeatedly changing between different images. Because individuals vary so greatly, it is impossible to totally remove the risk of triggering some seizures. However, certain steps can help reduce the risk of triggering seizures. * Avoid flashing very rapidly. Greater speeds can affect more people, especially when changing more than five times per second. * Avoid flashing large areas. Small areas, such as the flashing insertion bar, are less likely to trigger seizures than larger areas that flash. * Avoid high contrast. Reducing the difference in brightness between different states may help reduce the risk of seizures. * Provide an option to slow down or stop flashing. This is the recommended solution. * Avoid large number of changes on the screen at once. In some cases many objects changing rapidly and without synchronization can have the same effect as a large image flashing much more rapidly. There are several ways to let the user adjust the speed at which objects flash: * Caret blink rate. An easy solution is to flash objects at the caret blink rate, which the user can adjust through Control Panel. You can query this setting by calling GetCaretBlinkTime. * Provide a timing option. Your application can provide a menu or dialog box option to adjust the timing. The settings should be stored in the user-preferences section of the registry. * Provide a registry setting. If you cannot provide a user interface to allow the user to customize timings, support the option using a registry key and provide a .REG file that can edit to adjust this setting. Unexpected Side Effects Allow the user to move the mouse or navigate with the keyboard without triggering unexpected side effects. | Future Logo Requirement Blindness Low Vision Dexterity Cognitive Some users who rely on accessibility aids must move the mouse or keyboard focus to explore the information on the screen. Such action should not triggering unexpected side effects. Benefits * Blindness: Because blind users cannot perceive the entire screen at once, unexpected events on the screen would often go unnoticed or be disorienting. * Low Vision: Because users relying on screen enlargers cannot perceive the entire screen at once, unexpected events on the screen would often go unnoticed or be disorienting. * Dexterity: Many users need to minimize the number of keystrokes they type, so unexpected side effects to keyboard navigation can add to that number-sometimes considerably-and be a source of additional pain and frustration. * Cognitive/Language: Unexpected side effects may be very confusing to users with some types of cognitive disabilities. Side Effects of Mouse Movement Moving the mouse pointer should not have unexpected side effects You should avoid having events triggered by movements of the mouse pointer over or off a special area. If you must include triggering, you should make it optional. Some accessibility aids require the mouse pointer to move when information is explored on the screen. For example, a screen review utility may move the mouse to follow words being read, or a user may need to move the mouse to enlarge certain text. If text appears when the mouse moves over an object and disappears when the mouse moves off of it, the text essentially disappears each time the user tries to read it! There are two cases where it is acceptable to trigger changes based on mouse pointer movement, because these cases are already understood by accessibility aids and handled appropriately: * Pointer shape. It is acceptable to change the shape of the mouse pointer as it is moved. For example, you can change the shape to indicate whether or not an object is a valid drop target. * Tooltips. It is acceptable, and in fact encouraged, to use tooltip controls to display explanatory information when the pointer is paused over an object. However, this is only the case if a standard tooltip control is used. Side Effects of Keyboard Focus Movement Navigating with the keyboard should not have unexpected side effects You should avoid having events triggered by movements of the keyboard focus. However, if you must include triggering, you should make it optional. To enable the user to "read" or explore a window's contents, you should support keyboard mechanisms that allow the focus to change to a control or area without causing problems. For example, it is typical for a user who is blind to use the TAB key to move through all the controls in a dialog box as a means of exploring it before he or she goes back and does any actual work. There are exceptions to this rule, primarily in cases where application behavior has been standardized and mechanisms exist for accessibility aids to work appropriately: * Explanatory text. It is acceptable to display explanatory text that gives details about the function of a menu while menu messages are being processed. It is preferable to draw this text in a status bar to be consistent with other applications, but any text drawn during menu processing will be assumed to serve this function. * Radio buttons. It is acceptable to automatically change the value of option controls (radio buttons) and tab controls during keyboard navigation. Although this behavgior can cause problems for keyboard users, it is necessary for backwards compatibility. * Providing alternatives. An application that takes action when the focus moves should provide an alternative way to move the focus. This is typically done by using the CTRL key to modify the navigation key. For example, in Windows Explorer or in a list box that supports discontiguous selection, the user can move the focus and change the selection when navigating with an arrow key. However, the user can move the focus without changing the selection by holding down the CTRL key when he or she presses the arrow key. This is supported by radio buttons in Microsoft Office. Mouse Input Applications should not require the use of the mouse, but good mouse support can make applications easier to use for many people. Benefits * Dexterity: Individuals who can use a pointing device but not a keyboard find it easiest to use features with mouse shortcuts. * Cognitive/Language: Many individuals find it easier to point-and-click and directly manipulate visible objects than to memorize keyboard equivalents. System Mouse Settings Applications must be compatible with specified system setting for mouse input. | Logo Requirement Dexterity In order to qualify for the "Designed for Windows NT and Windows 95 Logo", applications must be compatible with the following system settings for mouse input: Required Mouse Settings | SM_CYDOUBLECLK | SM_CXDOUBLECLK SM_CYDRAG | SM_CXDRAG In addition, it is recommended, but not required, that the application comply with the following system settings: Recommended Mouse Settings | SPI_GETMOUSEHOVERHEIGHT | SPI_GETMOUSEHOVERTIME SPI_GETMOUSEHOVERWIDTH | SM_SWAPBUTTON Good Mouse Shortcuts Well-designed mouse shortcuts benefit nearly everyone The following steps make it easier for people to use your application: * Provide mouse shortcuts for commonly used features. Providing good mouse support makes the application easier for them most users, especially those who can use pointing devices but not the keyboard. They can enter text using on-screen keyboard utilities, but that is less efficient and convenient than performing actions designed for the mouse. * Support simple mouse operations. When possible, you should require only single-clicks to perform common operations. Some users have difficulty holding down a mouse button while moving the pointing device, and this makes drag-and-drop operations difficult. Double-clicking is also more difficult than single-clicking, so you should provide single-click access to commonly used operations whenever possible. You should also avoid requiring the use of mouse button 2, because some pointing devices and many alternative devices used by people with disabilities do not support it. * Make toolbars customizable. This allows the user to create mouse shortcuts for commands that might normally require the keyboard or multiple mouse clicks. Of course, you should not require the use of the mouse for any features. For more information, see "Keyboard Access" in this document. Customizable User Interface If possible, allow the user or administrator to customize the application to meet specific needs. | Recommendation Blindness Dexterity Cognitive Language Some users benefit from highly customized interfaces Customizable keyboard commands, menus, dialog boxes, and toolbars make it possible to specially tailor an application for their the needs of a group or individual. Benefits * Blindness: Screen review utilities can sometimes work better with applications when dialog boxes and windows are rearranged. * Dexterity: Voice input and on-screen keyboard utilities can sometimes work better with applications if commands are rearranged or renamed. * Cognitive/Language: Users with cognitive abilities benefit greatly from customized windows, dialog boxes, toolbars, and menus that reduce the complexity and number of choices on the screen. Users with cognitive or language disabilities can benefit from giving commands names that are easier to read or understand. Approaches to Customization There are many good approaches to customization, all of which can help reduce complexity and improve access to features that a specific user requires: * Detailed customization. Some applications allow the user to configure individual menu items and commands * Schemes. You can provide the user with a choice of schemes that would reconfigure portions of the user interface. For example, some applications allow the user to choose from menus geared for advanced, intermediate, or novice users. * Macro capabilities allow a user to create custom dialog boxes that supplement or replace existing functionality. This is normally supported in full-featured applications, such as Microsoft Word and Microsoft(R) Excel. Areas for Customization The following are not supported by most applications, but can benefit many individuals. When possible, support the following types of customization: * Omitting extraneous graphics. If your application uses graphical "decorations" that do not convey additional information, you should consider providing an option to hide them. For example, icons that illustrate option buttons can be hidden if the function of the buttons is already described by accompanying text. Such graphical decoration is very useful for most users, but it can be a hindrance for users with cognitive disabilities who require a simpler interface with less visual distraction. * Customizing dialog boxes. This is usually supported using a macro or scripting language. * Customizable menus. For more information, see "Keyboard Access" in this document. * Customizable keyboard shortcuts. For more information, see "Keyboard Access" in this document. Layout There are several ways that the visual design, or layout, of an application can improve its usability as well as accessibility for people with cognitive or visual impairments. Benefits * Blindness: Screen review utilities can sometimes identify screen objects by their spatial relationships with labels and other objects. This is not necessary for standard dialog boxes or applications that expose this information through Active Accessibility. * Low Vision: Individuals with tunnel vision, or who use screen magnification utilities, can only see a portion of the screen at a time. Positioning related items close together and in expected ways make it easier for them to locate information. * Cognitive/Language: Individuals with some cognitive disabilities may understand information and the relationship between objects if they are positioned according to accepted conventions. Labeling Controls Make it easy to recognize the label for each control Some types of controls, such as buttons, have their own textual labels. Accessibility aids have no trouble identifying such controls. However, other objects, such as edit controls or graphical objects, are typically labeled by placing a static control nearby. The Windows Interface Guidelines for Software Design describes guidelines for the placement of labels so that they are consistent across all applications. Proper labeling helps make the interface more consistent between applications and more usable for everyone. The following guidelines apply when using standard dialog boxes or custom dialog boxes: * Place a text label immediately to the left of or above its control. * Do not separate a control and its label by too great a distance. * Do not place unlabeled controls both to the left of and beneath a label. * All text labels should end with colons, and static text controls that do not label other controls should not end in colons. Labeling Icons Follow conventions for labeling icons If your application uses an icon or any type of graphic to represent an object or control, you should also display a text label with it. This arrangement is already familiar to users, and the combination of text and graphic helps shorten the learning curve for a new user. It can also be used by screen review utilities when the labels are not exposed through any programmatic means. Follow these standard guidelines: * A text label should generally be placed immediately beneath a large icon or to the right of a small icon. * Text labels placed beneath icons should use the font, size, and color defined for icon titles in Control Panel. * If you cannot display the text label visibly, use tooltips or other techniques to expose the label. See "Exposing Screen Elements" for more information. To see an examples of all three techniques, start the Windows Explorer from the Start menu, and choose Large Icons from the View menu. Positioning Related Items Near Each Other Try to position related objects near each other You should try to arrange related items near each other. Because a person with low vision or tunnel vision can only see a portion of the screen at a time, this arrangement helps reduce the amount of work the person has to do to shift their gaze back and forth between related items. It also makes relationships clearer to all users. Section 6 Verifying Accessibility All the planning in the world will not ensure that an application is as accessible as it could be. However, a number of techniques can be used to measure your success in meeting your accessibility objectives. These include: * Testing techniques * Prioritizing testing tasks * Getting feedback from customers Testing Techniques You can test your application to see how well it addresses some of the issues discussed in this document by following these suggestions. * Use the recommendations checklist. Have one or more people go through your application, comparing against the checklist of recommendations in this document. You can methodically test all of your major features, but informal testing can also find many of the most obvious problems. * Large, high-contrast appearance schemes. Choose the Accessibility Options section of Control Panel, choose the Display page, and turn on the High Contrast option. Be sure to choose the "White on Black" scheme in the Settings dialog box. Then try using your computer normally. Are there any portions of your application that become invisible or difficult to use or recognize? Are any areas still appearing as black on a white background? Are any elements improperly sized or truncated? * Keyboard. Drop your mouse behind your desk and use your computer for a week with they keyboard alone. Are there operations you cannot perform? Is anything especially awkward to use? Are the keyboard mechanisms adequately documented? Do all controls and menu items have underlined access keys? * Exposing screen elements. Use the Inspect Objects tool included with the Active Accessibility SDK. Hover the mouse pointer over portions of your application and see if the tool can display a proper description. Compare it with standard windows and controls and see if they match. * Exposing the keyboard focus location. Use the Magnifier accessory included with the Active Accessibility SDK. This will be a standard accessory with future versions of Windows and Windows NT. Use your application with the keyboard and make sure that the place where you are working appears, magnified, in the Magnifier window. * Compatibility with accessibility aids. In addition to the testing tools described here, you should try real accessibility aids to see if they work properly with your application. Many utilities are available at no charge or in trial versions. For a catalog of these tools, see http://microsoft.com/enable/. * Larger system font. Increase the size of your system font using the Display section of Control Panel. Does your application look good despite the changes? Can you adjust all of the fonts in your application to be at least as large as the system font? * Custom font sizes. Change the display scaling ratio using the Custom Font Size feature in the Display section of Control Panel. Does your application appear consistent, or do various elements of the user interface appear disproportionately large or small? Prioritizing Features If you prioritize features to be tested, we recommend you take the following factors into account: * Number of users. Give higher priority to features that affect large number of users. Generally, features related to viewing documents affect more people than those related to authoring documents. * Frequency of use. Give higher priority to features that are used frequently by those customers who use them. * Urgency of use. Give higher priority to features that are an integral and necessary part of the product, rather than optional or ease-of-use features. Getting Feedback from Customers The best way to find out if your product is really usable by people with disabilities is to actively solicit their feedback. * Beta tests. Include people with disabilities and developers of accessibility aids in any field or beta tests you run on your product. * Usability tests. If you perform usability testing, try including subjects who have disabilities. You do not necessarily have to design special tests for these subjects, but you should watch to see how these individuals approach and perform 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. * Surveys. Solicit input from your customers who have disabilities. This input may be coming today but getting filtered before it reaches your development team. You can also use the Internet to find and email groups of computer users with certain disabilities. * Evaluation programs. Send free evaluation copies to organizations that represent or work with people with disabilities, or who develop accessibility aids, and ask them for their feedback. You should also include companies who developer accessibility aids in any of these processes. This will not allow them to make sure their product works with your own, and prepare any special configuration files or other items necessary to make the two products work well together. They can also provide you with valuable technical suggestions for improving your application's accessibility. For a list of accessibility aid manufacturers, see http://microsoft.com/enable/. Appendix A Additional Resources For more information on accessibility, a catalog of accessibility aids, and solutions for people with disabilities, see Microsoft's Accessibility and Disabilities site on the World Wide Web: http://microsoft.com/enable/ Or contact: Microsoft Sales Information Center One Microsoft Way Redmond, WA 98052-6393 | World Wide Web: Voice telephone: Text telephone: | http://microsoft.com (800) 426-9400 (800) 892-5234 Additional Accessibility Guidelines This document is based on the general guidelines first proposed in the white paper "Making Software More Accessible for People with Disabilities." That paper was prepared by Gregg Vanderheiden of the Trace R&D Center of the University of Wisconsin at Madison under funding from the Information Technology Foundation (formerly ADAPSO Foundation) and the National Institute for Disability and Rehabilitation Research (NIDRR) of the U.S. Department of Education. That paper 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 | World Wide Web: Voice telephone: Text telephone: Fax: | http://trace.wisc.edu (608) 263-2309 (608) 263-5408 (608) 262-8848 The Windows Interface Guidelines for Software Design, contains a section on accessible software design. It is included in the Win32 SDK, online at http://microsoft.com, and is available as a book from Microsoft Press. Assistive Technology Programs for People with Disabilities For general information and recommendations on how computers can help specific needs, you should consult a trained evaluator. 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, contact: National Information System University of South Carolina Center for Developmental Disabilities Columbia, SC 29208 | Voice/text telephone: Fax: | (803) 935-5231 (803) 935-5059 Appendix B Accessible Documentation An application is not accessible if a user cannot learn to use it. This appendix describes ways in which accessibility can be addressed in the documentation process: * Providing documentation in accessible formats * Designing accessible documentation Documentation in Accessible Formats Some users have difficulty reading or holding conventionally printed documentation, so documentation should also be provided in other more accessible formats, such as online versions. You should inform the user if he or she has or can obtain online documentation that includes all or almost all of the information in the printed versions. The user should be able to easily determine if online documentation is available, how complete it is, and how to obtain it. Of course, it is also necessary to make sure that the application presenting the documentation is itself accessible. The following formats are acceptable for accessible documentation: * HTML Help. Microsoft is currently developing HTML Help, the next-generation of help systems for the Windows operating systems. The HTML Help system should be completely compatible with accessibility aids, as well as taking advantage of accessibility features in Microsoft Internet Explorer. Documentation developed for this system should be accessible to users with disabilities. * Text formats. Software vendors should allow customers to order the documentation on floppy disk. This type of electronic documentation is normally provided as formatted ASCII text files, or as HTML files designed for the World Wide Web. These formats address a wide variety of needs. For example, customers who are blind or have low vision can read the files in their own word processor using screen review or screen enlarger utilities, and customers with mobility impairments can read them online without holding or turning the pages of a physical book. The ASCII files normally include special tags that identify the structure of the document (that is, tags for headings, footnotes, and so on); these are normally included as part of all HTML files. * Specialized formats. Documentation can also be provided in additional formats, such as large print, Braille, or audio tapes. Most companies do not provide documentation in these formats, but license instead the source files for documents to users or organizations who want to create accessible versions in those formats. Any of these formats should provide descriptions of illustrations. All formats other than HTML or HTML Help should also provide descriptions of the structure of tables. Designing Accessible Documentation In general, accessible documentation design follows the same rules as accessible visual design for software: * Do not 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 those devices are often unable to preserve graphic or color information. * Color and graphics should be added redundantly to the text to improve documents. For example, if a reference work contains a list of function calls and gives important information about each one, some entries can be printed in blue ink, rather than black, to make it instantly obvious that they are not supported on all systems. In this case, all the entries that are shown in blue can also include a phrase, such as "platform specific" in their description. If space is limited, each can simply be marked with an asterisk. Such redundant use of information often makes documentation easier for everyone to use. A phrase or asterisk could also be used in cases where certain paragraphs are called out with a graphic in the margin. Modifying text in this way makes it easier for you, or another organization working on your behalf, to translate your documentation into alternative formats, such as Braille or online documentation. * Maintain high contrast between text and its background, and avoid screened art behind text. * Do not use text smaller than 10 points in size. * If possible, bind printed documents to lie flat. Comb and spiral bindings are considered the most accessible because they allow a document to lie flat. These types of bindings are useful for 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 for conversion to an online format, and a person with low vision might use a closed-caption television system to enlarge the pages. Flat bindings are also preferred by people who want to be able to type while reading. Appendix C Accessible Packaging This appendix describes hints for packaging software products to make them accessible. * Make diskettes easily identifiable. All diskettes and CD-ROM disks should be given a unique volume label that easily identifies the specific product and disk number. People who are blind may not be able to read the printed disk label, but providing an appropriate volume label allows them to identify the diskette using the dir command at the command prompt. * Making packaging easy to open. Users with mobility impairments may have trouble opening some packages. It can be useful to examine packaging to see if it could be made easier to use. For example, shrink-wrapped packages can be easy to open if they are left unsealed at a place where two layers overlap. * Don't require reading the packaging. If your setup procedure requires the user to read installation instructions, or a product identification code that is only available in print, it can be impossible for users with visual impairments to install the software without assistance. Appendix D Product Support and Customer Service The following steps can help your organization provide effective technical support and product service for customers with disabilities. * Provide customer support through 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 customer information and support services. These services should, therefore, be made available through a text telephone (also known as TTY or TDD) and standard ASCII modems. Stand-alone text telephones are available with a wide range of features, and combination TTY/ASCII modems can also be attached to standard computers, although specialized software is normally used to get full answering-machine functionality. * Train your service representatives. You should provide your customer service and technical support representatives with guidelines for interacting with people with disabilities. Having a basic familiarity with types of disabilities, the way in which people with disabilities use computers, and the very fact that they do use computers, can go a long way towards making customer interactions successful and positive. * Address customers with disabilities. Some companies, including Microsoft, incorporate information about accessibility into every product, and into their sites on the World Wide Web. This can help establish a positive relationship with the disability community and make customers with disabilities feel more comfortable in dealing with your organization. Appendix E: Windows Version 3.x Guidelines The following guidelines do not affect Win32(R) - based applications designed for Windows 95 or Windows NT, but should be followed when developing 16-bit applications (also called Win16 applications) for Windows version 3. x. Yielding Control to Background Applications Windows-based 16-bit applications should yield control at all times so that other programs, such as accessibility aids, can run in the background. If a program refuses to yield control, the user is unable to access the machine. You can avoid access problems by following these techniques: * Avoid using system modal dialog boxes or windows. When a system-modal window is active, no background tasks are allowed to run. (This is true to a lesser extent for 16-bit applications running under Windows 95, although it is not a problem for those running under Windows NT.) * Avoid using the PeekMessage function in tight loops without yielding. Colors in Online Help An author that is designing an online help topic can specify foreground and background colors, or use the color scheme selected by the user in Control Panel. If the author specifies his or her own color scheme, the user running Windows version 3. x or Windows NT version 3. x has no way to override the scheme and use a different set of colors. As a consequence, 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 the user with the option to use only Control Panel colors. However, this option leads to having the topic appear different from the help author's preference.) If you want your online help to be usable by as many customers as possible, you should generally allow the user to choose their own color scheme rather than specifying one of your own choosing. Testing Accessibility Flags Windows 95 introduced four new flags that advise applications when they should adjust their behavior to accommodate users with disabilities. Although each can be tested using the SystemParametersInfo function, this capability is not supported in earlier versions of Windows or Windows NT. To make this behavior available in earlier operating systems, you can test for the flags as WIN.INI settings. These settings are not used by Windows itself, but they can be set manually by users who want the specified disability options. The following WIN.INI settings are recommended. 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 ---------- End of Document