Guidelines and checklist for accessibility (XAML)

Applies to Windows and Windows Phone

Here we provide a checklist you can use to ensure that your Windows Runtime app using C++, C#, or Visual Basic is accessible.

Looking for the HTML/JavaScript version of this topic? See Guidelines and checklist for accessibility (HTML).

  1. Set the accessible name (required) and description (optional) for content and interactive UI elements in your app.

    An accessible name is a short, descriptive text string that a screen reader uses to announce a UI element. Some UI elements such as TextBlock and TextBox promote their text content as the default accessible name; see Name from inner text.

    You should set the accessible name explicitly for images or other controls that do not promote inner text content as an implicit accessible name. You should use labels for form elements so that the label text can be used as a LabeledBy target in the Microsoft UI Automation model for correlating labels and inputs. If you want to provide more UI guidance for users than is typically included in the accessible name, accessible descriptions and tooltips help users understand the UI.

    For more info, see Accessible name and Accessible description.

  2. Implement keyboard accessibility:

    • Test the default tab index order for a UI. Adjust the tab index order if necessary, which may require enabling or disabling certain controls, or changing the default values of TabIndex on some of the UI elements.
    • Use controls that support arrow-key navigation for composite elements. For default Windows Runtime controls, the arrow-key navigation is typically already implemented.
    • Use controls that support keyboard activation. For default Windows Runtime controls, particularly those that support the UI Automation Invoke pattern, keyboard activation is typically available; check the documentation for that control.
    • Set access keys or implement accelerator keys for specific parts of the UI that support interaction. See Responding to keyboard input for example code.
    • For any custom controls that you use in your UI, verify that you have implemented these controls with correct AutomationPeer support for activation, and defined overrides for key handling as needed to support activation, traversal and access or accelerator keys.

    For more info, see Implementing keyboard accessibility.

  3. Visually verify your UI to ensure that the text contrast is adequate, elements render correctly in the high-contrast themes, and colors are used correctly.

    • Use the system display options that adjust the display's dots per inch (dpi) value, and ensure that your app UI scales correctly when the dpi value changes. (Some users change dpi values as an accessibility option, it's available from Ease of Access.)
    • Use a color analyzer tool to verify that the visual text contrast ratio is at least 4.5:1.
    • Switch to a high contrast theme and verify that the UI for your app is readable and usable.
    • Ensure that your UI doesn’t use color as the only way to convey information.

    For more info, see Supporting high contrast themes and Meeting requirements for accessible text.

  4. Run accessibility tools, address reported issues, and verify the screen reading experience.

    Use tools such as Inspect to verify programmatic access, run diagnostic tools such as AccChecker to discover common errors, and verify the screen reading experience with Narrator.

    For more info, see Testing your app for accessibility.

  5. Make sure your app manifest settings follow accessibility guidelines. See Making tiles accessible.

  6. Declare your app as accessible in the Windows Store.

    If you implemented the baseline accessibility support, declaring your app as accessible in the Windows Store can help reach more customers and get some additional good ratings.

    For more info, see Declaring your app as accessible in the Windows Store. Note that declaring the app as accessible isn't relevant to Windows Phone.

Related topics

Accessibility for Windows Runtime apps using C#/VB/C++ and XAML
Design for accessibility
Practices to avoid

 

 

Show:
© 2014 Microsoft