Creating Accessibility-aware Silverlight 2 Content (Cont.)
So far, I've addressed application-level accessibility, but what’s good for the application developer is good for the control developer. There are a few more concepts that you need to understand first though.
Derive from Existing Controls
The Silverlight team has spent a lot of time making their controls accessible; you should try to derive from the closest Silverlight control. In addition, you need to extend the control’s AutomationPeer, which encapsulates accessibility functionality. If you can't find an AutomationPeer that matches your needs, then you should at least derive from FrameworkElementAutomationPeer.
Implement AutomationPeer and Associated Provider Interface
The AutomationPeer class exposes UI Automation by rolling up most of the non-pattern related UI Automation properties exposed by the AutomationElementIdentifiers class.
… when you design, do it with accessibility in mind.
Silverlight primarily chooses to focus on AutomationPeer concepts where it can. The best way to describe this is to say that the AutomationPeer class provides the necessary default UI Automation property values, and you identify a control’s accessibility support via functions rather than a role.
UI Automation identifies control functionality by a set of interfaces called control patterns. For example, to identify that you can "invoke" a control, you implement the IInvokeProvider interface in your control's AutomationPeer. To add a control pattern, you create a new AutomationPeer class and override its GetPattern method to return the interface corresponding to the pattern requested. Now that you have a custom AutomationPeer class, you need to make your custom control return an instance of it. Override the OnCreateAutomationPeer method on your control and return a new instance of your custom AutomationPeer. Listing 2 is an example of adding the IToggleProvider to a custom AutomationPeer created for a light switch control. The important parts of the custom control are in Listing 1.
To simplify technology and focus on the purpose of Silverlight, Silverlight supports only the APIs for creating provider-side UI Automation information. Silverlight does not provide the client-side UI Automation APIs.
Change is Good, But Notify Others
Because accessibility properties change often, screen readers rely on change notification to be efficient. Change notification covers such things as knowing when focus changes, knowing when a control becomes disabled, and knowing when control pattern properties change.
Silverlight provides two methods to raise a change notification: You use the AutomationPeer.RaisePropertyChangedEvent method to signal property changes, and use the AutomationPeer.RaiseAutomationEvent method to signal other types of automation changes.
Luckily, Silverlight already tells screen readers about most changes for you. Silverlight provides notifications to UI Automation clients for the AutomationPeer IsEnabled, IsOffscreen, Name, and ItemStatus values. In addition, Silverlight provides structure change notifications that tell you when items are added and removed from the visual tree. By using or deriving from a Silverlight control, you also take advantage of control-specific notifications, such as when a CheckBox is checked.
If you create your own control with its own AutomationPeer functionality, then you are responsible for identifying and notifying others about changes. See Listing 1 and Listing 2 for an example of raising property changes.
Provide Focus Indication
Visually, your control can do most anything. When people talk about accessibility support, one important visual is focus. In Silverlight 2, the control template and styling model is very rich, but what doesn't exist is a common definition for visually identifying focus.
If your control derives from a common Silverlight control, you should use the FocusVisualElement identification defined for the control and just restyle it as necessary. Using Silverlight's Visual State Manager (VSM), you can provide a custom control template that defines a new focus element.
If your control is totally unique, you should create your custom focus visual and add code in the GotFocus and LostFocus event handlers to show and hide the focus indicator. You should also create a control template and provide a named focus element, similar to what Silverlight does.
Lastly, instead of putting the onus on the application developers using your custom control, you should add the logic necessary to customize the controls visual style based upon the high contrast option mentioned earlier in this article.
For Silverlight 2, the operating system and, to some extent, the browser dictate the level of accessibility that Silverlight can provide.
Silverlight is a Web browser plug-in based upon either Mozilla plug-in or Microsoft ActiveX technology, depending upon the browser. The Web browser is responsible for providing operating system interaction and notifications with the plug-ins contained on a Web page. In some cases, a plug-in can work directly with the operating system and bypass the browser.
Silverlight can provide accessibility information when used inside of browsers running on operating systems that support the UI Automation specification. Currently, Microsoft Windows XP and later support UI Automation; Novell has made a commitment to supporting the UI Automation interfaces on Linux. Currently, Apple’s OS X operating system does not support UI Automation, and the Mozilla plug-in technology does not support interaction with the OS X accessibility framework.
Conclusion: Silverlight’s Accessible Future
With Silverlight 2, you can control high contrast styles, keyboard navigation, and screen reader support. You can even take advantage of UI Automation wherever it’s implemented. Silverlight’s new features can help you build Web applications and controls that support accessibility, so all users can gain enjoyment and value from your work. And remember, when you design, do it with accessibility in mind.