Techniques for WCAG 2.0

Skip to Content (Press Enter)

-

SL30: Using Silverlight Control Compositing and AutomationProperties.Name

Important Information about Techniques

See Understanding Techniques for WCAG Success Criteria for important information about the usage of these informative techniques and how they relate to the normative WCAG 2.0 success criteria. The Applicability section explains the scope of the technique, and the presence of techniques for a specific technology does not imply that the technology can be used in all situations to create content that meets WCAG 2.0.

Applicability

This technique relates to:

User Agent and Assistive Technology Support Notes

See User Agent Support Notes for SL30. Also see Silverlight Technology Notes.

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

Example 1: 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.

Example 2: 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>

Resources

Resources are for information purposes only, no endorsement implied.

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.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

Tests

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.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.