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.
In general “Accessibility” means two things:
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:
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:
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.
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:
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
Contact tool vendor. Report issue to Microsoft.
For contrast, DPI, color and magnification verification (step 4 above), use the following tools and steps:
Verification Tools and Steps
Control Panel - Ease of Access Switch to each of 6 High Contrast modes
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 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.