User Agent and Assistive Technology Support Notes

Description

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 SL7: Designing a Focused Visual State for Custom Silverlight Controls.

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 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.

Examples

Example 1: Two Button elements, one reskinned to provide new visible
focus indicator

XAML templates can be verbose; for clarity, only the parts of the
template that were changed or useful for showing the structure are
shown. Omitted portions are shown as ellipsis (...).

Related Techniques

Tests

Procedure

Note that not all Silverlight applications necessarily will start
with the keyboard focus being somewhere within the Silverlight content
area for purpose of Step #2. It may be necessary to press TAB several
times to traverse the browser's framing user interface. Also, within
the browser's display area that displays the HTML document, there might
also be other HTML elements that are keyboard focusable, which are
representative of HTML that falls lexically before the <object> tag
that instantiates the Silverlight plug-in. So it may also be necessary
to press TAB several times until these HTML elements are traversed.

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.

Expected Results

#3 and #4 are 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.