MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

The latter two we’ve already covered. In Chapter 6, “Layout,” we saw how to work with different
resolution scales, how to handle varying screen sizes (which can occur as a result of scaling), and how to
provide raster graphics for different scales so that they always look their best. For a quick review, you
might want to revisit the Scaling according to DPI sample.
Input considerations were also covered in Chapter 9, and I’ll remind you again that the Store
certification policy (section 3.5) requires that apps support all forms of input. Typically, this isn’t an issue
for mouse and touch; the real work to be done is making sure that your app can be used with nothing
but a keyboard. As noted in Chapter 9, see Implementing keyboard accessibility for full details. Testing
your app with Narrator turned on will also reveal whether you’ve paid any attention to keyboard
navigation, because no matter how well your elements are labeled for that purpose, those labels don’t
do any good if the user can never set the focus to them!
It’s also worth mentioning that including closed captions in video will assist users who are hearing
impaired. Doing so, however, is a detail for the video data itself or can be implemented via text overlays
on a video element. See the HTML5 and Accessibility in MSDN Magazine for more on video accessibility.
Let’s now look at how we support screen readers and contrast variations.
Sidebar: Accessibility Test Tools
The Windows SDK includes two tools to help you verify your implementation of accessibility. The
first is called Inspect, a UI automation tool that checks through the accessibility information
you’ve made available to screen readers and lets you know what you’ve missed. The second is
called AccChecker, which runs a series of verifications on the rest of the app. You’ll find these tools
in the Windows SDK install folder, typically c:\Program Files (x86)\Windows Kits\8.0\bin\x86. You
might also be interested in the Accessible Event Watcher and the UI Automation Verify tools. For
usage details on all of these, see Automation Testing Tools in the documentation as well as
Testing your app for accessibility. Of course, for the most complete kind of testing, find yourself a
few users who regularly work with assistive technologies, set them up with a developer license (so
that you can share your app package), and let them put your app through its paces!
Sidebar: Narrator and tabindex Attributes
When making your app navigable by keyboard, be careful not to overuse tabindex attributes on
elements that don’t need them, thinking that this will help Narrator for noninteractive elements. It
actually doesn’t. Narrator has its own keyboard commands (like CapsLock+arrows) and its own
navigation modes that skilled users employ to read anything on a page, irrespective of tabindex.
For this reason, setting tabindex properties on static elements decreases Narrator’s usability; you
should set the property only on interactive elements. In other words, understand that using an
app through keyboard and using it through Narrator are different processes, and think only of
tabindex in the context of keyboard navigation.
783