Silverlight Accessibility for Developers
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:
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 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.
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:
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.
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:
Then you set the LabeledBy property like so:
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”);
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.
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.
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." />
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
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:
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.