Skip to main content

Silverlight Accessibility for Developers

Overview

Welcome to the Silverlight Accessibility for Developers course. This course is tailored to your role as a developer using Silverlight and will give you specific skills and tools to create more accessible, user-friendly products.

As a result of this course, you will be able to:

  • Explain how UI Automation (UIA) and Silverlight work to create accessible code
  • Identify and address Silverlight-specific accessibility pitfalls

Welcome

Microsoft Silverlight powers rich application experiences and delivers high-quality, interactive video across the Web and mobile devices through the most powerful runtime available on the Web. Making these applications accessible requires planning and empowers more customers to experience your product. Taking the time to make Silverlight accessible may enrich the experience of all users.

This course assumes that you have a working knowledge of Windows Presentation Foundation (WPF) and Web developer accessibility.

This course is organized to help you locate information quickly when you need it, and is laid out in the following manner:

  • Programmatic Access
  • Keyboard Navigation
  • System Settings
  • Controls

Programmatic Access

Programmatic access involves ensuring all user interface (UI) elements are exposed programmatically to the assistive technology (AT). In Silverlight, programmatic access is achieved in a similar way to WPF. This course addresses the exceptions, where different implementations are required.

Silverlight applications are created using a subset of the WPF framework, which uses the UI Automation (UIA) API for programmatic access. If you have correctly implemented common controls in Silverlight, UIA default information will be provided automatically, as it would in WPF. To implement a common control properly, you must be sure to provide a name and automation ID for the control.

Automation Properties

In Silverlight, you work with UIA using the AutomationProperties class and its corresponding properties. As with WPF, creating custom controls or extending controls means working with the AutomationPeer and the UIA provider interfaces. Silverlight is similar to WPF, but the implementation is slightly different. You will learn more about that in a moment.

Silverlight on the Web

Because Silverlight is commonly implemented in Web pages, be aware of the issues that Web sites bring into the picture. HTML is presented through the browser using mappings from MSAA and the DOM. Silverlight, when implemented in a Web page, is a separate container that does not interact with the Web page. As a result, Silverlight doesn’t update the DOM or use MSAA. Instead, it uses UIA only to communicate with AT.

When designing accessible Web pages or applications, it helps to understand how information flows between user and the browser or application. The user conveys and receives information through the AT. Information moves in a variety of ways from the AT, depending on whether MSAA or UI Automation is implemented, and whether a screen reader that uses the DOM is involved.

In the case of MSAA, information such as properties and events are conveyed between the browser or client application and the AT.

In some cases, where the AT employs a different API from what the application uses, a bridge or proxy is used to convert information into the appropriate API for the AT. For example, an application that employs Silverlight and uses UI Automation would use the UI Automation-to-MSAA Bridge to convert information into MSAA for AT that uses MSAA.

If UI Automation is involved, then information is conveyed between the browser, client application, or Silverlight application and the AT.

Some screen readers take a virtual screenshot of a Web page using the DOM and work directly through the browser without interpreting through MSAA or UI Automation.

Silverlight Automation Tree

Silverlight is composed of many visual elements, from borders to control-based elements. UI Automation (UIA) uses these elements to create a UI Automation Tree (UIA Tree) for your product, and there are three views available to users of AT: raw view, content view, and control view. Users may or may not ever see all three views, depending on their needs and preferences.

Visual elements can be generally divided into two types:

  • Simple Visuals: usually derived directly from the FrameworkElement class. These visuals appear in the content view of the UIA Tree. Examples are Image and MediaElement.
  • Functional Controls: derived from the Control class. These controls appear in the control view of the UIA Tree. Examples are Button, TextBox, or ListBox.

Custom Controls - When you create custom controls, you can identify whether it’s a control, content, both, or none.

TextBlocks- Textblock can appear in either the content view, such as when used inside a control or data template, or the control view.

Visibility Property - If the Visibility property is equal to Visibility. Collapsed in your product, then it does not hide that element from the UIA Tree. If you do not wish to set the Visibility property, then disable controls that are hidden from view in order to prevent users of AT from trying to interact with them.

Labels

Much like Web accessibility, you can use the Label element for controls in Silverlight as well. For example, a TextBox for the user's name might have text to the left that says “Name.” Use the TextBlock element to provide the static text label and the AutomationProperties. LabeledBy property to attach the TextBlock as a label for the TextBox.

Setting the LabeledBy Property

Silverlight does not support element Binding syntax (using the ElementName syntax) to set the LabeledBy property in XAML, so you will need to address this issue. Here is an example:

<StackPanel Orientation="Horizontal">
    <TextBlock Text="Name:" x:Name="nameLabel"/>
    <TextBox Width="100" x:Name="nameInput"/>
</StackPanel>

Then you set the LabeledBy property like so:

AutomationProperties.SetLabeledBy(this.nameInput, this.nameLabel);

Additional Properties: Users do not always know what to do with controls or elements. In addition to using the AutomationProperties.Name value to give the element or control a name, provide values such as HelpText to assist with this issue.

<Button x:Name=”toggleButton” AutomationProperties.Name=”Switch” AutomationProperties.HelpText=”Click to toggle this switch on or off.” />

Alt Text in Silverlight

The same principles of alternative text (alt text) for the Web apply in Silverlight, but the implementation is done using the AutomationProperties static class. Controls that already have text in them, such as Button, do not need alt text. In the case of other images or controls without text, alt text must be provided. For information about alt text best practices, read the MSDN article “ Creating Text Equivalents for Images”.

To create alt text or name your element in the XAML, use the AutomationProperties.Name attribute. For example, using an Image element, the XAML would look like the following:

<Image x:Name="image" Source="/georgewashingtondelaware.png" AutomationProperties.Name="George Washington as he crosses the Delaware"/>

Or in the code, you would include:

AutomationProperties.SetName(this.NameInput “George Washington as he crosses the Delaware”);

Windowless Mode

Using the Windowless Mode in Silverlight renders it inaccessible. AT clients are unable to see the Silverlight application in the UI Automation (UIA) Tree in this situation. Using the standard mode eliminates this issue. When choosing how to set up your Silverlight project, be aware that a choice to use Windowless Mode means you will need to create an alternate, accessible option as well, which can increase project costs significantly. The value of Windowless Mode for your product must be considered carefully.

Keyboard Navigation

You must plan for effective keyboard interactions in your product. Think through the navigation for the product, which items should receive keyboard focus, and how non-text items will be labeled to provide the best experience for users. This section addresses specific ways to handle these issues in Silverlight.

Keyboard User Interface Design: For more information on keyboard best practices, see the Guidelines for Keyboard User Interface Design on the MSDN Web site.

Tab Order

To control the tab order in Silverlight, set the TabIndex property. Also, be aware that users cannot tab into and out of Silverlight applications except in Internet Explorer.

<Button x:Name="toggleButton" TabIndex="2" AutomationProperties.Name="Switch" AutomationProperties.HelpText="Click to toggle this switch on or off." />

Keyboard Focus

To specify what controls can receive keyboard focus, use the IsTabStop property. Only Control-based elements can receive keyboard focus. Most Silverlight controls already set the IsTabStop property to true, such as Button.

Setting Focus for a Silverlight-Only Application

In the case where the Web page is a Silverlight-only application (i.e. a complete Silverlight submersion experience), JavaScript will need to be created to create keyboard focus on a fully-embedded control; otherwise, AT is unable to recognize the controls within the page. For example, calling the Focus() method on the HTML page. Or you can do it in the Silverlight code:

public Page()







        {







            InitializeComponent();







            Loaded += new RoutedEventHandler(Page_Loaded);







        }















        void Page_Loaded(object sender, RoutedEventArgs e)







        {







             System.Windows.Browser.HtmlPage.Plugin.Focus();















        }

Sample code from Microsoft Silverlight website.

Non-Control-Based Elements Focus

In Silverlight, only control-based elements can receive focus, which presents accessibility issues when interactivity for mouse actions is added to items such as Image, Path, or MediaElement. To offer access to AT users, there are two options:

  1. Enable the functionality with a keyboard command or with a control in the UI. This option is a quick and easy approach, but it is not as accessible in many cases as the second option. It will not address navigational reading order, for example.
  2. Enable focus by creating a custom UserControl element that contains the Image, and add the keyboard logic there. This approach keeps the vertical reading order intact for users of AT who navigate the page using a Logical Hierarchy. The custom approach normally includes the addition of assigning a keyboard shortcut. MSAA-based screen  readers commonly read out text or alternative text (alt text) only when the item receives focus. By enabling a user to tab to a TextBlock or Image, it forces some screen readers to read the content. In addition, if you handle mouse-down on the Image to perform an action, you would then need to provide a keyboard accessible way for the user to tab to the image and invoke the same action as well. Note: A visual focus indication will also need to be provided for this option, which will be addressed later in this course.

Some images have information which pops up when a mouse rolls over the image. The images that cannot receive keyboard focus prevent users who do not use a mouse from seeing the popup information. Other images, however, can receive keyboard focus. Users without a mouse can access the popup information by putting focus on the image and reading the alt text associated with it.

Rate: