The objective of this technique is to use the Silverlight "control skinning" scenario and feature set to change the visible focus indication of a control. In particular, the intent is to increase the visibility of focus indication versus the appearance of a default-styled control. This technique is useful both for the control sets that are included in the Silverlight run time or SDK assemblies, as well as for Toolkit or any third party distributed control.

The default Silverlight core controls all indicate some type of visible focus indication, through their default templates. However, Silverlight application authors can still use the skinning techniques to augment or replace the visible focus indications for controls as used in their applications. For more information on how Silverlight controls will generally supply a default visual focus indicator, see Focus Overview on MSDN.

Silverlight control skinning is enabled through a deliberate separation of UI and logic in the Silverlight control model. Appearance of a control is largely written in XAML. The logic is largely written in code (for example C#) and is left unaffected when a Silverlight application author provides a new control template "skin". The hooks that connect the appearance and the logic are a Style property of the control (which the author changes the value of, to refer to their new XAML resource) and a contract of expected named entities in the XAML. The control logic invokes the names of the entities/parts whenever control state changes, and the expectation is that the named part provides the necessary appearance as defined in XAML. Design tools such as Visual Studio or Expression Blend generate copies of the default templates and parts, such that Silverlight authors can modify the parts that they want to change the appearance of, and still preserve the remainder of default appearance and behavior of the control.

For the visible focus indicator technique, the author typically modifies a single visual element that renders in layout as an overlay on top of the control when it is focused, and switches the overlay to nonvisible when the control is not focused. This element is a named element that is typically referred to from within the XAML named state Focused, which in turn is hooked up to changes in the visual state.

Note that this technique assumes that the original control author provided the necessary logic event hookup, and exposed a named state associated with keyboard focus to work with. If this is not the case, or if the scenario is that a Silverlight author is defining their own control, a different technique is needed. See .

The objective of this technique is to adjust the volume for media that is played in Silverlight applications, as implemented through incorporating the Silverlight MediaElement object. By default, a MediaElement will start playing its media as soon as the UI loads completely AND the media source file is downloaded. For details, see .

At any given time, a Silverlight MediaElement is associated with exactly one media source as specified by the Source property URI value. That source might be audio-only, or audio-video. The Volume property of MediaElement affects the audio playback volume of that particular source when it is playing. The Silverlight plug-in does not have a user option that adjusts the volume of ALL Silverlight applications as run within it, or a standardized user interface that is always present for all uses of MediaElement. Therefore it is the responsibility of Silverlight application authors to provide an adequate set of user interface controls, including volume adjustment, whenever the Silverlight application plays media that has an audio component.

Providing a volume control and a Mute control as part of a set of user interface controls that go with a MediaElement

In addition to the Play Pause Stop controls, application authors can also provide a dedicated control that changes the Volume property of the MediaElement. The typical control for setting a discrete volume is Slider, because Slider is designed for input of discrete values from a range. Adjusting Volume with a data bound Slider changes the volume of any actively playing media, independent of the system volume or of any other audio source controlled by Silverlight. For Volume as set with the Slider, the Binding in XAML declares the interaction between the control and the MediaElement, without requiring an event handler. However, not all users will be able to interact quickly with a Slider, particularly if they are not using a mouse. To help these users, application authors should also include a "Mute" control. Rather than setting Volume to 0, application authors should instead set IsMuted to true. Note that Volume and IsMuted values are not directly related; if IsMuted is set to true, that does not set Volume to 0, nor does setting Volume to zero cause IsMuted to be set true.

Volume ]]>

The following is the C# logic.

This example is shown in operation in the working example of Media Element Controls.

Volume

Audio and Video Overview

Silverlight Media Framework - a framework and a media player control implementation that incorporates many of the Silverlight techniques related to MediaElement

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. It is expected that the application incorporates a MediaElement.

Check that a control is available for controlling volume and that the Volume control controls the volume of the playing media, independently from system volume.

Check that control is available for muting, and that the Mute control mutes the volume of the playing media, independently from system volume.

#2 OR #3 is true.

Declaring Discrete Silverlight Objects to Specify Language Parts in the HTML DOM

The objective of this technique is use the HTML Lang attribute on the object tag to describe each Silverlight plug-in instance on the HTML hosting page as a "part" that has a different language. Assistive technologies that use HTML Lang as a determinant of language of parts can thus treat all Silverlight content as using that HTML Lang-declared language.

Most assistive technologies that are capable of determining Language for Web content will use the HTML Lang tag value as the determinant of the language of the page. Assistive technologies would also use HTML Lang tag values for the language of parts. HTML Lang is not specifically reported in accessibility frameworks. Assistive technologies would typically access the HTML DOM to get this information. This technique specifically addresses this known situation regarding how ATs obtain Language information from HTML rather than from accessibility frameworks that otherwise report other aspects of HTML content.

In order to support different language parts that each contain Silverlight content, authors declare one Silverlight object tag per continuous language part region in the HTML. For example, the following HTML is a simplication of HTML markup for a page that contains two Silverlight content areas, the first declaring Lang as English (en), the second declaring Lang as German (de):

]]>

To support communication between different Silverlight plug-in instances that are hosted on the same HTML page, application authors can use various techniques, including the following

System.Windows.Messaging APIs: this is the simplest technique, and this is shown in Example 1

Using a shared business object, and exchanging information by having each Silverlight instance reference two-way data binding to that business object's properties.

Exchanging information through the HTML DOM and declaring properties of one or both instances as Scriptable by the DOM.

Silverlight runtime language determination

Regardless of how HTML Lang is declared on the defining object tags, many aspects of how Silverlight works with language and culture information at run time are not determined by HTML Lang, and are instead determined by the operating system and which culture that operating system is running. For more information, see Understanding Language/Culture Properties as Used by Silverlight Applications and Assistive Technologies.

Two Silverlight object tags, each with different HTML Lang, to support a simple language-translator application as a Web page

The Visual Studio solution for this example has a total of 4 project components:

The Web project that declares the HTML or ASP page that shows the framework of how the two Silverlight object tags exist on a page. This is where the HTML Lang is actually set.

A project for the English user control, a simple TextBox.

A project for a German user control, also a simple TextBox.

A library with a static translation function

In this example, the English user control implements a LocalMessageSender, which sends asynchronous messages to the German user control. The German user control has a LocalMessageReceiver, which is set to listen as soon as the control is instantiated. When a message is received, the German control calls a function of the translation library, and displays translated text.

The following is the HTML page (some infrastructure and parameters omitted for clarity):

]]>

The following is the XAML for the English user control:

]]>

The following is the code-behind for the English user control:

The following is the code-behind for the German user control (the XAML is minimal; the main relevant point is that it contains a TextBox target named GermanTranslationBox). The code invokes the translation function found in a separate library. The translation function is not shown, it simply takes an English string and returns a German translation.

(lmr_MessageReceived); try { lmr.Listen(); } catch (ListenFailedException) {} } void lmr_MessageReceived(object sender, MessageReceivedEventArgs e) { if (e.Message!="") { String translated; translated = Translator.TranslateThat(e.Message); GermanTranslationBox.Text = translated; GermanTranslationBox.Focus(); } } } ]]>

This example is shown in operation in the working example of SilverFish.

Localizing Silverlight-based Applications

How to: Implement Communication Between Local Silverlight-Based Applications

Using a browser that supports Silverlight, open an HTML page that references multiple Silverlight object tags, each with different HTML Lang values.

Verify that language settings through HTML Lang on object tags are respected by assistive technologies that can use HTML Lang values for language of parts determination.

#2 gives expected results.

Defining a Focusable Image Class for Silverlight

The objective of this technique is to wrap the Silverlight Image class inside a UI container class that is focusable. If the image is focusable, users who use the TAB sequence to navigate content while the assistive technology is active, and/or assistive technologies that construct navigation structures that are based on the TAB sequence, can both detect the image in navigation. The assistive technology can then associate alternative text for that image within the navigation structure, and report the information to the user.

Many existing assistive technologies do not construct initial navigation views that are derived from UI Automation information if it is coming from a non-focusable element in a Silverlight user interface. This is particularly true if the assistive technology is in a navigation mode that is specifically intended to help users enter information into a form or similar interactive interface element; an example of this situation is the Forms Mode of the JAWS screen reader.

Image is an example of a Silverlight element that is not focusable. This technique and the example therein are intended to circumvent the possible omission of a nonfocusable Silverlight Image element from certain navigation views in existing assistive technology implementations. The Silverlight Image is wrapped with a display/viewer control class that is focusable. This image-wrapping control is initially presented in assistive technology representations of a Silverlight user interface that use only focusable elements when constructing the assistive technology's representation of the application.

The image wrapper class uses the AutomationProperties.Name property to provide a short text alternative for the contained Image, so that the alternative text can be read or otherwise presented by assistive technologies. The Silverlight API AutomationProperties.Name directly sets Name in the UI Automation tree. The properties in the UI Automation tree are reported to assistive technologies, when the assistive technology implements behavior that acts as a UI Automation client. Name is one of the accessibility framework properties that most assistive technologies present in some way, for purposes of both name and value information, and setting Name is the common technique for exposing text alternatives for any other Control class (for example, for a button with an image, as shown in the technique ).

This technique is intended for cases where application authors deliberately do not want a visible image caption for the image to be part of the user interface, and the image is a part of a larger interactive user interface control or page. Otherwise, if there is a visible caption, authors can use .

The two examples are intended to be used together, if an application is both defining and consuming the focusable image control.

Defining the FocusableImage XAML template and C# code behavior

Silverlight supports a control development model whereby the visual appearance of a control is largely defined in XAML, and the behavior of a control (such as its event handling and hookups to services) are implemented in a managed code language such as C#. The following is the XAML template, which includes a visual state that shows visually when the control is focused in UI.

]]>

The following is the C# class definition and logic. The logic includes invoking a default automation peer on creation, and loading the template as defined in the previous XAML example through the Silverlight "generic.xaml" resource convention for custom controls.

This example is shown in operation in the working example of Focusable Image.

Using the FocusableImage class in UI and applying AutomationProperties.Name

Now that the image is wrapped by a focusable control, you can instantiate an instance of the wrapper UI inside a Silverlight layout container, specify AutomationProperties.Name at the level of the wrapper control’s tag, and have that text serve as the alternative text for the referenced source image file.

]]>

Automation Properties for Accessibility Support in UI

AutomationProperties.Name Attached Property

Tools: SilverlightSpy or UIAVerify

Automation Tree

Open the test HTML page in a Silverlight-supported useragent host; to use UI Automation, use Microsoft Windows as platform.

Use the tab sequence inside the Silverlight content area to focus the control.

Using an accessibility framework verification tool, check that the string content is promoted as the default Name applied to the control.

Accessibility framework verification tools typically show the entirety of an automation tree for a given application, and in fact will show the tree for all applications running on the Windows client machine. Focusing the control as in #2 is thus not strictly speaking necessary. However, manually focusing using the application interface is often a faster way to step into the automation tree as opposed to having to open an extensive series of nested nodes starting from the browser host application root. Whether this functionality exists depends on which accessibility framework verification tool is being used for testing.

#3 is true.

Screen Reader

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. To use UI Automation, use Microsoft Windows as platform.

Engage the screen reader. Move focus to the control (for example, use the tab sequence).

Check that the Name applied to the image is read by the screen reader.

#3 is true.

Defining a UI Automation Peer for a Custom Silverlight Control

The objective of this technique is to create an AutomationPeer class for a custom Silverlight control. The AutomationPeer exposes accessibility properties of the control in a way that abstracts the Silverlight technology specifics of the control model and maps information to UI Automation concepts, so that these properties can be consumed by the UI Automation accessibility framework.

The AutomationPeer concept is part of the overall architecture design of the UI Automation system. The peer represents a deliberate abstraction of the control, such that a client can obtain pattern-based information about the specific purpose and capability of a control without knowing its implementation-specific object model or having to resort to using a framework-specific object model API. Also, the peers run in a different process than the controls they represent, which has performance and security advantages. For more information on UI Automation architecture, see UI Automation Overview on MSDN.

Creating a custom Silverlight control is one way that Silverlight application authors can create user interface components either for their own application, or as a packaged redistributable that provides the control UI for third parties. Creating an automation peer for a custom control reports control-specific information to the UI Automation accessibility framework, and enables a custom control to participate in all of the same techniques involving UI Automation that can be used for a control that is distributed in the core Silverlight run time. Assistive technologies can use the UI Automation accessibility framework to discover the name and role of the user interface component, and can get and set values by accessing UI Automation patterns. UI Automation thus supports extensibility, while maintaining a discovery system for names, roles and values of UI components.

Control authors associate a peer with a class by implementing a method override for the class implementation. Control authors declare name and role through properties that are general to any UI Automation peer. Control authors expose the means to get and set values by choosing to support one or more patterns that are usually associated with a role. For example, a control in the role of "Button" would typically support an "Invoke" pattern. A consumer of UI Automation could check whether the pattern was supported and then call the pattern-based method Invoke, which would activate the button without any device input events being produced or required.

By convention, controls and their automation peers share a naming pattern. For example, if a control is named Spinner, its automation peer is named SpinnerPeer. However, the actual wiring for the class-peer association is made in the control code by overriding OnCreateAutomationPeer. Thus it is necessary to have access to the control code in order to associate a new peer class implementation with that control.

In addition to properties, automation peers can also expose methods as part of the implemented UI Automation control pattern. For example, a peer implementing the Value pattern can provide an implementation of the SetValue method. The SetValue method can be called by a UI Automation client in order to programmatically set the value of the owner control. The functionality exposed by the implementation of a control pattern can be accessed either by automation-based testing, or by assistive technologies.

SimpleNumericUpDown control and its peer

The example implements a very simple Silverlight custom control named SimpleNumericUpDown. The control is a templateable control, meaning that the UI is defined in a XAML file that serves as the default UI, but any consumer of the control can change the visual appearance by applying a new template. Nevertheless, the basic accessibility characteristics of the control can be shaped by the control author, and can apply even for cases where the visible UI is noticably different. This separation between design-implementation and code-behavior is one reason for the peer-owner design in UI Automation. The majority of the example shows the C# code, including the following :

Associating the peer with the class.

Defining the peer, and basic information such as the class name.

Reporting which patterns the peer supports. In this case the peer supports a Value pattern.

Control definition class:

Automation peer definition:

This example is shown in operation in the working example of Simple Numeric UpDown control.

UI Automation of a Silverlight Custom Control

FrameworkElementAutomationPeer

Accessibility

Tools: SilverlightSpy or UIAVerify

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag. To see UI Automation, use Microsoft Windows as platform.

Use a verification tool that is capable of showing the full automation tree, and an object’s UI Automation properties and patterns as part of the tree. (For example, use UIAVerify or Silverlight Spy; see Resources links.) Select the item in the automation tree that is accessing the relevant custom automation peer implementation.

Examine the set of properties exposed in the tree. Check that name is reported by Name, that the class name is reported as ClassName, and that there is a role as reported by the value of ControlType.

If the control is expected to report a value, check that the value is reported in the tree somehow. (Exactly which property reports the value varies depending on the control function and pattern; for more information, see Windows Automation API).

Check whether a control pattern is reported in the tree. If a control pattern is reported, test the methods of that pattern using facilities in the verification tool. Verify that invoking the methods has changed the corresponding read only property values in the tree.

#3, #4, and #5 (if applicable) are true.

Designing a Focused Visual State for Custom Silverlight Controls

The objective of this technique is to build custom visual states for custom controls that include visible focus indicators in the templates and parts.

The default Silverlight core controls all indicate some type of visible focus indication, through their default templates. For more information on how Silverlight controls will generally supply a default visual focus indicator, see Focus Overview on MSDN.

Silverlight control skinning is enabled through a deliberate separation of visible user interface design and control logic in the Silverlight control model. Control authors expect that application authors might reskin their control. But control authors should provide an initial default set of states, templates, etc. so that application authors have a good baseline of functionality to compare with their customization. Defining visible focus states for all control parts is an example of such baseline functionality. In order to make the visual focus state customizable, the visual state should be associated with a name. Ideally that name should have a human-readable meaning that hints at its purpose, but the real reason for the name is that it connects the XAML-defined template (which control consumers can change) with the control logic defined by the control author (which control consumers cannot change). Also, the visual names and groups in the XAML should be attributed on the control class, to assist design tools. The best resource for general information about Silverlight control customization is Silverlight documentation on MSDN.

Component Parts

Some controls are created by assembling various component parts that are already defined as controls either by the Silverlight run time libraries or by third parties. That scenario is not really what this technique is about, because in that case the focus behavior is already defined by the component's template, and the control author can re-use that behavior as-is or reskin it but still through the same named state definition. This technique specifically addresses how to define a control where the interactive surface has mouse and keyboard handling defined at a lower level for the control as a whole. The actual focus region is defined by the control author in that case, and the focus indicator is also defined to match the behavior visually and functionally.

Design for Focus Indicators

The general design principles for visual focus indicators are that the indicators should apply a visual change to the focus region's exterior margin. A common pattern is to deliberately define the visuals for the control with a pre-existing blank margin for its layout slot; that way when the focus indicator is applied, the focus indicator can fill that margin.

The actual graphic for the visual focus indicator is typically a border or shaped frame of a solid color brush with at least 1 pixel line thickness. The color used for the border stands out visually from the underlying control background or other elements of the control. The contrast between brush for visual focus and the remainder of control should be a contrast difference that is visible to users who do not distinguish the hue of colors, but can distinguish the lightness/value. In many cases the border is rectangular, to go along with the control's layout slot. However, if the control's basic shape is a non-rectangular shape, sometimes the focus indicator is designed to make a border around that shape. An example of a default Silverlight control that is round and applies an exterior round border as a focus indicator is a RadioButton.

Most focus indicator designs change only the border and do not change the main area of the control. One reason for this is that changes to the main control are typically reserved for other interactive states that also have a visual indicator. Specifically, controls need a visual state that indicates that the mouse is over the control (this is termed either MouseOver or Hover state). Controls that support activation also have a visual state that provides feedback for activation. For example, the default Silverlight RepeatButton changes its Background gradient on the button field to be darker blue value when the mouse is over the button, and changes to an even darker value blue when the button is activated (either by clicking the mouse or by pressing SPACE or ENTER with keyboard focus on the RepeatButton). To see this behavior in a live sample, see RepeatButton sample on MSDN.

Logic for Focus Indicators

Typical logic is that the border to indicate focus is present in the default template design, but with an initial value of Visibility=Collapsed. Then, a visual state for focus is defined with a name that properly indicates its purpose as text (example: "Focused"). In addition, a state is needed that undoes whatever changes were applied for focus, once focus moves to another element (for example, "Unfocused"). For example, if the "Focused" state sets the value Visibility=Visible on some element, the "Unfocused" state sets that value to Collapsed again. Silverlight's visual state system also provides a way to group related states with a factoring name (for example, "FocusStates"). For more information on state names and state groups in Silverlight visual states, as well as learning how these states define a control contract that any control consumers should follow if they reskin that control, see Customizing the Appearance of an Existing Control by Using a ControlTemplate on MSDN.

The visual state system is designed to support visual transitions to states, and for that reason the visual state system is closely coupled with the Silverlight animation system. By animating the transition, the visual appearance changes over a time interval. Typically, if transitions are used, the time interval is short, one second or less. In the case of focus indicators, it is typical to not use transitions and to instead make a discrete change; otherwise, the state change might be interpreted by users as a lag in interface response from their system.

The states themselves are designed in XAML, but are loaded and unloaded through logic that the control author defines as part of their control code. The control author does this by handling the appropriate events that occur while the event scope applies to their control. For example, to apply the "Focused" state, the control author handles the GotFocus event. Rather than handle the event directly, the more common pattern is to override a virtual method that acts as a prewired event handler, OnGotFocus. The centralized logic for visual state changes is the method GoToState, with one of the parameters to pass representing the XAML name of the correct state to load from the XAML templates. Examples for all of the APIs discussed here are available in the MSDN topic Creating a New Control by Creating a ControlTemplate.

Focus in Silverlight

Focus in Silverlight is equivalent to the larger user interface and application concept of keyboard focus. The element that has focus is the element within the Silverlight object tree and programming model that has first chance to process the Silverlight key events. As a more tangible example that is user-centric, if a TextBox has keyboard focus, then when the user presses keys on the keyboard, the characters associated with the user's pressed keys (or possibly input that is enabled by an assistive technology that can substitute for key strokes) will appear in the TextBox. A user interface element in Silverlight can obtain keyboard focus in one of three ways:

The user uses the Silverlight tab sequence to traverse into the Silverlight content and to focus a specific control.

The Silverlight application's logic calls the Focus() method programmatically to force focus to a control.

The user performs some other action, for example uses the mouse to click on a control. That control's specific logic handles the Silverlight input event and uses that event as stimulus to call Focus() on that control. The difference between this case and the above case is that the behavior is typically built-in to that control's runtime behavior, and does not require each application author to call Focus() in application code.

Visible focus indicator as a style and state

The following is the XAML that defines the basic (normal) control template. This control is simple: it has a yellow circle graphic, which overlays a red circle edge when the control is focused. The circle edge is defined by the "FocusVisual" element in the composition, and is initially Visibility=Collapsed (the expected visual state prior to being focused).

]]>

The following is the specific visual state portion. Note how the visual state includes an ObjectAnimation with discrete keyframes for hard transition between Visible and Collapsed, targeting the element "FocusVisual" in the composition shown in the previous XAML.

Visible ]]>

The following is control logic in the control class that responds to the focus-related events and switches visual states in response. In this particular example, "Unfocused" is a state without a definition. Switching to the definitionless state has the effect of reverting to the default state, which in the case of this design is intentional. Alternatively, authors could make specific template changes that revert any animation that applied to the focused state.

This example is shown in operation in the working example of Visual Focus Indicator.

Customizing the Appearance of an Existing Control by Using a ControlTemplate

Focus Overview

Using a browser that supports Silverlight, open an HTML page that references a Silverlight application through an object tag.

Using a keyboard, tab to the element where focus characteristics are being examined.

Check that the background, border, or other noticable visual indicator of the element changes color.

Check that the changes in color for the background, border, or other noticable visual indicator are removed when the element loses focus.

#3 and #4 are true.

Displaying HelpText in Silverlight User Interfaces

The objective of this technique is to provide a long text alternative that replaces content when a short text alternative is not sufficient for a given user, and the user specifically requests that the application should provide more context or more information through the application user interface. The technique could also apply for providing a long text alternative for a nontext object, for example for an image that contains a level of detail that is difficult to capture in a standard visible-in-UI image caption.

Silverlight supports a UI Automation property named HelpText, to connote its possible usage to provide imperative instructions for interactive elements. HelpText is not always forwarded to users by existing assistive technologies, which is an issue discussed in the technique . Rather than relying on a particular assistive technology's support for enabling users to access the UIA HelpText, application authors can introduce user interface elements into their design that databind directly to the HelpText property, but where the interface element is not necessarily displayed by default. An interface update might be designed to occur if the application user specifically activates a "Get Help" action that is presented in the initial user interface.

This technique emphasises a "HelpText" model as a factoring practice. Silverlight application authors can use the HelpText as a data source that centralizes such information, because it already exists and has that intended purpose in accessibility frameworks. For example, the HelpText could be shown in a tooltip, a popup, a separate user interface element that is deliberately rendered in close proximity, etc. For accessibility support, a recommended display option for HelpText is to add or dynamically alter a Silverlight text element in the primary user interface. Silverlight supports an adaptive layout metaphor. Adding text to the runtime elements in the application generally causes an interface redraw, which in turn informs assistive technologies (through UIA properties and events) that content might have changed.

To set the UIA HelpText in Silverlight, you set the attached property AutomationProperties.HelpText. AutomationProperties.HelpText can be set in code, but is typically set in XAML that defines a Silverlight UI.

HelpText and Tooltip

The same information that is used for AutomationProperties.HelpText long text alternatives could also be useful to sighted users. In this case, the same text could be displayed in a Silverlight ToolTip control. The reason that application authors should use both AutomationProperties.HelpText AND Tooltip in conjunction is because the Tooltip information is not introduced into the runtime accessibility framework information set by UI Automation, because that information set does not anticipate the mouse action triggers that cause tooltips to display. In Silverlight programming, a useful technique for sharing the same resource is to combine the Silverlight data binding feature with the .NET Framework embedded resource feature. For more information on combining Silverlight data binding and resources for common string sources, see How to Make XAML Content Localizable.

Displaying a long text alternative for an Image with XAML

Application authors can specify the AutomationProperties.HelpText attribute on the Image element. The value provided for the attribute should be a meaningful long text alternative for the image content. The value of AutomationProperties.HelpText should augment rather than duplicate any AutomationProperties.Name or an associated Label or LabeledBy caption. One or both of these is also typically specified to provide the basic (short-text) accessibility support for an image.

Diagram of standard office layout Provide text-only alternative description of the previous image ]]>

The following event handler removes the Help button and replaces it in UI with a TextBox that displays the long text alternative.

Using HelpText to augment existing form labels, to provide long text instructions

This example provides instructions for two form fields. The same text is also displayed for mouse users as a Tooltip and the AutomationProperties.HelpText string is used as a common source for both display options. In this example, the form submission does not perform client-side validation (although server-side validation following a data round trip might still exist, or validation could be added similar to the technique shown in ).

The following is the XAML UI:

Get Help ]]>

The following is the resource definition in app.xaml:

]]>

The generated resource code that defines the "Resource1" class is not shown here because it is mostly infrastructure that is produced by a generation task in Visual Studio. For more information about embedded resources in Silverlight, see Resources Overview on MSDN. The resources here contain just two strings:

NameTextBoxToolTipString: Must be 10 characters or less. Required.

AgeTextBoxToolTipString Must be a value between 0 and 120. Required.

The following is the event handler code, which changes the interface.

Note the call to Focus() - this puts the screen reader focus on the first form element so that the added text can be read. The very same text source as used for the Tooltip is added programmatically to the existing Label controls.

After the Get Help button is clicked, the visual appearance of the application is modified:

Before activating Get Help

Image:BeforeTooltipForm.png

After activating Get Help

Image:AfterTooltipForm.png

This example is shown in operation in the working example of HelpText and Tooltip.

The objective of this technique is to handle key events in a Silverlight application and enable application-specific keyboard functionality in a Silverlight application. The keyboard functionality might relate to a particular element of the Silverlight application user interface, or might be a handler for global key events within the application, such as an application-wide access key.

In Silverlight, application authors handle user input by attaching event handlers for input events. The input events are implemented on a class that is a base element in the Silverlight class hierarchy, such that all Silverlight UI elements can be the source of an input event if the user interacts with them. Typically, the event handler names are specified in XAML, although it is also possible to wire events in code. The implementation of the handlers for the Silverlight managed code programming model is always done in C# or Visual Basic code.

The most commonly used input events are the following:

Other forms of input that Silverlight supports include touch devices (with mouse promotion for cases where the application runs on devices that do not have touch input modes) and a related inking mode. For any UI interaction that uses mouse input or these other input modes, Silverlight application authors can write a parallel key event handler to provide users the keyboard equivalent.

Also, the Silverlight event system and control model combine to enable behavior whereby a mouse event and a keyboard event can be treated as the same event and can be handled by a common event handler. Using this technique, Silverlight authors can facilitate keyboard functionality in custom controls or as override behavior to existing Silverlight-supplied controls, and provide equivalence for mouse events or events that are specific to other input devices. Silverlight authors can also use controls that already have a keyboard equivalence as a built-in behavior.

The parallel key event handler case, and the built-in behavior case, are each shown in one of the examples.

All input events report a specific source that is communicated to handler code as an event parameter, so that the application author can identify which element in their Silverlight UI was being interacted with, and the application can perform an action that is relevant to that user input. In the case of mouse events, the event source is the element that the mouse pointer is over at the time. In the case of key events, the event source is the element that has focus. The element that has focus is visually indicated so that the user knows which element they are interacting with (see ). Assistive technologies often have parallel conventions whereby the user is made aware of which element is visually focused and is the current input scope presented by the assistive technology,

The objective of this technique is to declare Silverlight user interface elements related to user input and use the Silverlight two-way data binding techniques to provide a Submit button and opt-in forms submission logic pattern for forms. The Submit button serves as the final deliberate step of a form submission scenario. Silverlight programming techniques do not provide a "Submit button as a distinct object. Rather, application authors design their user input workflow such that it is a single user action that initiates change of context that is related to a data input scenario. The key to doing this in Silverlight is to use a data binding mode that sets UpdateSourceTrigger of all individual databound fields in that form or transaction. For any data binding where the UpdateSourceTrigger is Explicit, no real-time change is made to the data, until the UpdateSource method is called on each of these bindings. The application-specific Submit button is connected to an event handler that calls UpdateSource on all of the databound UI elements that comprise that form.

The objective of this technique is to create a control user interface for the Silverlight MediaElement object. The controls enable users to pause or stop the video to prevent the video images on the MediaElement surface from moving, and stop video-associated audio. These UI controls enable an interaction defined in code event handlers. Each handler calls one of the following MediaElement methods:

Note that by default, a MediaElement will start playing its media as soon as the UI loads completely AND the media source file is downloaded (or a certain buffer size is reached, in the case of streaming media). Use the AutoPlay property to change this default.

The objective of this technique is to implement built-in handling of key events in a custom control. If a custom control is correctly implemented, then any Silverlight applications that include the control can rely on the built-in key handling for some or all of the desired keyboard equivalence of a control's functionality.

Defining a custom control requires that the control author write a default template for the control and also the initialization logic, including the default implementations for built-in keyboard equivalence. Typically, control authors provide keyboard equivalence for any actions that can be activated by a mouse click on the control surface, and that are not already providing a keyboard equivalence through the implementation of a composite part.

All input events report a specific source that is communicated to handler code as an event parameter, so that the application author can identify which element in their Silverlight UI was being interacted with, and the application can perform an action that is relevant to that user input. In the case of mouse events, the event source is the element that the mouse pointer is over at the time. In the case of key events, the event source is the element that has focus. The element that has focus is visually indicated so that the user knows which element they are interacting with (see ). Assistive technologies often have parallel conventions whereby the user is made aware of which element is visually focused and is the current input scope presented by the assistive technology.

The objective of this technique is to introduce key handling that exists at the application root level of a Silverlight application, rather than per-element key handling. Event handling at the application level as opposed to at the element level is one way to address key equivalence. The key events provide key equivalence for particular user interface elements that a user might otherwise interact with using a mouse. This technique is related to events in the Silverlight programming model, as opposed to in the HTML DOM.

Handling key events at the root level of an application rather than only on the element that was the "source" of a key event is possible because of a Silverlight programming model feature known as event routing. For more information on event routing and how it works, see Events Overview for Silverlight.

This technique demonstrates a "menu" approach to key handling and user interaction. This technique is presented as a companion to , which can be thought of as an "accelerator key/hotkey" approach. The "menu" approach towards keyboard equivalence is perhaps just as common as the "hotkey" approach. It is often simpler to document a menu's key equivalence in a user interface than it is to document key equivalents of particular regions of an application, or to communicate to users that where the current focus is placed is relevant to how keyboard keys are interpreted by the application, even if the key action is relevant to only one of the controls in an interface. If all keys are handled at the top level, the specific focused element is no longer relevant.

In order to originate a key event that Silverlight application code can detect, some element in the Silverlight application must have keyboard focus. One way to assure keyboard focus is to focus the Silverlight plug-in as a whole, as called from within an event handler for Application.Startup. This is shown in the examples.

If an application does handle keys at top level, care should be taken to not interfere with specific text entry control behavior, such as typing into a TextBox. To avoid interactions, the design of key equivalence at the top level of an application typically relies on combinations with key modifiers. The Control/CTRL key is a key that is often used for this purpose. Application authors should also be aware of the implications of browser hosts that might handle the key event at HTML DOM level without making that event available to the Silverlight programming surface. For more information on this concept, see "Keyboard Events and Browser Hosts" section of Keyboard Support Overview for Silverlight on MSDN.

Application authors are responsible for correctly documenting the accelerator keys that are pertinent for their application. There are a variety of techniques for documenting user interface actions that are not described here. One possible suggestion is to include a generalized "Help" button that appears early in the application's reading order, which is focusable and has an AutomationProperties.Name value available as the text content or equivalent. Such a button can be activated without knowing any of the application's accelerator keys, and the activation result could be a new text element that enumerates the possible keys. For example, the application could display a Silverlight Popup with the following content:

A screen shot of a sample Popup control that documents specific accelerator keys

The objective of this technique is to use text captioning that is embedded in the stream with media displayed in a Silverlight MediaElement, and present that text captioning in a separate Silverlight control or text element.

This particular technique uses scripting files with a TimelineMarkers collection that are embedded directly within the media file. When text captioning is embedded directly in the streams, synchonization of the scripting stream versus the video content stream is done automatically by the MediaElement component. Each time the MarkerReached event fires, that is an indication that a synch point in the video that corresponds to a script marker entry has been reached. Silverlight application authors can obtain the text from the relevant timeline marker entry through their event handler implementations, and can display captions in the user interface area where the text captions are displayed. Typical Silverlight controls that can be used for displaying text captions include TextBlock (nonfocusable), TextBox, or RichTextBox. A typical interface design would place the caption-display control in close proximity to the MediaElement control that is being captioned, for example might place the captions directly underneath the MediaElement "screen".

Script-embedded captions are captions that are stored directly in the media file as metadata, rather than as a separate file. For information about techniques for captions in separate files, see .

The objective of this technique is to replace a Silverlight MediaElement with static alternative non-media content that is not time-based. The static alternative content replaces the media in the same or a nearby user interface region of the Silverlight application.

A Silverlight application user interface can be adjusted at run time by removing elements from the visual tree, and adding new elements to the visual tree. In this case, the user interface is designed to provide a control that the user activates to display the static alternative content, which is often a control that displays text, or a text element.

The objective of this technique is to use the Silverlight AutomationProperties.Name property to provide a short text alternative for controls that do not otherwise contain text. The text is intended to provide human-readable identifiers and short-descriptions or user instructions for accessibility frameworks, which can then be reported to assistive technologies.

"Control" in this technique refers to any element that is based on the Silverlight Control class, and is keyboard-focusable either by user action or calling focus to the control programmatically. The non-text control in question might be something like a button that communicates information using only an icon or image. For example, a triangle image rotated 90 degrees clockwise is commonly used in many user interfaces to indicate a "Play" button control. This "Play" icon mimics interface metaphors from many non-software consumer products, and is often presented in a user interface without any nearby visible text information that explains the purpose of the control. Another example is a "thumbnail" metaphor where a small image serves as a control that can be activated, and where the action results in the display of a larger version of the same image, or enters an editing mode that loads the same image.

For cases of controls such as buttons that invoke actions, the text alternative also identifies link purpose.

In Silverlight, a text-only identifier for any control can be set specifically as AutomationProperties.Name on the parent control. Silverlight control compositing techniques enable either per-control images that are specified by the application author, or a general-purpose image/icon for a control that is part of the control's template and displays that way by default. The Silverlight API AutomationProperties.Name directly sets Name in the UI Automation tree. The properties in the UI Automation tree are reported to assistive technologies, when the assistive technology implements behavior that acts as a UI Automation client (or as an MSAA client, which relies on the UIA-MSAA bridge).

Applying a text alternative for an icon Button with XAML

Application authors can specify the AutomationProperties.Name attribute on the Button element, and leave accessibility information for the composited Image content unspecified. It is the button and its action that is relevant to users, not the non-interactive Image component. The value provided for AutomationProperties.Name is a meaningful text alternative for the action conveyed by the button's icon/image, but where the functionality is conceptually embodied in the button and not its images or other constituent parts in compositing or visual design.

]]>

This example is shown in operation in the working example of Button Text Alternative.

Not all assistive technologies choose to read or present information from the UI Automation tree for Silverlight in cases where the corresponding UI object is not focusable in the tab sequence. This technique provides the support for introducing the information into the UI Automation tree for that element, but cannot guarantee that a given assistive technology provides the user with access to the element information from that UIA tree.

The objective of this technique is to replace a timed Silverlight animation with a non-timed user interface element that presents equivalent information. This is useful in cases where the Silverlight animation is a timed animation that may contain information that the user wants to see without a time limit, such as crawling text in a text area. The animated version of information in the user interface element can instead be swapped out for an equivalent static element.

The Silverlight animation system is generalized such that nearly any Silverlight property of type Double, Point or Color can be animated, or a property can cycle through discrete object values. Thus the possibilities for which properties in the user interface can be animated are quite broad. The general technique shown can be used to stop any animation.

Silverlight content in a user agent host that supports browser zoom

The objective of this technique is to define style switching logic for Silverlight. In particular, the intent is to use the style switcher to change the font size of text elements. This technique could be used only for specific elements, or could also be applied to the entire Silverlight content area and all text elements therein (including elements such as TextBlock that are technically not controls). Examples are provided for these two cases.

The property to style or otherwise change is the FontSize property. Primarily, this is done using the API Control.FontSize, but developers can also use similar properties on other objects that do not derive from Control (examples: TextBlock; DataGridTextColumn).

Silverlight uses a style system whereby many properties that affect UI appearance can be referred to and changed through a style resource. The style resource overrides the default code implementation and the default XAML template as provided by the Silverlight core implementation(or a third party control author). A style enables an application author to make a one-to-many change to property values in an efficient and reversible way, and also to group multiple related property changes as one unit of logic. Styles can be applied explicitly by referencing them by name, or implicitly by associating a style with a class (which then targets all instances of that class). This is analogous to how CSS can either define styles globally for tags or uniquely for classids and names.

Silverlight styles are always written in XAML. Silverlight event handlers are most often written in code (there are related techniques that can react to states with event associations, defined in pure XAML, but the specific style switching technique is most straightforward in code).

The objective of this technique is to use the AutoPlay property of MediaElement object, which prevents the MediaElement from playing its media source automatically.

By default the value of AutoPlay is true, which causes any media that is the Source of the MediaElement to play as soon as either the entire source file is loaded (for nonstreaming media) or an initial buffer is loaded (for streaming media). To prevent the possible accessility issues, developers can instead specifically set AutoPlay to false, so that the user always controls whether the media plays. This technique would thus be used in combination with providing user interface controls that go along with the MediaElement, and that enable the user to control the media. In particular, the user interface controls enable the media to play, pause or stop, with event wiring for those controls associated with the Play, Pause or Stop methods of the MediaElement object.

MSAA clients might not use LabeledBy values appropriately, unless such clients are handling MSAA AND IAccessibleEx. See IAccessibleEx Implementation Guidelines.

Most assistive technologies will use the HTML Lang tag value as the determinant of the language of the page. Assistive technologies would also use HTML Lang tag values for the language of parts. HTML Lang is not specifically reported in accessibility frameworks, so assistive technologies would typically be accessing the HTML DOM to get this information.

The objective of this technique is to use text captioning that comes from a separate text file, synchronize the captions with the media in a Silverlight MediaElement, and display the captions in Silverlight.

There are two variations of the general theme of implementing Silverlight media player controls to work with external timed text: using built-in capabilities of the Microsoft Expression Encoder tool, and using parsing code that consumes caption as a raw file format and converts that format into the Silverlight API's TimelineMarkers representation. This technique primarily addresses how to use the Expression Encoder technique, along with media player templates that are also provided by Expression Encoder or related Silverlight SDKs such as the Smooth Streaming SDK.

At a pure architecture level, Silverlight uses the TimelineMarkers API to display caption text at synchronized times. The Expression Encoder and Expression Blend tools provide a front end to drive the TimelineMarkers API for the supported formats. The intention of the architecture is so that Silverlight as a run-time has a base architecture that could potentially use any existing or future timed text format, but the tools for Silverlight (rather than built-in features of the runtime) provide the optimized workflow for producing captioned media projects.

A procedure for using the Expression Encoder and Expression Blend tools to produce a Silverlight media player application that can consume timed text in TTML format is provided as Example 1 in this technique. (Note: prior to the approval of TTML by W3C, DFXP was a format that used much of the eventual TTML vocabulary. In tools that predate TTML, this format is often identified as DFXP.)

A purely code-based parsing technique, with the goal of avoiding Expression Encoder dependencies, is necessarily more complex. This is because there are multiple issues to solve:

The objective of this technique is to use some of the basic user interface objects in Silveright to produce blocks of content that are identified as a "List" to accessibility frameworks and to Silverlight's own tab sequence navigation behavior.

Using the "List" technique results in a tab sequence behavior whereby that element is treated as a single tab stop, even if that element has consituent elements (the list items) that would otherwise be considered additional tab stops in the main tab sequence. In the default key handling, when the user presses the TAB key while focus is on a List, the focus goes to the next element after the List. To focus the items of the list, the user would press the Arrow keys rather than TAB. In the Silverlight programming model for controls, this tab sequence behavior is expressed by the TabNavigation property holding the value of Once. The Silverlight ListBox is a control that reports itself as "List" role, and that has a default TabNavigation.Once value. Thus ListBox as per this technique is a lightweight technique for producing blocks that can be bypassed. It is specifically a lightweight technique because it can be accomplished by writing simple application-level XAML and using only the Silverlight core libraries.

Silverlight also supports more full-featured techniques for producing bypass blocks that are based on common user interface features such as menus or toolbars. However, using toolbars in Silverlight is inherently not as lightweight because the Silverlight core libraries themselves do not include a ready-made toolbar. Silverlight provides a ContextMenu as part of the Silverlight Toolkit extensions, but the behavior of this particular menu does not easily address the bypass block scenario. Silverlight includes all the infrastructure and necessary base classes for defining a toolbar or a menu that could address the bypass block scenario. Many third-party control implementations of menus and toolbars exist, either as part of control packages that are sold by control vendors, or through community mechanisms such as CodePlex or third-party sites that provide free source code. For some examples, see the following:

If application authors use a built-in control such as ListBox where the accessibility framework reported role is not traditionally associated with a navigation role, it is a best practice to set AutomationProperties.Name such that the name informs the user of the purpose of the list control. Otherwise, the role alone leaves this ambiguous. For example, an author might name the list control "Navigation control".

Often the List control itself is focusable. So long as the List control has a visual focus indicator, that behavior might be acceptable. However, it might provide a better user experience to deliberately have the List itself non-focusable, and instead have focus fall to the first List item when focus reaches that region. Otherwise, the List might be perceived as an "extra" tab stop to some users. To enable that behavior, set IsTabStop to false on the List control. The List itself still provides the intended tab navigation behavior, and is still reported and identified to accessibility frameworks and assistive technologies, even when the List container is not focusable. This is shown in Example 1, by setting IsTabStop as part of a Style.

When an accessibility framework presents a List, assistive technologies are generally expected to continue to support use of the same key behavior as the default behavior, and to report to users that the item is a List when it is focused. If assistive technologies use the accessibility framework APIs for navigation, the items in the list are considered child elements. Navigating either by spatial direction (e.g. NAVDIR_RIGHT in MSAA) or sequential direction (e.g. NAVDIR_NEXT in MSAA) skips the list items and goes to the spatial/next peer.

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.

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.

]]>

This example is shown in operation in the working example of Button Nontext Text Composition.

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.

... > ]]>

The objective of this technique is to change the presentation / visual appearance of text, by setting several of the font-specific properties in the Silverlight API. Changing such properties does not change the semantic meaning of the text, nor does it alter the representation of the text that is available to assistive technologies through the Silverlight support of the UIA accessibility framework. By using font properties, it is possible to introduce a wide variety of presentation changes to fonts that do not introduce semantic elements that interfere with an assistive technology's view of text in the Silverlight application. In particular, adjusting font properties will make it possible to avoid any need for use of images of text, yet still provide a wide range of choices for text presentation.

Silverlight font properties exist on all controls, as well as on other text elements that are not true controls. For controls, the font properties apply in any case where the control enables a presentation mode that has enclosed text areas in its layout. By setting Silverlight font properties, it is possible to adjust presentation of font features without changing the structural connotation of that control, or the value of any control-specific property that contains plain-text. For example, the FontSize property can be set on a Paragraph (not a control) or on a Button (a control, and in this case the font size changes apply to any text displayed in the button content area). Font properties are also inheriting properties, meaning that if applying a font property value to a container in a relationship, those font property values can apply to child elements in the relationship. For example, if a FontSize is applied to a RichTextBox, that FontSize value is used by default by all the Paragraph items displayed in the RichTextBox.

Similar to CSS, Silverlight font properties can be grouped as a Style. That Style can be applied to all instances of a text element type (for example to all cases of Paragraph) or specifically referenced as a resource that is only used by certain instances of a text element type. Either way, the Style feature enables the separation of presentation from semantics for text elements, and enables workflows where content authors supply the semantic text and design-oriented authors adjust the related Silverlight styles. For more information on the Silverlight concept of styles, see Control Customization on MSDN.

The following Silverlight font properties are useful to style text and avoid the need for text in images. Links in this list refer to the Control class version of these properties.

So long as images of text are avoided, the text within a Silverlight text element can be reported to the UI Automation accessibility framework that Silverlight supports. That text is reported using the same basic text content as is used for semantic text display in the UI. In other words, exposing that text to assistive technologies that use UIA as a framework does not require the Silverlight application author to resort to automation-specific override properties such as AutomationProperties.HelpText; the automation peers for text elements report all necessary text content to automation as a built-in behavior of the text element controls. For more information on UI Automation and text containers, see .

JAWS version 12 misreports a read-only RichTextBox as "edit", despite it reporting its role as "document" to both UIA and MSAA. Text is still read by JAWS 12, but users might expect that they would be able to enter text in an element that JAWS 12 reports as edit, whereas in fact they cannot enter text.

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 .

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.

The objective of this technique is to use the default Silverlight tab sequence, or alternatively to apply the options that Silverlight application authors can use for altering the tab sequence. Application authors might alter the tab sequence in cases where the default tab sequence is not desirable for some reason, and those reasons might vary per application or application scenario. The tab sequence can be altered in order to create a meaningful sequence in the tab order, so that assistive technologies that rely on traversal of focusable elements can use and determine the meaningful sequence.

Silverlight uses structured definitions for defining its user interface presentations, where the declaration order is significant because it becomes the structure of the run-time visual tree. The structured definitions also define the layout and presentation structure in most cases. The structured definition concept is described in more detail in .

The Silverlight development platform attempts to create an overall system where the logical order of how elements are defined in XAML and code, and then presented in a user interface, will also match a logical tab sequence and logical reading order when presented to the user. In many cases, a Silverlight application author can write an application without necessarily worrying about the tab sequence, can test the tab sequence during a verification and testing phase of development, and will not need to set any specific properties to adjust the tab sequence. As a broad generalization, a Silverlight tab sequence will be constructed so that it traverses elements left to right, and top to bottom, and will behave similarly to how HTML would behave if the HTML analogs of Silverlight elements were constructed and presented in the same way. However, there are specific Silverlight controls that deliberately alter the tab sequence, or whose elements are made keyboard-accessible through a keyboard navigation technique other than TAB. For more information, see Focus Overview on MSDN.

The objective of this technique is to use the Silverlight Validation API. The Validation API associates the validation logic with form input elements that properly support accessible text both for the initial entry and for any error identification and suggestion that is displayed in the user interface.

Application authors can either associate Validation.Errors output with specific UI elements, include an initially hidden ValidationSummary user interface element, or both. The example shown in this technique uses both ValidationSummary and Validation.Errors. The ValidationSummary is the most appropriate technique for providing text feedback after a form submission attempt, because assistive technologies pick it up as a discrete focusable element in the interface representation. The Validation.Errors technique is perhaps a better cognitive user experience for sighted users, because it presents the specific error suggestions in closer proximity to the input items that are in error.

This technique relies on several Silverlight features: AutomationProperties, the Name property for identifying specific UI elements, the Validation and ValidationSummary API, the ElementName variation of Silverlight data binding, and the general behavior of TextBox elements.