Testing your app for accessibility (HTML)
Looking for the C#/VB/C++/XAML version of this topic? See Testing your app for accessibility (XAML).
If you intend to declare your app as accessible in the Windows Store, you should address all priority 1 errors reported by AccChecker with ARIA web verifications enabled. Addressing accessibility issues means fixing them in the code or, in rare cases, acknowledging that they do not apply to your app and suppressing them.
You can launch the accessibility testing tools either from a Microsoft Visual Studio command prompt or from the Windows SDK tools folder (<install_dir>\Program Files\Windows Kits\<version>\bin\<architecture>).
The best way to test your keyboard accessibility is to unplug your mouse or use the touch keyboard if you are using a tablet device. Test keyboard accessibility navigation by using the Tab key. You should be able to cycle through all interactive UI elements by using Tab key. For composite UI elements, verify that you can navigate among the subelements by using the arrow keys. Finally, make sure that you can invoke all interactive UI elements with the keyboard, typically by using the Enter or Spacebar key.
Use the tools and methods recommended by the World Wide Web Consortium (W3C) to verify that the visible text contrast ratio is at least 4.5:1. The exceptions include inactive UI elements, and logos or decorative text that doesn’t convey any information and can be rearranged without changing the meaning.
Use your app while a high-contrast theme is active to verify that all the UI elements display correctly. All text should be readable, and all images should be clear. If necessary, provide separate versions to use when a high-contrast theme is active.
Verify that your app can be used when Make everything on your screen bigger is turned on in the Ease of Access area of PC settings for Windows 8. Make sure that all controls can be reached, all text is visible, and that no UI elements overlap. If you find any issues, follow the guidelines for layout scaling and provide additional resources for different scaling factors. For more information, see Guidelines for scaling and Testing your app layout.
Use Narrator to test the screen reading experience for your app.
Follow these steps to test your app using Narrator with a mouse and keyboard:
- Start Narrator by pressing Windows logo key + Enter.
- Navigate your app with the keyboard by using the Tab key, the arrow keys, and the Caps Lock + arrow keys.
- As you navigate your app, listen as Narrator reads the elements of your UI and verify the following:
- For each control, ensure that Narrator reads all visible content. Also ensure that Narrator reads each control's name, its state (checked, selected, and so on), and the control type (button, check box, list item, and so on).
- For each table, ensure that Narrator correctly reads the table name, the table description (if available), and the row and column headings.
- For each live region, ensure that Narrator announces live region changes as specified in the HTML markup through aria-live attributes, aria-atomic attributes, and so on.
- If the element is interactive, verify that you can use Narrator to invoke its action by pressing Caps Lock + Spacebar.
- Press Caps Lock + Enter to search your app and verify that all of your controls appear in the search list, and that the control names are localized and readable.
- Turn off your monitor and try to accomplish main app scenarios by using only the keyboard and Narrator. To get the full list of Narrator commands and shortcuts, press Caps Lock + F1.
Use these steps to test your app using Narrator's touch mode:
Note Narrator automatically enters touch mode on devices that support 4+ contacts. Narrator doesn't support multi-monitor scenarios or multi-touch digitizers on the primary screen.
- Get familiar with the UI and explore the layout.
- Navigate through the UI by using single-finger swipe gestures. Use left or right swipes to move between items, and up or down swipes to change the category of items being navigated. Categories include all items, links, tables, headers, and so on. Navigating with single-finger swipe gestures is similar to navigating with Caps Lock + Arrow.
- Use tab gestures to navigate through focusable elements. A three-finger swipe to the right or left is the same as navigating with Tab and Shift + Tab.
- Spatially investigate the UI with a single finger. Drag a single finger up and down, or left and right, to have Narrator read the items under your finger. You can use the mouse as an alternative because it uses the same hit-testing logic as dragging a single finger.
- Read the entire window and all its contents with a three finger swipe up. This is equivalent to using Caps Lock + W.
If there is important UI that you cannot reach, you may have an accessibility bug.
Interact with a control to test its primary and secondary actions, and its scrolling behavior.
Primary actions include things like activating a button, placing a text caret, and setting focus to the control. Secondary actions include things like selecting a list item or expanding a button that offers multiple options.
- To test a primary action: Double tap, or press with one finger and tap with another.
- To test a secondary action: Triple tap, or press with one finger and double tap with another.
- To test scrolling behavior: Use two-finger swipes to scroll in the desired direction.
Some controls provide additional actions. To display the full list, enter a single four-finger tap.
If a control responds to the mouse or keyboard but does not respond to a primary or secondary touch interaction, the control might need to implement additional UI Automation control patterns.
Build date: 11/26/2013