Accessibility

Accessibility means making your software usable and accessible to a wide range of users, including those with disabilities. Many users require special accommodation because of temporary or permanent disabilities, the natural effects of aging, or the environment in which they work.

The issue of software accessibility in the home and workplace is becoming increasingly important. Nearly one in five Americans have some form of disability — and it is estimated that more than 30 million people in the U.S. alone have disabilities that may be affected by the design of your software. In addition, between seven and nine out of every ten major corporations employ people with disabilities who may need to use computer software as part of their jobs. As the population ages and more people become functionally limited, accessibility for users with disabilities will become increasingly important to the population as a whole. Legislation, such as the Americans with Disabilities Act, requires that most employers provide reasonable accommodation for workers with disabilities. Section 508 of the Rehabilitation Act is also bringing accessibility issues to the forefront in government businesses and organizations receiving government funding.

Designing software that is usable for people with disabilities does not have to be time-consuming or expensive. However, it is much easier if you take accessibility issues into consideration during planning and design rather than after the software is finished. Following the principles and guidelines in this book will help you design software for most users. Most of these recommendations, such as the conservative use of color or sound, can benefit all users, not just those with disabilities. In addition, keep the following basic objectives in mind:

The following sections provide information about types of disabilities and additional recommendations about how to address the needs of customers with those disabilities. For more information about designing for accessibility, see The Microsoft Windows Guidelines for Accessible Software Design on the Microsoft Accessibility Web site at http://www.microsoft.com/enable/.

Types of Disabilities

There are many types of disabilities, but they are often grouped into several broad categories. These include visual, hearing, physical movement, speech or language impairments, and cognitive and seizure disorders.

Visual Disabilities

Visual disabilities range from slightly reduced visual acuity to total blindness. Those with reduced visual acuity may require only that your software support larger text and graphics. For example, the system provides scalable fonts and controls to increase the size of text and graphics. To accommodate users who are blind or have severe impairments, make your software compatible with speech or Braille utilities, described later in this chapter.

Color blindness and other visual impairments may make it difficult for users to distinguish between certain color combinations. This is one reason why color is not recommended as the only way to convey information. Always use color as an additive or enhancing property.

Hearing Disabilities

Users with hearing loss are generally unable to detect or interpret auditory output at normal or maximum volume levels. The best way to support users who have this disability is to avoid using auditory output as the only way to communicate information. Instead, use audio output only in addition to visual output. For more information about supporting sound, see "Sound" earlier in this chapter.

Physical Movement Disabilities

Some users have difficulty performing or are unable to perform certain physical tasks — for example, moving a mouse or pressing two keys simultaneously on the keyboard. Others have a tendency to inadvertently strike multiple keys when targeting a single key. It is important that you consider physical ability not only for users with disabilities, but also for beginning users who need time to master the motor skills necessary to interact with the interface. The best way to support these users is to support all your basic operations by using simple keyboard and mouse interfaces.

Speech or Language Disabilities

Users with language disabilities, such as dyslexia, find it difficult to read or write. Spell-check and grammar-check utilities can help children, users with writing impairments, and users whose first language is not English, including many individuals who are deaf and whose native language is American Sign Language. Some accessibility tools and utilities designed for users who are blind can also help those with reading impairments. Most design issues affecting users with oral communication difficulties apply only to utilities specifically designed for speech input.

Cognitive Disabilities

Cognitive disabilities can take many forms, including perceptual differences and memory impairments. You can accommodate users with these disabilities by allowing them to modify or simplify your application's interface, such as customizing menus and dialog boxes or hiding graphics. Similarly, using icons and graphics to illustrate objects and choices can be helpful for users with some types of cognitive impairments.

Seizure Disorders

Some users are sensitive to visual information that alternates its appearance or flashes at particular rates — often the greater the frequency, the greater the problem. However, there is no perfect flash rate, so base modulating interfaces on the system's cursor blink rate. Users can customize this value to avoid particular frequencies. If that is not practical, provide your own interface for changing the flash rate.

The GetCaretBlinkTime function provides access to the current cursor blink rate setting. For more information about this function, see the Microsoft Platform SDK on the MSDN Online Web site at http://msdn.microsoft.com/ui/guide/sdk.asp.

Types of Accessibility Aids

A number of accessibility aids are available to assist users with certain types of disabilities. To allow these users to effectively interact with your application, make sure your application is compatible with these utilities. This section briefly describes the types of accessibility utilities and how they work.

One of the best ways to accommodate accessibility in your application's interface is to use standard Windows conventions wherever possible. Windows already provides a certain degree of customization for users, and most accessibility aids work best with applications that follow standard system conventions.

Screen Enlargement Utilities

Screen enlargers (also referred to as screen magnification utilities or large-print programs) allow users to enlarge a portion of their screen. They effectively turn the computer monitor into a viewport showing only a portion of an enlarged virtual display. Users then use the mouse or keyboard to move this viewport to view different areas of the virtual display. Enlargers also attempt to track where users are working, following the input focus and the activation of windows, menus, and secondary windows, and can automatically move the viewport to the active area.

Windows 98 and Windows 2000 include a low-end screen enlarger, called Magnifier. Magnifier is intended to provide a minimum level of functionality for users with slight visual impairments. Most users with visual impairments will need a magnification utility program with higher functionality for daily use. For a list of Windows-based screen enlargement utilities, see the Microsoft Accessibility Web site at http://www.microsoft.com/enable/.

Screen-Review Utilities

People who cannot use the visual information on the screen can interpret the information with the aid of a screen-review utility (also referred to as a screen-reader program or speech-access utility). Screen-review utilities take the information displayed on the screen and direct it through alternative media, such as synthesized speech or a refreshable Braille display.

Because both of these media present only text information, the screen-review utility must render other information on the screen as text; that is, it must determine the appropriate text labels or descriptions for graphical screen elements. It must also track users' activities to provide descriptions of what the user is doing.

Windows Media Player provides support for closed captioning using the Synchronized Accessible Media Interchange (SAMI) standard. This makes it easy for anyone to enhance multimedia content with closed captions for people who are deaf or hard-of-hearing, and with descriptive narration for users who are blind. For more information about Windows Media Player, see http://www.microsoft.com/windows/mediaplayer/. For information about SAMI, see http://www.microsoft.com/enable/.

These utilities often work by monitoring the system interfaces that support drawing on the screen. They build an off-screen database of the objects on the screen, their properties, and their spatial relationships. They also use information available through Microsoft Active Accessibility, a standard programming interface for Windows and applications to actively cooperate with accessibility aids. Some of this information is presented to users as the screen changes, and other information is maintained until users request it. Screen-review utilities often include support for configuration files (also referred to as set files or profiles) for particular applications.

Voice-Input Systems

Users who have difficulty typing can choose a voice-input system (also referred to as a speech recognition program) to control software with their voice instead of with a mouse and keyboard. Like screen-reader utilities, voice-input systems identify objects on the screen that users can manipulate. Users activate an object by speaking the label that identifies the object. Many of these utilities simulate keyboard interfaces, so if your application includes a keyboard interface, it can be adapted to take advantage of this form of input.

On-Screen Keyboards

Some individuals with physical disabilities cannot use a standard keyboard, but can use special devices designed to work with an on-screen keyboard. These switching devices display groups of commands that appear on the screen, and the user employs one or more switches to choose a selected group, then a command within the group. Another technique allows a user to generate keystroke input by using a special mouse or headpointer (a device that lets users manipulate the mouse pointer on the screen through head motion).

Windows 2000 includes a low-end on-screen keyboard. Most users with motion impairments will need an on-screen keyboard utility with higher functionality for daily use. For a list of Windows-based on-screen keyboard utilities, see the Microsoft Accessibility Web site at http://www.microsoft.com/enable/.

Keyboard Filters

Filtering out inappropriate keystrokes can sometimes compensate for users with impaired physical abilities, such as erratic motion, tremors, or slow response. The Accessibility Options in Windows Control Panel support a wide range of keyboard filtering options.

These are generally independent of the application users are interacting with and therefore require no explicit support except for the standard system interfaces for keyboard input. However, users relying on these features may type slowly.

Compatibility with Screen-Review Utilities

You can use the following techniques to ensure that your application is compatible with screen-review utilities. The system allows your application to determine whether the system has been configured to provide support for a screen-review utility, allowing your application to enable or disable certain capabilities.

You can check the SM_SCREENREADER setting using the GetSystemMetrics function. For more information about this function and other information about supporting screen-review utilities, see the Microsoft Platform SDK on the MSDN Online Web site at http://msdn.microsoft.com/ui/guide/sdk.asp and the Microsoft Accessibility Web site at http://www.microsoft.com/enable/.

Controls

Use standard Windows controls wherever possible. Most of these have already been implemented to support screen-review and voice-input utilities. However, the custom controls you create may not be usable by screen-review utilities.

Include a label for every control, even if you do not want the control's label to be visible. This applies regardless of whether you use standard controls or your own specialized controls, such as owner-drawn controls or custom controls. If the control does not provide a label, you can create a label using a static text control that you can define as hidden.

Follow the standard layout conventions by placing the static text label before the control (above or to the left of the control). Also, set the keyboard tab navigation order appropriately so that tabbing to a label navigates to the associated control it identifies instead of to a label.

To make sure that the label is recognized correctly, include a colon (:) at the end of the label's text string, as shown in Figure 15.1, unless you are labeling a button, tab, or group box control. Screen-review utilities often use a colon to identify the control. In cases where a label would be visually distracting, provide the label but do not make it visible. Although the label is not visible, it will still be accessible to a screen-review utility.

Text labels are also effective for choices within a control. For example, you can enhance menus or lists that display colors or line widths by including some form of text representation, as shown in Figure 15.2.

If providing a combined presentation is too difficult, offer users the choice between text and graphical representation, or choose one of them based on the system's screen-review utility setting.

Text Output

Screen-review utilities usually interpret text — including properties such as font, size, and face — that is displayed with standard system interfaces. However, text displayed as graphics (for example, bitmapped text) is not accessible to a screen-review utility. To make it accessible, use the Microsoft Active Accessibility programming interfaces to expose the text. Or you can create an invisible text label and associate it with the graphical representation by drawing the text over the graphic with a null operator (NOP). However, Active Accessibility is strongly recommended; invisible text should be used only as a last resort. Screen-review utilities can read standard text representations in a metafile, so you can also use metafiles instead of bitmap images for graphics information that includes text.

Graphics Output

Users with normal sight may easily be able to distinguish different elements of graphic or pictorial information, such as a map or chart, even if they are drawn as a single image; however, a screen-review utility must distinguish between different components. There are a number of ways to do this. Any of these methods can be omitted when the system's screen-review setting is not selected. One way to help users identify images is to label them. Like labels for controls, labels for images can help screen-review utilities uniquely identify an image or the parts of an image.

Microsoft Active Accessibility supports special programming interfaces that you can use to identify graphics or portions of graphics. Using these interfaces is the best way to support accessibility of graphic images.

However, you can also consider drawing bitmap images that need to be identified separately by users. If performance is an issue, combine the component images in an off-screen bitmap using separate drawing operations, then display the bitmap on the screen with a single operation. You can also draw multiple bitmap images with a single metafile. Although these methods do not identify the nature of each image to the screen reader, they do allow the screen reader to recognize that the image is made up of different components. This is especially important when the user can interact with these different areas.

Alternatively, you can redraw each component separately, or draw a separate image to identify each region using a null operator. This has no effect on the visible image, but it allows a screen-review utility to identify the region. You can also use this method to associate a text label with a graphic element.

When you draw graphics, use standard Windows drawing functions wherever possible. If you change an image directly — for example, clearing a bitmap by writing directly into its memory — a screen-review utility will not be able to recognize the content change and will describe it to users incorrectly. Avoid using such techniques when a screen-reader utility is running.

Icons and Windows

Icons that represent objects should be accompanied by a text label (title) of the object's name. Use the system font and color for icon labels, and follow the system conventions for placement of the text relative to the icon. This allows a screen-review utility to identify the object without special support.

Similarly, make sure that all your windows have titles. Even if the title is not visible, it is still available to access utilities. The more specific your window titles, the easier users can differentiate between them, especially when using a screen-review utility. Using unique window class names is another way to provide for distinct window identification, but providing appropriate window titles is preferred.

The User's Point of Focus

Many accessibility aids must follow where the user is working. For example, a screen-review utility conveys to users where the input focus is; a screen enlarger pans its viewport to ensure that the user's focus is always kept on the visible portion of the screen. Most utilities give users the ability to manually move the viewport, but this becomes laborious, especially if it has to be repeated each time the input focus moves.

The SetCaretPos function is an example of a system function you can use to indicate focus location. For more information about this function, see the Microsoft Platform SDK on the MSDN Online Web site at http://msdn.microsoft.com/ui/guide/sdk.asp. You can also indicate the focus location using Active Accessibilty. For more information about Microsoft Active Accessibility, see the Microsoft Active Accessibility Web site at http://www.microsoft.com/enable/msaa/.

When the system handles the move of the input focus — such as when the user selects a menu, navigates between controls in a dialog box, or activates a window — an accessibility utility can track the change. However, the utility may not detect when an application moves the input focus within its own window. Therefore, whenever possible, use Microsoft Active Accessibility or the standard system functions to place the input focus, such as the text insertion point. Even when you provide your own implementation of focus, you can use the system functions to indicate focus location without making the standard input focus indicator visible.

Timing and Navigational Interfaces

Some users read text or press keys very slowly and do not respond to events as quickly as the average user. Avoid briefly displaying critical feedback or messages and then automatically removing them, because many users cannot read or respond to them. Similarly, limit your use of time-based interfaces. If you do include a time-based interface, always provide a way for users to configure the length of the time-out.

Also, avoid displaying or hiding information based on the movement of the pointer, unless it is part of a standard system interface (for example, ToolTips). Although such techniques can benefit some users, the techniques may not be available for those using accessibility utilities. If you do provide such support, consider making these features optional so that users can turn them on or off when a screen-review utility is installed.

Similarly, avoid using general navigation to trigger operations, because users of accessibility aids may need to navigate through all controls. For example, do not use basicTAB keyboard navigation in a dialog box to activate actions associated with a control, such as selecting a check box or clicking a command button. However, you can use navigation to facilitate further user interaction, such as validating user input or opening a drop-down control.

Color

Base the color properties of your interface elements on the system colors for window components rather than defining specific colors. Remember to use appropriate foreground and background color combinations. If the foreground of an element is rendered with the button text color, use the button face color as its background rather than the window background color. If the system does not provide standard color settings that can be applied to some elements, you can include your own interface that allows users to customize colors. In addition, you can provide graphical patterns as an optional substitute for colors as a way to distinguish information.

For more information about the use of color and how it is used for interface elements, see Chapter 14, "Visual Design."

The system also provides a global setting called High Contrast that users can set through the Accessibility Options in Control Panel. The setting provides contrasting colors for foreground and background visual elements. Your application should check the status of this setting when it starts and whenever it receives notification of system setting changes. When set, adjust your interface colors based on those set for the high-contrast color scheme. In addition, whenever High Contrast is set, hide any images that are drawn behind text (for example, watermarks or logos) to maintain the legibility of the information on the screen. You can also display monochrome versions of bitmaps and icons using the appropriate foreground color.

The GetSystemMetrics function provides access to the SM_HIGHCONTRAST setting. For more information about this function, see the Microsoft Platform SDK on the MSDN Online Web site at http://msdn.microsoft.com/ui/guide/sdk.aspM.

Scalability

Another important way to provide visual accessibility is to allow for scalability of screen elements. Sometimes this simply means allowing users to change the font for the display of information. The system allows users to change the size and font of standard Windows components. Use these same metrics for appropriately adjusting the size of other visual information you provide. For your own custom elements, you can provide scaling by including a TrueType font or metafiles for your graphics images.

It may also useful to provide scaling features within your application. For example, many applications provide a Zoom command that scales the presentation of the information displayed in a window, or other commands that make information easier to read. You may need to add scroll bars if the scaled information exceeds the current size of the window.

Keyboard and Mouse Interface

Providing a good keyboard interface is an important step in accessibility because it affects users with a wide range of disabilities. For example, a keyboard interface may be the only option for users who are blind or who use voice-input utilities, and for those who cannot use a mouse. The Accessibility Options in Control Panel often compensate for users with disabilities related to keyboard interaction; however, it is more difficult to compensate for problems related to pointing device input.

Follow the conventions for keyboard navigation techniques presented in this guide. For specialized interfaces within your software, model your keyboard interface on conventions that are familiar and appropriate for that context. Where they apply, use the standard control conventions as a guide for defining your interaction. For example, support tab and SHIFT+TAB keys and access keys as ways to navigate to controls.

Make sure that users can navigate to all objects. Avoid relying only on navigational design that requires users to understand the spatial relationship between objects. Accessibility utilities may not be able to convey such relationships.

Providing a well-designed mouse interface is also important. Pointing devices may be more efficient than keyboards for some users. When designing the interface for pointing input, avoid making basic functions available only through multiple clicking, drag-and-drop manipulation, and keyboard-modified mouse actions. These actions are best regarded as shortcut techniques for more advanced users. Make basic functions available by single-clicking.

The system also allows your application to determine when the user relies on the keyboard rather than on pointing device input. You can use this to present special keyboard interfaces that might otherwise be hidden.

To determine whether a user relies on keyboard rather than pointing device input, check the SM_KEYBOARD PREF setting using GetSystemMetrics. For more information about this function, see the Microsoft Platform SDK on the MSDN Online Web site at http://msdn.microsoft.com/ui/guide/sdk.asp.

Where possible, avoid creating basic functions that depend on the user installing a particular device. This is critical for supporting users with physical disabilities and users who may not wish to use or install a particular device.

Accessible HTML Pages

When you design Web-style applications, there are additional considerations. While HTML provides power and flexibility in presenting information, it can also create barriers for some users. For example, graphic images are inaccessible to users with vision impairments. Careful design and coding of information can minimize these barriers. Here are some guidelines to keep in mind:

Include a short textual description for all images or audio files using the ALT attribute. For a .jpg image, include a description of the image in the file's comment field. For an illustrative image, be sure to use descriptions that convey the relevant information. For images like bullets, use simple text such as "*". Because text descriptions may wordwrap, preview your page with images turned off to ensure that it looks correct. Avoid arrangements that display text descriptions in multiple columns.
If an image needs a lengthy description that doesn't fit into the ALT attribute, provide a link to a separate page that contains a complete description. For a .jpg image, also include the description in the file's comment field.
Provide equivalent text menus for all image maps. Similarly, provide alternative ways to access items in a table, because it may be difficult for a sight-impaired user to navigate through a table using a screen-reader utility.
For audio files, provide text transcriptions or description files. If the text is lengthy, you can provide a link to a separate page.
If you provide online forms that cannot be read by screen-review utilities, provide alternate methods of communication. For example, you can include instructions for supplying information by phone, mail, or e-mail.
Avoid proprietary file formats or use them as alternatives rather than replacements for ASCII or HTML files.

Finally, when you design any Web-based application or content, follow the standards set by the World Wide Web Consortium for accessibility of Web content. This will ensure that your application is accessible to the widest possible range of users and is compatible with automation tools. For more information, see the Microsoft Accessibility Web site at http://www.microsoft.com/enable/.

Documentation, Packaging, and Support

Although this guide focuses primarily on the design of the user interface, a design that provides for accessibility needs takes into consideration other aspects of a product. For example, consider the documentation needs of your users. For users who have difficulty reading or handling printed material, provide online documentation for your product. If the documentation or installation instructions are not available online, you can provide documentation separately in alternative formats, such as ASCII text, large print, Braille, or audiotape. For a list of organizations that can help you produce and distribute such documentation, see the Accessibility section of the Bibliography in this book.

When possible, choose a format and binding for your documentation that makes it accessible for users with disabilities. As in the interface, information in color should be a redundant form of communication. Bindings that allow a book to lie flat are usually better for users with limited dexterity.

Packaging is also important because many users with limited dexterity can have difficulty opening packages. Consider including an easy-opening overlap or tab that helps users remove shrink-wrapping.

Finally, although support is important for all users, it is difficult for users with hearing impairments to use standard support lines. Consider making these services available to customers using text telephones (also referred to as "TT" or "TDD"). You can also provide support through public bulletin boards or other networking services.

Usability Testing

Just as it is important to test the usability of your software, it is a good idea to test its accessibility. There are a variety of ways to do this. One is to include users with disabilities in your prerelease or usability test activities. Another way is to establish a working relationship with companies that provide accessibility aids. Information about accessibility vendors or potential test sites is included in the Bibliography.

You can also try running your software the way a person with disabilities would. Try some of the following ideas for testing:

Test your application against the accessibility recommendations checklist. Have one or more people go through your application, comparing against the checklist of recommendations in The Microsoft Windows Guidelines for Accessible Software Design (available to download at http://www.microsoft.com/enable/dev/). You can methodically test all of your major features, but informal testing can also find many of the most obvious problems.
Test your application using large, high-contrast appearance schemes. To set up your test computer, click the Accessibility Options icon in Control Panel. Click the Display tab, and then click Use High Contrast. Click the Settings button, and then click White on black.

Next try using your computer. Are there any parts of your application that become invisible or are difficult to use or recognize? Do any areas still appear as black on a white background? Are any elements improperly sized or truncated? Make sure that you repeat this test with the Black on white option selected.

Test your application's keyboard interface. Try using your computer for a week without a mouse. 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?
Test how your application exposes its screen elements. Use the Inspect Objects tool included in the Active Accessibility SDK, or the Narrator accessory included in Windows 2000. Using the mouse pointer, hover over portions of your application and see if the tool can display a proper description. Also try using your application and see how these utilities behave. Compare it with standard windows and controls and see if they match.
Test how your application exposes the input focus. Use the Magnifier accessory included in Windows 98 and Windows 2000. Use your application with the keyboard and make sure that the place where you are working appears, magnified, in the Magnifier window.
Test your application's compatibility with accessibility utilities. In addition to the testing tools described here, you should try accessibility aids to see whether they work properly with your application. Many utilities are available at no charge or in trial versions. For a catalog of these tools, see the Microsoft Accessibility Web site at http://www.microsoft.com/enable/.
Test how your application handles large fonts. To increase the size of your system font in Control Panel, click the Display icon and then click the Appearance tab. 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?
Test how your application handles custom font sizes. To change the custom font sizes in Control Panel, click the Display icon and then click the Appearance tab. When you use a custom font size, does your application appear consistent, or do various elements of the user interface appear disproportionately large or small?