Relying on Silverlight AutomationPeer Behavior to Set 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.1 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.1.

Applicability

Note

Microsoft has stopped updating and distributing Silverlight, and authors are encouraged to use HTML for accessible web content.

This technique relates to:

Description

The objective of this technique is to illustrate how in certain cases, the Silverlight automation peer system can provide an accessibility framework Name based on any simple text strings that are also presented in the visible user interface as control content.

The applicability of this technique to SC 1.3.1 is that once promoted, the Name becomes the primary information item that describes the user interface element to accessibiity frameworks and assistive technologies, and the information is thus immune to any further applications of the Silverlight style system that might change the appearance of the visual text equivalent (styled with color, uses italic font for rendering basis, etc.)

The applicability of this technique to SC 4.1.2 is that the default peer promotion behavior provides the Name component of Name, Role, Value. This is related to the description of the term label in SC4.1.2.

A default behavior for generating Name for accessibility frameworks is possible for certain peers of content controls. The content controls that might support a default automation peer behavior include:

In these cases the string that sets either Content (for ContentControl and ButtonBase) or Text (for TextBlock) is promoted as the AutomationProperties.Name for the control in UI Automation, without any further attribution. The properties in the UI Automation tree are reported to accessibility frameworks (UI Automation, and MSAA through the bridge). The accessibility frameworks reports this information to assistive technology clients.

Relying on default automation peer behavior is the preferred Silverlight technique for supplying the accessibility framework "Name" information, so long as the default peer promotion actually does produce a usable name. Using default behavior is preferred because re-using the strings that are already used in the general visual presentation is less likely to result in accessibility-specific strings being forgotten by the application author, or get decoupled from visible UI in a revision process.

For cases where there is control compositing in a control rather than simple text, the automation peer typically cannot provide a default simple string, and it may be the application author's responsibility to set AutomationProperties.Name explicitly as an attribute in XAML, or as a property in runtime code. For details, see .

Test-based methodology

In order to use this technique effectively, application authors are expected to be following a test-based methodology towards verifying what information their application is reporting to any pertinent accessibility framework. Useful tools for this purpose include SilverlightSpy and UIAVerify. Application authors might examine their running Silverlight application on a test machine where the accessibility framework test viewers are also active. Initially, the application author might view the application at a point in the application development cycle that is prior to any effort devoted to specifically adding accessibility-related information to the application. Silverlight applications might be in this state because the initial user interface design was done in a visually oriented design tool such as Microsoft Expression Blend. Using the test-based methodology, application authors might note that certain accessibility framework properties are already populated, as a result of the mechanisms that are described in this technique. However, it is rare that ALL of the necessary accessibility information for an application can be obtained entirely from the built-in default behaviors of the automation peers. At this point, the application author may have to apply additional Silverlight techniques that provide accessibility framework information, for example .

Examples

Example 1: Button is composed with direct text content only

The following example shows XAML UI only. Logic is not shown, but would typically be added by referencing a Click handler from the XAML. 

 <Button Height="20" Width="200">Fire photon torpedoes!</Button>

The following illustration shows the UIAVerify tree view of this simple interface. Note that the internal string "Fire photon torpedoes!" is being peer-forwarded. This is verified by the Properties view on the right side: the Name property value is "Fire Photon Torpedoes", even though no programmatic Name property or AutomationProperties.Name has been applied to that button that would otherwise have supplied an acccessibility framework "Name".

Figure 1UIAVerify tree view

This example is shown in operation in the working example of Simple Peer Forwarding.

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Procedure

  1. Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. To use UI AUtomation, use Windows as the platform.
  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 any element where default automation peer promotion is expected is supplying a default Name in the automation tree.

Expected Results

#3 is true.