Techniques for WCAG 2.0

Skip to Content (Press Enter)

-

SL33: Using Well-Formed XAML to Define a Silverlight User Interface

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 SL33. Also see Silverlight Technology Notes.

Description

The objective of this technique is to use the characteristics of the XAML language to support basic parsing requirements that both applications and accessibility frameworks rely upon. This technique explains the role of XAML in the overall Silverlight development and application architecture, in particular for defining the elements that make up a Silverlight user interface. This technique also present some basic facts about XAML as a language; more information of this nature is also included in Silverlight Technology Notes.

XAML is a markup language for object instantiation. XAML can be incorporated into a technology such as Silverlight. A specific XAML vocabulary can be defined by a technology such as Silverlight, and the vocabulary can be extended by anyone that provides suitable backing code. For example, a Silverlight application author can define a custom class, and the application author or potentially other Silverlight application authors can use XAML to instantiate instances of the custom class.

XAML has a published language specification.

XAML does not necessarily declare the entirety of the object tree that a Silverlight client runtime loads, but XAML typically declares the majority of the objects/elements that represent the Silverlight application's user interface. The objects and values that are used for accessibility scenarios are often closely related to the standard user interface, and thus accessibility-related properties are typically declared in XAML rather than in code, even though setting the values in code is technically possible.

For more information on XAML in Silverlight, see Silverlight XAML Overview on MSDN.

XAML and XML

XAML is based on XML, and shares many of its language features. Some of the language features that are directly relevant to the stated intent of SC4.1.1 and to 4.1.1 related techniques include:

Some XAML language features that are analogous to XML but have some technology-specific differences include:

XAML parsing and HTML parsing

In the Silverlight implementation, XAML is like HTML in that it is loaded and parsed just-in-time. Silverlight XAML is not precompiled to binary or MSIL (the language-neutral CLR runtime format). Instead,Silverlight XAML is transmitted or stored as plain text, either loose or packaged as resources in a library. Thus Silverlight XAML is human readable as well as machine readable.

However, unlike HTML, Silverlight XAML is only intended to be loaded and interpreted by the Silverlight runtime, rather than multiple possible user agents that each implement an HTML engine. HTML is a language where the behavior is also specified. In contrast, XAML is a language for referencing constructs that are defined in runtime libraries, and the functional specification of the XAML language itself is minimal (intrinsics; language rules; primitive types). Layout, appearance, type-member sets, roles, etc. are all left up to specific frameworks and vocabularies that use XAML. Behavior associated with a given XAML construct is based on type definitions made in a runtime library. For Silverlight XAML, the types are from Silverlight core libraries, but often the definitions come from libraries that are available to the Silverlight runtime as part of an application's packaging for distribution.

XAML is generally speaking strict, and will raise parsing errors if XAML contains elements that are not recognized. Such parsing errors generally present the information in the XAML from resulting in any objects being created, which in turn prevents a Silverlight application from running. This is different from typical (non-xHTML) HTML, where implementations are permitted to contain nonrecognized elements or attributes and ignore them.

Examples

Example 1: XAML in design tools for Silverlight

A developer utilizes features in their Silverlight XAML authoring tool to ensure that:

More about design tools and XAML

Silverlight XAML is able to be loaded by design tools for Silverlight. In the design tool, the XAML is interpreted much like the runtime interprets it, in order to show the visual representation of the Silverlight application. In addition, the design tool might implement design surfaces in which the user interface can be changed, and typically provides a way to save any changes made in the tool back into the loaded XAML.

At design time, tools such as Microsoft Visual Studio or Microsoft Expression might provide opportunities to correct any XAML errors before the Silverlight application is compiled and packaged for deployment. This might be implemented by performing static analysis of the XAML, by forwarding the design tool's own parser errors as it renders the design surface, or by forwarding linking errors that are identified by a precompile step (for example, missing event handlers raise a XAML error from precompile). This behavior is sometimes identified as a design mode behavior in Microsoft documentation and other documentation about Visual Studio or specific tools.

Regardless of how a given XAML file behaves while being interacted with in a design mode, it is the Silverlight runtime XAML parser on each client installation that is the ultimate determinant of whether the XAML is valid or invalid.

Example 2: Silverlight application consumer

A consumer views a Silverlight application that is hosted in an HTML page. If the Silverlight application has valid XAML, the Silverlight content loads, and the fact that the XAML-based UI loaded at all is assurance that:

Resources

Resources are for information purposes only, no endorsement implied.

Tests

Pass case

Procedure

  1. Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. That application is known to consume Silverlight XAML.

  2. Verify that the application runs correctly and displays user interface.

Expected Results

#2 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

Fail case

Procedure

  1. Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. That application is known to consume Silverlight XAML, and the XAML is known to be deliberately invalid.

  2. Verify that the application did not run.

Expected Results

  1. #2 is true.

Note that it is common that an error message is displayed to users in HTML, which is implemented by handling the JavaScript OnError event emitted by the Silverlight plugin. XAML parse errors are forwarded to JavaScript errors and can be handled in this way. However, it is also possible that the application is production-ready, and deliberately does not expose any JavaScript errors, whether Silverlight managed code errors or not. If seeing the specific error is important, the test might need to be run against a preproduction or debug version of the application.

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.