- Microsoft Silverlight, versions 3 and greater
- Silverlight managed programming model and Silverlight XAML
Microsoft has stopped updating and distributing Silverlight, and authors are encouraged to use HTML for accessible web content.
This technique relates to:
- Success Criterion 1.3.1: Info and Relationships (Sufficient as a way to meet an unwritten technique)
- Success Criterion 4.1.2: Name, Role, Value (Sufficient as a way to meet G10: Creating components using a technology that supports the accessibility notification of changes)
The objective of this technique is to illustrate how in certain cases,
the Silverlight automation peer system can provide an accessibility
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,
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:
ButtonBasederived classes that do not change the GetNameCore implementation. This includes the
Buttonclass. In order for the default promotion to work, the
Contentof the button must be set as a plain string or must contain only a
TextBlock; any compositing such as wrapping in a
Borderor other container will disable the default promotion.
- Any other
ContentControlderived class where the
Contentproperty contains either
TextBlockor a text-content-only
ButtonBaseimplementation as sole content.
In these cases the string that sets either
TextBlock) is promoted
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
AutomationProperties.Name explicitly as an
attribute in XAML, or as a property in runtime code. For details, see .
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 .
Resources are for information purposes only, no endorsement implied.
- 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.
- 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 any element where default automation peer promotion is expected is supplying a default Name in the automation tree.
#3 is true.