Accessibility: Design Guidelines 

Accessibility means making your software usable and accessible for a wide range of users, including those with disabilities.

  • Use standard Windows controls. Most assistive technologies supports standard controls, but any custom controls you create might not be accessible.
    Developer Note:
    Custom Controls: If you create a custom control that is not composed solely of other common controls, you must implement the IAccessible interface. Client applications, such as Microsoft Narrator, call IAccessible methods and properties to obtain information about an application's UI and data. You can read more about IAccessible in the MSDN Library.

  • Every user task that can be performed by using a mouse (or other pointing device) must also be performable by using a keyboard. Many users do not use a mouse.
    Check keyboard navigation by testing the tab and arrow sequences to ensure that users can move through all the controls and progress logically through the interface. Labels should not be a part of the tab sequence. Screen readers often uses a surface’s tab sequence when interpreting that surface, so ensure that the tab sequence reflects the order in which the user needs to hear information.
  • Wherever possible, make tasks performable by single-clicking. Avoid making basic functions available only through multiple-clicking, drag-and-drop operations, or combined keyboard/mouse actions. These actions are best regarded as shortcut techniques for more advanced users.
  • Avoid relying on design that requires users to understand the spatial relationship between objects. Accessibility utilities might not be able to convey such relationships.
  • Always indicate the location of the input focus.
  • Do not override user system settings, such as cursor blink rate, keyboard settings, and high contrast display.
    Base the color properties of your UI 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.
  • To display text that might be copied, use a read-only text box, not a static text field.
  • If the content of a static text field might exceed its boundaries—in other words, if the user must use the mouse to drag the text and reveal the whole string—assign a label and access key to that field.
  • Display messages for a time sufficient to allow users to read or respond to them.
  • Do not display or hide controls or information (such as dynamic “hover text” or alt text) based on the movement of the pointer. Although such techniques can benefit some users, accessibility utilities do not support this functionality. Standard functionality such as ToolTips is an exception.
  • Do not use input focus to change control states or to trigger events or messages. Users of accessibility aids might need to navigate through all controls on a surface before making changes.
  • If your product includes online forms in formats that cannot be read by screen-reading tools, provide instructions for communicating by phone, mail, or e-mail.
  • Use tables sparingly. Tables can be difficult to understand when interpreted by assistive technologies, so use tables only when there’s no reasonable alternative. If you use tables, ensure that their access key (arrow key) sequence is linear, not according to some other logic (such as order of the cells’ importance). The sequence can be horizontal or vertical—whichever makes more sense to the user.

See Also

Show: