Guidelines and checklist for accessibility (HTML)
[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]
Looking for the C#/VB/C++/XAML version of this topic? See Guidelines and checklist for accessibility (XAML).
Here we provide a checklist you can use to ensure that your Windows Runtime app using JavaScript is accessible.
Set the accessible name (required) and description (optional) for content and interactive UI elements.
An accessible name is a short, descriptive text string that a screen reader uses to announce a UI element. You should set the accessible name explicitly for images (use the alt attribute), input fields (use the label tag with the for attribute), custom div controls, so on. Accessible descriptions and tooltips help users understand the UI.
For more info, see Accessible name and Accessible description (optional).
Set and maintain accessible value and status attributes.
These attributes are important for custom elements, including buttons, lists, check boxes, combo boxes, sliders, progress bars, and so on.
Set the role attribute for interactive custom UI elements and regions.
You should assign a valid Web Accessibility Initiative - Accessible Rich Internet Applications (WAI-ARIA) role to custom UI elements (for example, interactive div tags) and regions.
For more info, see Role.
Implement keyboard accessibility by doing the following.
- Set the tabindex attribute for interactive elements.
- Implement arrow-key navigation for composite elements.
- Implement keyboard activation.
- Set access keys or implement accelerator keys.
For more info, see Implementing keyboard accessibility.
Set the aria-live attribute for regions that display dynamic content.
Setting aria-live enables screen readers to announce UI changes as they happen.
For more info, see Making live regions accessible.
Make tables accessible by setting an accessible name, headers, and summary or description.
These steps are important for large and complex tables where users need help with understanding data. Don’t forget to mark layout tables with
role="presentation".For more info, see Making tables accessible.
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 Make the computer easier to see in Ease of Access Center.)
- 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 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.
Split pages into logical regions and mark the regions with landmark roles and accessible names. This enables assistive technologies to generate page summaries and provide more efficient navigation.
For more info, see Exposing the logical structure of your app.
Run accessibility tools, address reported issues, and verify the screen reading experience.
Use Inspect to verify programmatic access, run UI Accessibility Checker (AccChecker) to discover common errors, and verify the screen reading experience with Narrator.
For more info, see Testing your app for accessibility.
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 JavaScript and HTML