Accessibility best practices

Article
09/15/2021

Note

This article is intended for .NET Framework developers who want to use the managed UI Automation classes defined in the System.Windows.Automation namespace. For the latest information about UI Automation, see Windows Automation API: UI Automation.

Implementing the following best practices in controls or applications will improve their accessibility for people who use assistive technology devices. Many of these best practices focus on good user interface (UI) design. Each best practice includes implementation information for Windows Presentation Foundation (WPF) controls or applications. In many cases, the work to meet these best practices is already included in WPF controls.

Programmatic Access

Programmatic access involves ensuring that all UI elements are labeled, property values are exposed, and appropriate events are raised. For standard WPF controls, most of this work is already done through AutomationPeer. Custom controls require additional work to ensure that programmatic access is correctly implemented.

Enable Programmatic Access to all UI Elements and Text

User interface (UI) elements should enable programmatic access. If the UI is a standard WPF control, support for programmatic access is included in the control. If the control is a custom control – a control that has been subclassed from a common control or a control that has been subclassed from Control – then you must check the AutomationPeer implementation for areas that may need modification.

Following this best practice allows assistive technology vendors to identify and manipulate elements of your product's UI.

Place Names, Titles, and Descriptions on UI Objects, Frames, and Pages

Assistive technologies, especially screen readers, use the title to understand the location of the frame, object, or page in the navigation scheme. Therefore, the title must be descriptive. For example, a Web page title of "Microsoft Web Page" is useless if the user has navigated deeply into some particular area. A descriptive title is critical for users who are blind and depend on screen readers. Similarly, for WPF controls, NameProperty and HelpTextProperty are important for assistive technology devices.

Following this best practice allows assistive technologies to identify and manipulate UI in sample controls and applications.

Ensure Programmatic Events Are Triggered by All UI Activities

Following this best practice allows assistive technologies to listen for changes in the UI and notify the user about these changes.

User Settings

The best practice in this section ensures that controls or applications do not override user settings.

Respect All System-Wide Settings and Do Not Interfere with Accessibility Functions

Users can use the Control Panel to set some system-wide flags; other flags can be set programmatically. These settings should not be changed by controls or applications. Also, applications must support the accessibility settings of their host operating system.

Following this best practice allows users to set accessibility settings and know that those settings will not be changed by applications.

Visual UI Design

Best Practices in this section ensure that controls or applications use color and images effectively and are able to be used by Assistive technologies.

Don't Hard-Code Colors

People who are color blind, have low vision, or are using a black and white screen might not be able to use applications with hard-coded colors.

Following this best practice allows users to adjust color combinations based on individual needs.

Support High Contrast and all System Display Attributes

Applications should not disrupt or disable user-selected, system-wide contrast settings, color selections, or other system-wide display settings and attributes. System-wide settings adopted by a user enhance the accessibility of applications, so they should not be disabled or disregarded by applications. Color should be used in their correct foreground-on-background combination to provide proper contrast. Don't mix unrelated colors, and don't reverse colors.

Many users require specific high-contrast combinations, such as white text on a black background. Drawing these reversed, as black text on a white background causes the background to bleed over the foreground and can make reading difficult for some users.

Ensure All UI Correctly Scales by Any DPI Setting

Ensure that all UI can correctly scale by any dots per inch (dpi) setting. Also, ensure that UI elements fit in a screen of 1024 x 768 with 120 dots per inch (dpi).

Best Practices in this section ensure that navigation has been addressed for controls and applications.

Provide Keyboard Interface for All UI Elements

Tab stops, especially when carefully planned, give users another way to navigate the UI.

Applications should provide the following keyboard interfaces:

tab stops for all controls that the user can interact with, such as buttons, links, or list boxes
logical tab order

Show the Keyboard Focus

Users need to know which object has the keyboard focus so that they can anticipate the effect of their keystrokes. To highlight the keyboard focus, use colors, fonts, or graphics such as rectangles or magnification. To audibly highlight the keyboard focus, change the volume, pitch, or tonal quality.

To avoid confusion, applications should hide all visual focus indicators and dim selections that are located in inactive windows (or panes).

Applications should do the following with keyboard focus:

one item should always have keyboard focus
keyboard focus should be visible and obvious
selections and/or focused items should be visually highlighted

Different aspects of keyboard navigation provide different ways for users to navigate the UI.

Applications should provide the following keyboard interfaces:

shortcut keys and underlined access keys for all commands, menus, and controls
keyboard shortcuts to important links
all menu items have an access key; all buttons have accelerator keys, all commands have an accelerator key.

Mouse location should not interfere with keyboard navigation. For example, if the mouse is positioned some place and the user is navigating with the keyboard, a mouse click should not happen unless initiated by the user.

Multimodal Interface

Best Practices in this section ensure that application UI includes alternatives for visual elements.

Provide User-Selectable Equivalents for Non-Text Elements

For each non-text element, provide a user-selectable equivalent for text, transcripts, or audio descriptions, such as alt text, captions, or visual feedback.

Non-text elements cover a wide range of UI elements including: images, image map regions, animations, applets, frames, scripts, graphical buttons, sounds, stand-alone audio files, and video. Non-text elements are important when they contain visual information, speech, or general audio information that the user needs access to in order to understand the content of the UI.

Use Color but Also Provide Alternatives to Color

Use color to enhance, emphasize, or reiterate information shown by other means, but do not communicate information by using color alone. Users who are color blind or have a monochrome display need alternatives to color.

Use Standard Input APIs with Device-Independent Calls

Device-independent calls ensure keyboard and mouse feature equality, while providing assistive technology with needed information about the UI.

Share via