A lot of our customers and partners have asked us to provide guidance on how to make their WPF and Silverlight applications accessible, so I decided to publish a post folks can refer to. Note most of the content below is directly applicable to any other Windows application.

Introduction

In general “Accessibility” means two things:

1. Nominal accessibility: An application or an application programming stack exposes the necessary information so that it makes its UI elements accessible;
   
2. Accessibility with an accessibility tool: An accessibility tool (e.g. a screen reader) can access the UI of a given application and expose the UI to its users.

For an application to be “accessible”, ideally it would satisfy both (1) and (2) i.e. be both nominally accessible and also accessible with popular accessibility tools. Satisfying (1) guarantees that the level of accessibility of an application does not depend significantly on the accessibility tool. Satisfying (2) guarantees that a disabled user can interact with an application, when using a particular accessibility tool. Satisfying (2) is clearly more important, and as a matter of fact the various accessibility tools go to extraordinary lengths to make applications that are not nominally accessible be accessible through the tool.

+++

Accessibility tools use several techniques to build an accurate in-memory representation of what is presented on the screen:

1. Public accessibility API
2. Public platform API
3. Kernel interfaces
4. In-process code injection

Microsoft provides two accessibility API – MSAA and UIA. MSAA is a legacy API, introduced circa 1996, which is not extensible and is no longer sufficient for modern UIs. UIA is the new much richer and fully extensible Accessibility API from Microsoft, originally introduced in WPF / Windows Vista in 2007.

It’s important to note that many existing Win32 applications are not nominally accessible. I.e. they do not expose the right accessibility information, using public accessibility API. They are only made accessible through the use (by the accessibility tools) of techniques such as (ii), (iii) and (iv) above.

+++

Accessibility API typically expose:

1. Provider API : these are the API used by an application stack to expose its UI elements;
2. Client API: these are the API used by an accessibility tool (e.g. a screen reader) to query the UI elements of an application.

MSAA and UIA both conform to that client-provider model. There is also a bridge between MSAA and UIA, which allows a client using the MSAA client API to access an application exposed through UIA.

General Accessibility Testing Workflow

Microsoft provides a number of accessibility testing tools that can help with identifying of nominal accessibility problems. Combining these with the target accessibility tool is the winning recipe for creating of fully accessible applications.

Below is a suggested accessibility testing work-flow:

For contrast, DPI, color and magnification verification (step 4 above), use the following tools and steps:

WPF Accessibility

WPF is a fully accessible stack. WPF uses UIA (in fact the original UIA team used to be part of the WPF team) to provide access to the various UI elements. All standard WPF elements (packaged controls, etc.) implement the necessary client-side UIA interfaces to expose themselves to accessibility readers.

Development and testing of nominally accessible WPF applications is fairly straightforward. For more information, refer to the “Accessibility Testing” section in the “WPF Application Quality Guide”.

While following these guidelines will result in nominally accessible applications, it is important to once again stress that all applications should also be tested with the target accessibility tool to confirm that they are truly accessible from the point of view of a disabled user.