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/
© 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.
Microsoft® Windows® 95 and Windows NT® 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/.
This document is aimed at people who design, build, test, or document software applications for the Windows 95 and Windows NT operating systems.
This document contains the following sections:
This section summarizes the techniques for making software applications accessible to people with disabilities. These are described in more detail later in this document.
You should follow these basic principles when designing an accessible application:
Providing a good keyboard user interface is key to designing an accessible application.
Many accessibility aids need to know where the user is working.
Many accessibility aids need to identify or manipulate the objects on the screen.
Color should be used to enhance, emphasize, or reiterate information.
The size of text and graphics affects usability as well as accessibility.
Visual design and layout can make an application more usability, and more accessible for people with cognitive or visual impairments:
This section provides background on accessibility, including the different types of accessibility aids available and the basic principles underlying accessibility design.
This section discusses:
Accessible design is important to all of us in the computer industry. It is important to you and your organization because:
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:
These categories describe groups of disabilities covering a broad range of people with widely different levels of need.
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.
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.
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 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.
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.
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.
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:
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/.
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.
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® 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.
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.
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.
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.
Two things contribute to the accessibility of an application:
The guidelines in this document address both types
of needs.
This section describes the general procedure for creating accessible applications:
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
The key is to identify issues, prioritize them, and address those that you reasonably can
It is impossible for any written guidelines to cover every situation, so it is worth restating the basic principles that underlie accessible design:
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.
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:
When prioritizing features, we recommend you take the following factors into account:
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:
Provide keyboard access to all features.
| 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.
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:
The following examples show some navigational techniques that you may be able to adopt and adapt to your application:
Some applications use the CTRL+TAB or CTRL+PAGE DOWN key combination to shift through groups of panes or pages.
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.
Fully document the keyboard user interface.
| 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.
Provide underlined access keys for all menus and controls.
| 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:
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.
Use logical keyboard navigation order.
| 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.
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.
Allow the user to select text with the keyboard.
| 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:
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.]
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.
| 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.
Expose the location of the keyboard focus within a window.
| 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.
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.
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/.
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.)
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:
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/.
Allow other software to identify and manipulate all screen elements that the user interacts with.
| 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
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:
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.
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.
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.
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:
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]
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.
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.
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.
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.
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:
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.
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.
To see an example of handling multiple controls with the same name, display Keyboard page in the Accessibility Options section of Control Panel.
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:
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.
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/.
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.
When the High Contrast options is set,
| 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.
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.
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.
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.
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.
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.
Avoid conveying important information by color alone.
| 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.
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.
Remember, small fonts and insufficient contrast are among the most frequent complaints to come out of usability testing.
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
| The application must be compatible with specific system settings for sizes and fonts. |
Logo Requirement
Dexterity |
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.
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?
| 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.
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.
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.
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.
The application should be compatible with changes to the system font size and changes to the number of pixels per logical inch.
| 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.
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:
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.
Several methods can be used to accommodate a bitmap to differently sized regions:
The following alternatives can be used in place of bitmaps, which can more easily adjust to different amounts of space:
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.
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
Do not convey important information by sound alone.
| 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.
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.
Applications make sounds for a variety of reasons. We can divide these up into four general categories:
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 comp