Silverlight Accessibility Overview

Accessibility and Developer Scenarios in Silverlight

Accessibility concepts in Silverlight programming and development can be divided into two areas: accessibility for Silverlight application authors who are using existing controls in their application UI, and accessibility for custom control authors.

Consumers of existing controls can report accessibility-related information as part of their application functionality and UI design by relying on accessibility exposure of general-purpose control properties such as TextBox.Text. This is possible because the code support for control classes such as TextBox already implements Microsoft UI Automation support and forwards many of the user-defined property values to Microsoft UI Automation API and clients. Such control classes implement an automation peer class that parallels the control class when it is represented in the Microsoft UI Automation system. The peer classes expose automation patterns through interfaces that are consumable without callers needing to know the specific object model of a control.

Consumers of existing controls can also report or change information that is specifically accessibility-related by setting values for the Silverlight accessibility properties implemented by the class AutomationProperties.

Custom control authors who want their controls to support Microsoft UI Automation with Silverlight can inherit the accessibility support that is provided by the control base class. For example, if you derive from TextBox, by default, Microsoft UI Automation treats the derived class the same as if it were a TextBox instance. The technical connection point for this behavior is the callback method UIElement.OnCreateAutomationPeer. You can check the documentation for a particular control class override of UIElement.OnCreateAutomationPeer to learn more about which specific automation peer class each control associates itself with. Typically, there is a name relationship convention between controls and peers, but UIElement.OnCreateAutomationPeer defines the true behavior. By reading documentation for the peer class, you can learn more about the accessibility support that is enabled by default. The default applies if you derive from a control and inherit its existing peer and UIElement.OnCreateAutomationPeer override, without defining any custom automation peers. This documentation about the default behavior can help you decide whether the UI capabilities that are exposed by your custom control are already correctly exposed for accessibility, or whether you have to define a custom automation peer to provide better automation and accessibility information through your control.

For more information about the concepts and procedures you use to define a custom automation peer for a Silverlight control or UI element, see UI Automation of a Silverlight Custom Control.

Accessibility Properties

In addition to supporting Microsoft UI Automation, Silverlight also exposes properties in its control model that can be used to transmit accessibility-related information in a control UI declaration, typically in XAML. This could be done through a control template, or through setting properties on an instantiated control after the template is applied. The accessibility properties can override any defaults that are provided by existing Silverlight control behavior and peer implementations. You can do this for instances of controls, without having to address any aspect of the control backing code. You can set accessibility properties in code constructor calls, in instantiating XAML, or in XAML styles or templates. You can also use Silverlight data binding to provide accessibility information for cases where other aspects of the UI are already using data binding or data templates.

The accessibility properties are implemented as attached properties. Attached properties for Silverlight can be set on any Silverlight object that derives from DependencyObject, which encompasses all controls and nearly all objects that have a direct UI representation. Typically, attached properties are set in XAML, but they can also be set in code using the dedicated set accessor in the attached property owner class. The class that implements the attached properties for accessibility support in Silverlight is AutomationProperties.

For more information about how to use instance-specific accessibility properties, see Automation Properties for Accessibility Support in UI.

Media Captioning

Accessibility support sometimes includes providing text captioning for video content. This is enabled in Silverlight through encoding the information in the video source file, but is not described in this topic. For more information, see the MSDN documentation for Expression Encoder. Or see Audio and Video.

Tab Sequences

One aspect of UI design that is useful as an accessibility technique is the creation of a tab sequence. The tab sequence enables users who may not be able to use a mouse to navigate the controls of a Silverlight application by using only the keyboard. The control that is currently tabbed to becomes the focused control, and becomes the source of keyboard events. Keyboard events are relevant either for capturing accelerator key sequences, or for control-specific actions that use keyboard input. For example, after a TextBox is tabbed to, a user types with the keyboard, and the TextBox displays each character as it is typed.

Silverlight automatically creates a default tab sequence based on the order of elements in the object tree. To be in the tab sequence, an element must be a Control derived class, and must be enabled and visible. To maintain an appropriate tab sequence, you should attempt to keep the order of elements as defined in XAML or code in parallel with the visible layout that results in your application. For cases where the default tab sequence does not traverse the elements in a way that is intuitive to users, you can override specific parts of the tab sequence. To override portions of the default tab sequence, declare TabIndex values on the relevant control elements. You can also enable specific tab navigation models for certain controls or blocks of controls in order to streamline the tab sequence for application UI that includes many controls. For more information on tab sequences, see Focus Overview.

Accessibility, UI Automation, and Testing

In addition to providing support for accessibility in platforms and applications, Microsoft UI Automation can also be used to provide the basis for a testing automation framework. This aspect of Microsoft UI Automation is not discussed in this topic; this topic focuses on the accessibility aspects of Microsoft UI Automation.

Microsoft does provide some unit testing frameworks for Silverlight. However, these are not part of the default Silverlight tools for Visual Studio, or the SDK, and are therefore not discussed in this topic. For more information, search MSDN for "Silverlight Unit Testing Framework."

Themes and Templates for High Contrast

Silverlight exposes a property SystemParameters.HighContrast that can be used to determine whether the Silverlight application is running in a high contrast mode. This determination is made based on settings of the operating system instead of specific hosts. (The hosts themselves also often use techniques to read contrast information from the operating system, and might display differently.)

Based on reading SystemParameters.HighContrast either at application startup or during application lifetime, you might consider supplying an alternate control template, alternate color resources from your resource dictionaries, override styles, run-time changes to property values, or any combination of these techniques. Any of these techniques are potentially valuable for the accessibility aspects of your control if the user wants to use a high-contrast mode for display.

UI Automation and Platforms

As stated previously, Microsoft UI Automation is the accessibility framework for Microsoft Windows. The Microsoft UI Automation system relies on the presence of several DLLs on the client system, especially the UIAutomationCore.dll. These DLLs are not part of the Silverlight core redistributable, and they typically only exist on the client when that client is running a Microsoft Windows operating system. When UI Automation is available on the client system, Silverlight has providers, peers, and patterns that support it. On other platforms, Silverlight does not support UI Automation.

Microsoft UI Automation is supported on Microsoft Windows operating systems, both when hosted by one of the browser hosts supported under that platform, or when running out-of-browser. In the browser hosted case, the browser host is an intermediate in the Microsoft UI Automation exposure of the UI, and may have providers of its own to support the UI that surrounds any hosted content (Silverlight or otherwise), such as menus and dialog boxes.

UI Automation Tools and General UI Automation Development

This topic and the related Silverlight documentation do not attempt to explain the basics of accessibility and UI automation for clients, or for specific devices or input methods.

Microsoft UI Automation is a broad technology that Silverlight supports. Tools and techniques are available for general implement of Microsoft UI Automation on supported platforms, and you can apply these tools to Silverlight development.

For information about programming for UI Automation client tools, see UI Automation Clients for Managed Code in the .NET Framework documentation.

For information about programming best practices for accessibility, see Accessibility Best Practices in the .NET Framework documentation.

UI Automation uses control patterns to represent common control behaviors. These control patterns resemble those that are defined in the .NET Framework. For information about the control patterns that are defined in the .NET Framework, see UI Automation Control Patterns Overview in the .NET Framework documentation.

See Also

Reference

Concepts