Guidelines for designing accessible apps

Applies to Windows and Windows Phone

As you design your app, always keep in mind that your users have a wide range of abilities, disabilities, and preferences. Follow these principles of accessible design to ensure that your app is accessible to the widest possible audience, and helps attract more customers to your app in the Windows Store.

Why plan for accessibility?

Designing your app with accessibility in mind helps ensure that it works well in the following scenarios.

  • Screen reading: Blind or visually impaired users rely on screen readers to help them create and maintain a mental model of your app's UI. Hearing information about the UI and including the names of UI elements, helps users understand the UI content and interact with your app.

    To support screen reading, your app needs to provide sufficient and correct information about its UI elements, including name, role, description, state, and value. Learn more about exposing basic information about UI elements for HTML or for XAML.

    You must also provide additional accessibility information for UI elements that contain dynamic content, such as a live region in a Windows Runtime app using JavaScript with HTML. The additional accessibility information lets screen readers announce changes that occur to the content. To provide accessibility information for a live region in HTML, set the aria-live attribute on elements that contain dynamic content. For more info see Making live regions accessible. To provide accessibility information for a live region using the ARIA metaphors for live content in XAML, use the attached property AutomationProperties.LiveSetting.

  • Keyboard accessibility: The keyboard is integral to using a screen reader, and it is also important for users who prefer the keyboard as a more efficient way to interact with an app. An accessible app lets users access all interactive UI elements by keyboard only, enabling users to:

    • Navigate the app by using the Tab and arrow keys.
    • Activate UI elements by using the Spacebar and Enter keys.
    • Access commands and controls by using keyboard shortcuts.

    The On-Screen Keyboard is available for systems that don't include a physical keyboard, or for users whose mobility impairments prevent them from using traditional physical input devices.

    Learn more about implementing keyboard accessibility for HTML or for XAML.

  • Accessible visual experience: Visually impaired users need text to be displayed with a high contrast ratio. They also need a UI that looks good in high-contrast mode and scales properly after changing settings in the Ease of Access control panel. Where color is used to convey information, users with color blindness need color alternatives like text, shapes, and icons. Learn more about supporting high contrast themes for HTML or for XAML. Or learn more about meeting requirements for accessible text for HTML or for XAML.

Dos and don'ts

  • Support screen reading by providing information about your app's UI elements, including name, role, description, state, and value.
  • Let users navigate your app using the Tab and arrow keys.
  • Activate UI elements by using the Spacebar and Enter keys.
  • Access commands and controls by using keyboard shortcuts.
  • Design text and UI to support high contrast themes.
  • Ensure that text and UI to make appropriate scaling adjustments when Ease of Access settings are changed.
  • Don’t use color as the only way to convey information. Users who are color blind cannot receive information that is conveyed only through color, such as in a color status indicator. Include other visual cues, preferably text, to ensure that information is accessible.
  • Don’t use UI elements that flash more than three times per second. Flashing elements can cause some people to have seizures. It is best to avoid using UI elements that flash.
  • Don’t change user context or activate functionality automatically. Context or activation changes should occur only when the user takes a direct action on a UI element that has focus. Changes in user context include changing focus, displaying new content, and navigating to a different page. Making context changes without involving the user can be disorienting for users who have disabilities. The exceptions to this requirement include displaying submenus, validating forms, displaying help text in another control, and changing context in response to an asynchronous event.
  • Avoid building custom UI elements if you can use the default controls included with the Windows Runtime or controls that have already implemented Microsoft UI Automation support. Standard Windows Runtime controls are accessible by default and usually require adding only a few accessibility attributes that are app-specific. In contrast, implementing the AutomationPeer support for a true custom control is somewhat more involved (see Custom automation peers).
  • Don't put static text or other non-interactive elements into the tab order (for example, by setting the TabIndex property for an element that is not interactive). If non-interactive elements are in the tab order, that is against keyboard accessibility guidelines because it decreases efficiency of keyboard navigation for users. Many assistive technologies use tab order and ability to focus an element as part of their logic for how to present an app's interface to the assistive technology user. Text-only elements in the tab order can confuse users who expect only interactive elements in the tab order (buttons, check boxes, text input fields, combo boxes, lists, and so on).
  • Avoid using absolute positioning of UI elements (such as in a Canvas element) because the presentation order often differs from the child element declaration order (which is the de facto logical order). Whenever possible, arrange UI elements in document or logical order to ensure that screen readers can read those elements in the correct order. If the visible order of UI elements can diverge from the document or logical order, use explicit tab index values (set TabIndex) to define the correct reading order.
  • Don’t automatically refresh an entire app canvas unless it is really necessary for app functionality. If you need to automatically refresh page content, update only certain areas of the page. Assistive technologies generally must assume that a refreshed app canvas is a totally new structure, even if the effective changes were minimal. The cost of this to the assistive technology user is that any document view or description of the refreshed app now must be recreated and presented to the user again.

    Note  If you do refresh content within a region, consider setting the AccessibilityProperties.LiveSetting accessibility property on that element to one of the non-default settings Polite or Assertive. Some assistive technologies can map this setting to the Accessible Rich Internet Applications (ARIA) concept of live regions and can thus inform the user that a region of content has changed.

    Note  A deliberate page navigation that is initiated by the user is a legitimate case for refreshing the app's structure. But make sure that the UI item that initiates the navigation is correctly identified or named to give some indication that invoking it will result in a context change and page reload.

Additional usage guidance

Make your HTML custom controls accessible

If you use an HTML custom control, you need to provide all of the basic accessibility information for the control, including the accessible name, role, state, value, and so on. You also need to ensure that the control is fully accessible by keyboard, and that the UI meets requirements for visual accessibility.

For example, suppose you include a div element that represents a custom interactive element; that is, it handles the onclick event. You must:

  • Set an accessible name for the div element.
  • Set the role attribute to the corresponding interactive ARIA role, such as "button”.
  • Set the tabindex attribute to include the element in the tab order.
  • Add keyboard event handlers to support keyboard activation; that is, the keyboard equivalent of an onclick event handler.

To learn more about exposing custom HTML UI elements for accessibility, see Accessible Rich Internet Applications (ARIA).

Note  

The HTML5 canvas element doesn’t support accessibility. Because it doesn’t provide any way to expose accessibility information for its content, avoid using canvas unless it is absolutely necessary. If you do use canvas, treat it as a custom UI element.

Make your XAML custom controls accessible

If you use a XAML custom control, you might need to adjust some of the basic accessibility information for the control, including the accessible name, role, state, value, and so on. You also need to verify that the control is fully accessible by keyboard, and that the UI meets requirements for visual accessibility. When you create custom controls for XAML, you inherit the UI Automation support that was available for whichever control you used as the base class for your custom control. Sometimes that's good enough. But depending on the degree that you're customizing your control, you might also want to create a custom UI Automation peer class that modifies or augments the default UI Automation support. This is enabled by the APIs in Windows.UI.Xaml.Automation and Windows.UI.Xaml.Automation.Peers namespaces. For more info, see Custom automation peers.

Accessibility support in the development platform

The Windows Runtime development platform supports accessibility in all stages of the development cycle:

  • Creating: The code generated from the Microsoft Visual Studio app templates includes accessibility information.
  • Coding: The development platform includes the following accessibility support during the coding stage.
    • Microsoft IntelliSense in Visual Studio includes accessibility information.
    • The controls included in the Windows 8 platform have built-in support for accessibility. By using the standard HTML and platform controls, you can get most of your accessibility support as a default platform behavior. For example, the ratings control is fully accessible without any additional work, while the ListView controls require only an accessible name for the main list element—all other accessibility support is built in. For a list of platform controls, see Controls list (HTML) or Controls list (XAML).
    • The Windows Dev Center documentation includes accessibility guidelines and sample apps.
  • Testing: The Windows Software Development Kit (SDK) includes accessibility testing tools. Learn more about testing your app for accessibility for HTML or for XAML.
  • Selling: You can mark your app as accessible when you publish it in the Windows Store, enabling users to discover your app by using the Accessibility filter when browsing the store. Learn more about declaring your app as accessible in the Windows Store for HTML or for XAML.

Related topics

For developers (HTML)
Accessibility for Windows Runtime apps using JavaScript
Testing your app for accessibility
Accessible Rich Internet Applications (ARIA)
ARIA sample
For developers (XAML)
Accessibility for Windows Runtime apps using C++, C#, or Visual Basic
Testing your app for accessibility
Windows.UI.Xaml.Automation
XAML accessibility sample

 

 

Show:
© 2014 Microsoft