Guidelines and checklist for accessibility (XAML)
[This article is for Windows 8.x and Windows Phone 8.x developers writing Windows Runtime apps. If you’re developing for Windows 10, see the latest documentation]
Here we provide a checklist you can use to ensure that your Windows Runtime app using C++, C#, or Visual Basic is accessible.
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.
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.
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.
Run accessibility tools, address reported issues, and verify the screen reading experience.
For more info, see Testing your app for accessibility.
Make sure your app manifest settings follow accessibility guidelines. See Making tiles accessible.
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.