Share via

Application Accessibility Testing

  • Article

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:

Step

If “Pass”

if “Fail”

1. Run “AccChecker” (download from here)

Go to step 2

Fix reported issues Go to step 2

2. Run “UIA Verify” (download from here)

Go to step 3

Fix reported issues Go to step 3

3. Run “Inspect” (download from here) - only for focus and caret tracking testing

Go to step 4

Fix reported issues Go to step 4

4. Verify contrast, DPI, color, magnification (see next table)

Go to step 5

Fix issues Go to step 5

5. Run target accessibility tool

DONE

Contact tool vendor. Report issue to Microsoft.

 

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

Test Criteria

Verification Tools and Steps

High-contrast

Control Panel - Ease of Access Switch to each of 6 High Contrast modes

High-DPI

Control Panel – Display Switch to 150% (1200x1000 min resolution) Switch to 200% (1600x1200 min resolution)

Redundant Color Information

Use a tool such as Fujitsu’s Color Doctor Try each of the 4 conversion filters

Magnifier tracks all keyboard navigation

Control Panel – Ease of Access – Magnifier Enable follow mouse/keyboard/insertion point Use WinKey+Plus / WinKey+Minus to change magnification

All UIs respect the accessibility system settings

Control Panel – Ease of Access

All documentation is accessible

  

All UIs have 5:1 or higher contrast ratio of text to background

Use a tool such as the Color Contrast Analyzer Install the luminosity and brightness version

All UIs can be used fully with On-Screen Keyboard

Control Panel – On-Screen-Keyboard (OSK.EXE)

UIs do not flash with rate between 2 Hz and 55 Hz

Use a tool such as PEAT (Photosensitive Epilepsy Analyzer Tool)

 

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.

Comments

  • Anonymous
    June 04, 2010
    The comment has been removed
  • Anonymous
    June 04, 2010
    The comment has been removed
  • Anonymous
    June 04, 2010
    Thanks Vince. Good to see this information is useful.