Close your eyes, ignore your mouse, navigate with your keyboard, and rely on your ears alone. Now try to use an application you’ve built or tested. Can you?
The few informal tests described in this article can expose a plethora of usability and accessibility shortcomings, oversights, and other issues in your application. But how do you test, assess, and rectify them?
To ensure the most consistent user experience across the Microsoft® Windows® product line, Microsoft has developed a number of tools to assist developers and testers to verify the accessibility implementations in their applications.
Despite the name, the Windows Automation API encompasses both accessibility and automation frameworks.
In this article, I describe each of these tools and explain what they are designed to test and the scenarios in which each tool, alone or in combination, may be useful. I also describe how you can use these tools throughout the development cycle and how to incorporate them into automated and non-automated test frameworks.
An Overview of the Windows Automation Frameworks
The tools I discuss in this article are designed to test and report on a set of standardized accessibility issues typical of an application user interface (UI). The tests rely on programmatic access of the UI implementing the relevant API components defined in the framework known as the Windows Automation API.
Despite the name, the Windows Automation API encompasses both accessibility and automation frameworks, including Microsoft Active Accessibility®, UI Automation, the IAccessibleEx interface, as well as other related and evolving technologies. Each of these frameworks enables programmatic access to the UI at run time by exposing control properties, methods, and events such that you can use a tool to manipulate and interact with the UI manually or through automation.
By incorporating the relevant components of the Windows Automation API and following common accessible design practices, developers and testers can make applications running on Windows significantly more useful for people with vision, hearing, or motion disabilities.
In the following sections I briefly describe the frameworks that constitute the Windows Automation API.
Microsoft Active Accessibility
Microsoft Active Accessibility is a set of COM interfaces and APIs that provide the means to expose and collect information about UI elements and controls. This allows assistive technologies, test tools, and automation frameworks programmatic access to and manipulation of the UI.
UI Automation
UI Automation is similar to Microsoft Active Accessibility in that it provides a means for exposing and collecting information about UI elements and controls to support user interface accessibility and software test automation. However, UI Automation is a newer technology that provides a much richer object model than Microsoft Active Accessibility, and it is compatible with both Win32® and .NET.
This ability to find and track an accessibility bug through to resolution in a process you can automate makes these tools indispensible additions to a tester’s toolkit.
Note: UI Automation exposes each object in the UI as an AutomationElement object to client applications. An AutomationElement object exposes common properties of the UI element it represents, such as the control type and relevant control patterns that provide properties specific to the control type.
The IAccessibleEX Interface
The IAccessibleEX interface is a new interface that provides the ability for developers to add partial support for UI Automation to controls with existing IAccessible COM interface implementations. This is transparent to testers and the tools discussed in this article.
Evaluating the Accessibility of Your Application
There are two primary approaches to evaluating the accessibility of an application: a manual audit based on a set of commonly accepted heuristics for an accessible UI (also known as static testing) and a partial audit to a fully automated test platform that evaluates the implementation of an accessibility framework within your application’s code (dynamic testing). Both methods can provide results based only on a set of guidelines, either from the heuristics of the audit or those built into the design of the accessibility framework.
Accessibility Auditing
Typically, auditing your application for accessibility issues is a manual process that involves attempting to access and use the full functionality of the application exclusively through keyboard input and other assistive technologies (such as screen readers). As an auditor, you assess each issue discovered during the audit and log a bug for each issue as necessary. You then assign a priority and severity to each bug and, where possible and appropriate, provide recommendations for fixing or working around the issues that the audit uncovers. These recommendations are based on a combination of experience and accessibility guidelines from industry or advisory groups.
Since there is an inherent risk of testing the functionality of the tool rather than the application, auditing should be conducted by seasoned testers familiar with accessibility requirements and the broad range of assistive technologies.
Accessibility Testing
For the purposes of this article, accessibility testing is associated with automated, repeatable code execution based on a set of predefined test cases. Depending on the sophistication of the tool, I will supply generic recommendations for specific issues uncovered during testing.
In addition to compiling reports for basic unit tests, some of the tools discussed also offer support for regression and integration testing. This ability to find and track an accessibility bug through to resolution in a process you can automate makes these tools indispensible additions to a tester’s toolkit.
And in this Corner, We Have… The Tools
The following Microsoft tools enable developers to test accessibility implementations and functionality in applications using Microsoft Active Accessibility or UI Automation.
UI Automation Verify
UI Automation Verify (UIA Verify) is a test automation framework that facilitates automated testing for specific Microsoft UI Automation implementations. This framework provides the basis for the UI Automation Test Library command-line tool and Visual UI Automation Verify (Visual UIA Verify), a Windows-based graphical user interface (GUI) for the test framework. Most of the UIA Verify framework functionality is provided through a DLL (UIATestLibrary.dll) that enables the testing of specific UI Automation functionality and that logs the test results.
Note: The Visual UIA Verify GUI does not support event monitoring or testing and validating text-based content using the UI Automation TextPattern and TextPatternRange control pattern interfaces. The UI Automation Test Library does not share these limitations.
To use the UI Automation Test Library, a driver (or client) application obtains an AutomationElement object from a control that requires verification. The driver, in turn, supplies the AutomationElement object to the UI Automation Test Library, which executes the tests required to validate the UI Automation implementation. Figure 1 illustrates the typical workflow when using the UI Automation Verify framework to test an application.
The Visual UIA Verify framework is a Windows driver for the UI Automation Test Library. This tool is designed for manual testing. It provides an interface to UI Automation Test Library functionality and eliminates the code overhead of a command-line tool. Figure 2 illustrates the five functional areas of the Visual UIA Verify framework.
UI Spy
UI Spy, the precursor to the UIA Verify framework, is a Windows application designed for UI Automation testing of specific accessibility issues.
While the lack of built-in automation support limits the effectiveness of UI Spy, it can still be an invaluable tool for viewing an application's UI hierarchical structure, property values of individual controls, and event tracking. You can also use UI Spy to interact with controls through UI Automation control patterns. This extensive functionality provides the means for developers and testers to verify that an application UI is programmatically accessible to assistive technology devices. Figure 3 shows UI Spy querying and displaying the UI Automation properties of an element.
UI Spy is similar to Visual UIA Verify in that it does not support the testing and validation of text-based content using the TextPattern and TextPatternRange control pattern interfaces of UI Automation.
UI Accessibility Checker
UI Accessibility Checker (AccChecker) verifies the design and implementation of Microsoft Active Accessibility in a control or application UI, regardless of the underlying UI framework.
The AccChecker architecture incorporates three levels, or stages, of functionality:
All three levels of AccChecker provide similar functionality through verification routines that include Microsoft Active Accessibility programmatic access, programmatic event generation, control layout and keyboard navigation validation, and a basic screen-reader transcription service. Figure 4 illustrates the initial view of the AccChecker UI with default verifications.
Inspect Objects
Inspect Objects (Inspect) is a Microsoft Active Accessibility-based tool designed for inspecting and testing IAccessible COM interface properties as well as navigating UI elements and controls.
The Inspect tool tracks elements by using keyboard focus, mouse cursor movement, or its navigation tools. This built-in navigation is based on a snapshot view of the Microsoft Active Accessibility element tree hierarchy.
The Inspect tool is very useful for quickly discovering UI elements that lack unique and meaningful Microsoft Active Accessibility Name property values. The Name property is required for assistive technology devices, such as screen readers, to identify controls such as buttons, text boxes, list boxes, images, and links. Figure 5 shows the Inspect tool querying the Microsoft Active Accessibility properties of an element in the Notepad menu.
Accessible Explorer
Accessible Explorer (AccExplorer) is a Microsoft Active Accessibility-based tool that offers functionality that is very similar to the Inspect tool. However, it differs in two important features:
- A somewhat limited ability to track and display a live view of the Microsoft Active Accessibility element tree.
- Microsoft Active Accessibility verification of specific UI elements. The AccExplorer tool provides a passed, failed, and warning system on selectable Microsoft Active Accessibility properties based on the HRESULT returned by the automated query.
Figure 6 illustrates how to use the AccExplorer tool to verify specific Microsoft Active Accessibility properties for the Notepad content pane.
Accessible Event Watcher
Accessible Event Watcher (AccEvent) is a command-line tool that provides developers and testers with a means of validating Microsoft Active Accessibility-based WinEvents raised by UI elements. The AccEvent tool reports events when an element is invoked or selected, when it changes state, and when there is a change in focus.
You can track in-process and out-of-process events based on the options available with the Microsoft Active Accessibility SetWinEventHook function.
Even though the AccEvent tool may report some UI Automation-specific WinEvents, you should use a dedicated UI Automation client for testing UI Automation events due to the differing designs of the event object models in the two frameworks.
Figure 7 illustrates how the AccEvent tool catches the toolbar clock events.
Conclusion
No tool alone can definitively test and guarantee compliance with all accessibility guidelines. However, the tools described in this article make achieving that goal significantly easier through their comprehensive coverage of the many accessibility compliance issues that software vendors face today.
