Guidelines for accessibility
As you design your app, always keep in mind that your users have a wide range of abilities, disabilities, and preferences. Following accessible design principles from the beginning helps ensure that your app is accessible to the widest possible audience, and helps attract more customers to your app in the Windows Store.
Designing your app with accessibility in mind helps ensure that it works well in the following accessibility 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, including the names of UI elements, helps users understand the UI content and invoke available functionality.
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.
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.
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 selecting Make everything on your screen bigger 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.
The Windows 8 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.
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) for Windows 8.1 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.
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 Accessible Rich Internet Applications (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).
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.
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 Microsoft 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 for Windows Store apps using C#/VB/C++ and XAML
- ARIA sample