# Using Silverlight Control Compositing and AutomationProperties.Name

ID: SL30

Technology: silverlight

Type: Technique

## When to Use

- Microsoft Silverlight, versions 3 and greater
- Silverlight managed programming model and Silverlight XAML

## Description

The objective of this technique is to properly apply Silverlight control composition techniques that can present text and non-text in UI as part of the same control. This technique explains the consequences that using control composition has on how that control is reported to the accessibility frameworks that Silverlight supports.

Silverlight control composition concepts are relevant either to Silverlight developers who define and package a Silverlight control for use by other Silverlight authors, or for Silverlight application authors that use Silverlight controls in their UI but use the content properties of such controls to include several other elements in a composite layout.

In Silverlight programming and UI definition, Silverlight authors can use control composition to define a parent control that initiates an action. The control can have component parts, such as text and non-text composition pieces that display within the control and have equivalent meaning. Silverlight authors can rely on the text component of the control to provide any text alternative for purposes other than the accessibility framework. However, Silverlight authors should declare alternative text on the control that is specifically consumed by accessibility frameworks, by setting `AutomationProperties.Name` as an attribute in XAML. In most cases, this text can be the same as the visible text in the control composition, per the definition of 'label' in SC 4.1.2.

Note that this technique does not result in a duplication of text, as explained in H2. This is because the element parts of control composition are either inherently not focusable separately, or can be specified by instance-specific properties to behave as if they cannot be focused. The parts in Silverlight composition are not promoted to the accessibility frameworks as parts of an application-specific UI Automation tree, so that control composition as an implementation detail does not interfere with the usage of controls by Silverlight application authors. The primary source of accessibility-related information is the specific `AutomationProperties.Name` property as set on the parent control in the composition, which is set by the application author rather than the control author.

The control author does specify the information that is reported to accessibility frameworks as the "ClassName", which is often used by assistive technologies for identification purposes and is appended to any "Name" value. For example, if an application author includes a "Widget" control, and gives it an `AutomationProperties.Name` value of "Show Map", an assistive technology might identify the element as "Show Map widget". The "Show Map" part comes from the application author code, and the "widget" part comes from the Widget control implementation code.

## Examples

### Button is composed with a StackPanel that contains nontext and text content

In this example the `TextBlock` that goes with the graphic image conveys the text information for non-accessibility purposes. The `Button` has internal composition that combines text from a non-focusable `TextBlock` part and an image part. Therefore the "Pause" Text is not promoted to serve as "Name" through built-in `Button` automation peer logic. The Silverlight application author is responsible for explicitly setting `AutomationProperties.Name` on the `Button` so that the text equivalent is available to the accessibility framework. This example shows the XAML UI. The logic, which might be attached to `Button` with a Click handler, is not shown.

     <Button
       Height="20" Width="50" AutomationProperties.Name="Pause"
     >
       <StackPanel Orientation="Horizontal" >
         <Image Height="12" Width="12" Source="/icon_pause.png"/>
         <TextBlock Text="Pause"/>
       </StackPanel>
     </Button>

This example is shown in operation in the working example of Button Nontext Text Composition.

### Button composed, using binding and resource references for strings

This example is similar to Example 1 and produces the same result at run time. This example shows the preferred technique of using the Silverlight data binding and resource features to ensure that the strings for text content and accessibility are the same strings. Also, this gets the strings out of the XAML source and makes them simpler to localize or edit. For more information on using resource strings through binding, see Localizing XAML topic on MSDN.

     <Application.Resources>
      <resx:Resources x:Key="UIResourceStrings" />
     </Application.Resources>
      ...
     <Button
       Height="20" Width="50"
       AutomationProperties.Name="{Binding PauseUIString, Source=UIResourceStrings}" />
     >
       <StackPanel Orientation="Horizontal" >
         <Image Height="12" Width="12" Source="/icon_pause.png"/>
         <TextBlock
           Text="{Binding PauseUIString, Source=UIResourceStrings}"/>
       </StackPanel>
     </Button>

## Tests

### Automation tree verifier

### Procedure

1. Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.
2. Use a verification tool that is capable of showing the full automation tree, and an object’s name text alternative as part of the tree. (For example, use UIAVerify or Silverlight Spy; see Resources links.)
3. Check that the `AutomationProperties.Name` appears as the `Name` value for identification in the automation tree, whenever a composite control that has both text and non-text elements is encountered.

### Expected Results

#3 is true.

#### Screen reader

### Procedure

1. Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.
2. Engage the screen reader. With focus inside the Silverlight content area, press TAB to focus to a composite control where both text and non-text elements are present.
3. Check that the `Name` as applied to the control instance, along with the class name of the control, is read by the screen reader.

### Expected Results

#3 is true.

## Related Techniques

- SL18
- H2

## Resources

- Silverlight Layout System
- AutomationProperties.Name Attached Property
- Tools: SilverlightSpy or UIAVerify