Technique SL30:Using Silverlight Control Compositing and AutomationProperties.Name
About this Technique
This technique is not referenced from any Understanding document.
This technique applies to content implemented in Microsoft Silverlight.
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>
Related Resources
No endorsement implied.
Tests
Automation tree verifier
Procedure
- Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.
- 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.)
- Check that the
AutomationProperties.Name
appears as theName
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
- Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.
- 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.
- 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.