Accessibility in Windows Store apps built for Windows using C++, C#, or Visual Basic (Windows)

Language: JavaScript and HTML | VB/C#/C++ and XAML

7 out of 10 rated this helpful - Rate this topic

Roadmap: How does this topic relate to others? See:

This topic describes some of the concepts and technologies that relate to accessibility scenarios in a Windows Store app built for Windows using C++, C#, or Visual Basic.

Prerequisites

This topic assumes that you know how to create a basic Windows Store app. For instructions on creating your first Windows Store app using C++, C#, or Visual Basic, see Create your first Windows Store app using C# or Visual Basic or Create your first Windows Store app using C++.

Accessibility and your app

Accessibility is about making your applications usable by people who have limitations that prevent or impede the use of conventional user interfaces. For some applications, accessibility requirements are imposed by law. However, it's a good idea to address accessibility issues regardless of legal requirements so that your applications have the largest possible audience.

There are many possible disabilities or impairments, including limitations in mobility, vision, color perception, hearing, speech, cognition, and literacy. However, you can address most requirements by following the guidelines offered here. This means providing:

Support for keyboard interactions and screen readers.
Support for user customization, such as font, zoom setting (magnification), color, and high-contrast settings.
Alternatives or supplements for parts of your UI.

The Windows 8 controls for a XAML UI provide built-in keyboard support and support for assistive technologies such as screen readers, which take advantage of accessibility frameworks that already support apps, HTML, and other UI technologies. This built-in support enables a basic level of accessibility that you can customize with very little work, by setting just a handful of properties. If you are creating your own custom XAML components and controls, you can also add similar support to those controls by using the concept of an automation peer.

In addition, data binding, style, and template features make it easy to implement support for dynamic changes to display settings and text for alternative UIs.

UI Automation

Accessibility support for Windows Store apps using C++, C#, or Visual Basic comes primarily from the integrated support for the Microsoft UI Automation framework that is present in the base classes and the built-in behavior of the class implementation for control types. Each control class uses the UI Automation concepts of automation peers and automation patterns that report the control's role and content to UI Automation clients. The Windows Store app is treated as a top-level window by UI Automation, and all the content within that app window is reported to and available to a UI Automation client. For more info about UI Automation, see UI Automation Overview.

Assistive technology

Many user accessibility needs are met by assistive technology products installed by the user or by tools and settings provided by the operating system. This includes functionality such as screen readers, screen magnification, and high-contrast settings.

Assistive technology products include a wide variety of software and hardware. These products work through the standard keyboard interface and accessibility frameworks that report information about the content and structure of a UI to screen readers and other assistive technologies. Examples of assistive technology products include:

On-screen keyboard software, which enables people to use a pointer in place of a keyboard.
Voice-recognition software, which converts spoken words into typed text.
Screen readers, which convert text into spoken words or other forms such as Braille.

Apps that have good keyboard and screen reader support usually work well with various assistive technology products. In many cases, a Windows Store app works with these products without additional modification of information or structure. However, you may want to modify some settings for optimal behavior or to implement additional support.

Some of the options that you can use for testing basic accessibility scenarios with assistive technologies are listed in Testing your app for accessibility.

Screen reader support and basic accessibility information

Screen readers provide access to the text in an application by rendering it in some other format, such as spoken language or Braille output. The exact behavior of a screen reader depends on the software and on the user's configuration of it.

For example, some screen readers read the entire app UI when the user starts or switches to the application, enabling the user to receive all of the available informational content before using tab navigation. Some screen readers also read the text associated with an individual control when it receives focus during tab navigation. This enables users to orient themselves as they navigate among the input controls of an application. Narrator is an example of a screen reader that provides both behaviors.

The most important information that a screen reader or any other assistive technology needs in order to help users understand or navigate an app is an accessible name. In many cases a control or element already has an accessible name that is calculated from other property values that you have otherwise provided. The most common case in which you can use an already-calculated name is with an element that supports and displays inner text. For other elements, you sometimes need to account for other ways to provide an accessible name by following best practices for element structure. And sometimes you need to provide a name that is explicitly intended as the accessible name for app accessibility. For a listing of how many of these calculated values work in common UI elements, and for more info about accessible names in general, see Exposing basic accessibility information about UI elements.

There are several other automation properties available (including the keyboard properties described in the next section). However, not all screen readers support all automation properties. In general, you should set all appropriate automation properties and test to provide the widest possible support for existing and future screen readers.

Keyboard support

To provide good keyboard support, you must ensure that every part of your application can be used with a keyboard. If your app uses mostly the standard controls and doesn't use any custom controls, you are most of the way there already. The basic Windows Store app using C++, C#, or Visual Basic control model provides built-in keyboard support including tab navigation, text input, and control-specific support. The elements that serve as layout containers (such as panels) use the layout order to establish a default tab order. That order is often the correct tab order to use for an accessible representation of the UI. If you use ListBox and GridView controls to display data, they provide built-in arrow-key navigation. Or if you use a Button control, it already handles the Spacebar or Enter keys for button activation.

For more info about all the aspects of keyboard support in a Windows Store app using C++, C#, or Visual Basic, including tab order and key-based activation or navigation, see Implementing keyboard accessibility.

Media and captioning

For a Windows Store app using C++, C#, or Visual Basic, you typically display audiovisual media through the MediaElement class. You can use members of this class to control the media playback. For accessibility purposes, provide controls that enable users to play, pause, and stop the media as needed. Media sometimes includes additional components that are intended for accessibility, such as captioning or alternative audio tracks that include narrative descriptions. For more info about concepts related to media, MediaElement, and accessibility, see Making media content accessible.

Accessible text

Three main aspects of text are relevant to accessibility:

Tools must determine whether the text is to be read as part of a tab-sequence traversal or only as part of an overall document representation. You can help control this determination by choosing the appropriate element for displaying the text or by adjusting properties of those text elements. Each text element available in a Windows Store app using C++, C#, or Visual Basic has a specific purpose, and that purpose often has a corresponding UI Automation role. Using the wrong element can result in reporting the wrong role to UI Automation and creating a confusing experience for an assistive technology user.
Many users have sight limitations that make it difficult for them to read text unless it has adequate contrast against the background. How this impacts the user is not intuitive for app designers who do not have that sight limitation. For example, for color-blind users, poor color choices in the design can prevent some users from being able to read the text. Accessibility recommendations that were originally made for web content define standards for contrast that can avoid these problems in apps as well. For more info, see Meeting requirements for accessible text.
Many users have difficulty reading text that is simply too small. You can prevent this issue by making the text in your app's UI reasonably large in the first place. However, that's challenging for apps that display large quantities of text, or text interspersed with other visual elements. In such cases, make sure that the app correctly interacts with the Make everything on your screen bigger system feature that can scale up the entire UI, so that any contained text scales up along with it. Make everything on your screen bigger is an on/off setting that is in the Ease of Access area of PC settings for Windows 8.

Supporting high-contrast themes

The UI controls that are provided for Windows Store apps using C++, C#, or Visual Basic use a visual representation that is defined as part of a XAML resource dictionary of themes. One or more of these themes is specifically used when the system is set for high contrast. When the user switches to high contrast, by looking up the appropriate theme from a resource dictionary dynamically, all your UI controls will use an appropriate high-contrast theme too. Just make sure that you haven't disabled the themes by specifying an explicit style or using another styling technique that prevents the high-contrast themes from loading and overriding your style changes. For more info, see Supporting high contrast themes.

Design for alternative UI

In general, when you design your applications, think about how they may be used by people with limited mobility, vision, and hearing. Because assistive technology products make extensive use of standard UI interfaces, it is particularly important to provide good keyboard and screen-reader support even if you make no other adjustments for accessibility.

In many cases, you can convey essential information by using multiple techniques to widen your audience. For example, you can highlight information using both icon and color information to help users who are color blind, and you can display visual alerts along with sound effects to help users who are hearing impaired.

If necessary, you can provide alternative, accessible user interface elements that completely remove nonessential elements and animations, and provide other simplifications to streamline the user experience. The following code example demonstrates how to display one UserControl instance in place of another depending on a user setting.

XAML


<StackPanel x:Name="LayoutRoot" Background="White">

  <CheckBox x:Name="ShowAccessibleUICheckBox" Click="ShowAccessibleUICheckBox_Click">
    Show Accessible UI
  </CheckBox>

  <UserControl x:Name="ContentBlock">
    <local:ContentPage/>
  </UserControl>

</StackPanel>


private void ShowAccessibleUICheckBox_Click(object sender, RoutedEventArgs e)
{
    if ((sender as CheckBox).IsChecked.Value)
    {
        ContentBlock.Content = new AccessibleContentPage();
    }
    else
    {
        ContentBlock.Content = new ContentPage();
    }
}

Verification and publishing

For more info about accessibility declarations and publishing your app, see Declaring your app as accessible in the Windows Store.

Assistive technology support in custom controls

When you create a custom control, we recommend that you also implement or extend one or more AutomationPeer subclasses to provide accessibility support. In some cases, so long as you use the same peer class as was used by the base control class, the automation support for your derived class might be adequate at a basic level. However, you should test this, and implementing a peer is still recommended as a best practice so that the peer can correctly report the class name of your new control class. Implementing a custom automation peer has a few steps involved. For more info, see Custom automation peers.

Accessibility in Windows Store apps built for Windows using C++, C#, or Visual Basic