Creating Accessibility-aware Silverlight 2 Content

If you haven't heard, accessibility is one of the most important aspects of a Web site experience. By using the accessibility features in Silverlight™ 2, you can provide the best experience for all users. Building a rich Internet experience can be a daunting task when you have to balance a cool visual design with usability.

Usability goes beyond the initial determination that a user interface (UI) "makes sense" as the UI has to be accessible to everyone. Silverlight 2 enables building a cool and accessible experience, whether you are building an entire Silverlight application or just a few Silverlight controls. This article provides you with guidelines for taking advantage of these features and building an accessible Silverlight application.

If you attempted to add accessibility to your Silverlight 1 content, you probably found that there wasn't much support except for something analogous to "alt" text for screen readers. Silverlight 2 on the other hand provides necessary features that you can build on.

In general, when you build your Web application with accessibility in mind, there are a general set of areas to think about:

• Screen reader support.
• Keyboard navigation.
• High contrast presentation.

Ensuring Your Silverlight 2 Content Supports Screen Readers

Silverlight 2 provides information to screen readers about your application via the new UI Automation framework. At the application level, you work with UI Automation using the AutomationProperties class and its corresponding properties. When creating custom controls or extending controls, you work with AutomationPeer and the UI Automation provider interfaces. This article looks at some important UI Automation concepts you should be aware of as you build your Silverlight 2 application.

Silverlight Accessibility Tree

Your Silverlight 2 application is comprised of many visual elements from Borders to Control-based elements. For the most part, you can split the visual elements into two types: simple visuals that usually derive directly from the FrameworkElement class, or functional controls that derive from the Control class. A TextBlock, Image, or MediaElement are examples of simple visuals while a Button, TextBox, or ListBox are examples of functional controls.

Along with the visual tree of elements, your Silverlight 2 application has a corresponding accessibility tree. UI Automation presents three accessibility views of the visual tree: a control view, a content view, and a raw view. Generally, all elements that derive from Control show up in the control view while elements that derive directly from FrameworkElement show up in the content view. TextBlock can appear in either the content view when used inside a control or data template or the control otherwise. If you create custom Silverlight controls, you can identify whether it’s a control, content, or both (or none).

There are different ways to think of elements being visible or invisible. Silverlight 2 reports elements whose Visibility property is equal to Visibility.Collapsed as hidden, but reports elements that are in the tree and "hidden" from view as being visible elements. This distinction is important because you might style your app to have different UI "modes" by just z- ordering the elements. If you have reasons for not setting the Visibility property, then you should at least disable controls that are "hidden" from view to ensure that screen readers don't attempt to interact with them.

XAML Tag Your Elements

As you develop your Silverlight application, you sometimes need to provide additional accessibility information to ensure your content is readable. For example, screen readers won't know anything about your Image element except that it is an image. As with HTML, you need to provide "alternative" text-based information. With Silverlight, you provide alternative accessibility information by using the AutomationProperties static class.

There are cases when you won't have to add additional markup via AutomationProperties. For example, controls that have text in them (like Buttons) already provide default information. In other cases, you do need to provide additional data.

Using AutomationProperties is very easy both in your XAML markup and in code. Using the Image element as an example, you set the AutomationProperties.Name attribute with XAML markup like this:

In code, you use the appropriate attached property set/get method:

For best practices on providing good alternative text, see the MSDN technical article "Creating Text Equivalents for Images" (http://msdn.microsoft.com/en-us/library/ms971334.aspx).

Sometimes you might have a TextBox, Image, or other control labeled with text. For example, a TextBox for the user's name might have text to the left specifying "Name:". You can use the TextBlock element to provide that static text label, and the AutomationProperties.LabeledBy property to tell that the TextBlock is labeling the TextBox. Because Silverlight 2 does not support element Binding syntax (using the ElementName syntax) to set the LabeledBy property in XAML, you have to resort to some code, like this XAML:

Then you set the LabeledBy property like so:

To properly support screen readers, you need to ensure that all your non-text controls that show up in the accessibility tree provide at least the AutomationProperties.Name value. I recommend that you spend the time to provide other values such as HelpText. There are some great accessibility verification tools recently released by Microsoft that work great with UI Automation. Check it out by searching for Microsoft Accessibility Labs on MSDN.

UI Automation and Microsoft Active Accessibility Screen Readers-Bridging the Gap

As I've mentioned earlier, Silverlight 2 relies on the operating system's UI Automation support. This does not imply that only UI Automation-based screen readers are supported. On supported operating systems, Microsoft® Active Accessibility®-based screen readers can read Silverlight 2 content via the UI Automation UIA-to-MSAA Bridge. Because the accessibility technologies are somewhat different, not all data transfers into Microsoft Active Accessibility properties and some concepts are simplified.

For more information on the UIA-to-MSAA bridge, see the Windows Automation API 3.0 Overview article by Masahiko Kaneko in this issue. In addition, you can search MSDN for Active Accessibility Bridge to UI Automation for specific details on the limitations.

By: Mark Rideout

Mark Rideout is a Program Manager on the Silverlight Team at Microsoft. Mark is responsible for features around text and text input in addition to input and accessibility features. Mark has worked on multiple Microsoft UI frameworks such as Windows Forms and has been working with the .NET Framework since 1.0. Mark started at Microsoft in 1997, and prior to that, Mark worked as a consultant where he designed and developed business applications.

Mark enjoys everything Lego, pinball, and Disneyland. He enjoys teaching his 2-year-old daughter about everything he likes.

markri@microsoft.com