New tools for Accessibility Interoperability
Microsoft just launched a new online resource and released two new open-source accessibility testing tools for developers who want to create accessible and assistive technology products that make it easier for everyone —including people with impairments and disabilities — to see, hear and use computers and other devices.
The two new tools, UI Accessibility Checker (AccChecker) and UI Automation Verify (UIA Verify), enable developers to test accessibility implementations and functionality in applications that use either Microsoft Active Accessibility (MSAA) or Microsoft User Interface Automation (UIA). Both tools were released through CodePlex.
AccChecker, which enables testers without previous MSAA experience to easily discover and correct problems in MSAA user interface implementations, was designed to fill a gap. Existing tools provided in-depth details about MSAA implementations, but no information about whether an implementation was correct.
AccChecker comes in three modes:
- a graphical user interface (GUI) tool for the initial investigations of UIs;
- a set of simple application programming interfaces (APIs) for easily creating automatic test cases;
- and a command-line tool for batch processing.
Using the GUI tool, testers can easily scan a UI and review a list of errors and warnings. Then, using the per-issue documentation, testers can determine why each issue has occurred, assess the implications for users with impairments or disabilities, and decide how to fix the problem. Once all issues have been addressed, testers can use the APIs to create regression tests. If testers are not skilled enough to use the APIs, they can employ the command-line mode to create tests in a batch file.
UIA Verify is a test automation framework that facilitates ad-hoc and automated testing for Microsoft UI Automation implementations. The framework provides the basis for tools such as the UI Automation Test Library and Visual UIA Verify, a graphical user interface for the test framework.
These tools also provide better support for UI Automation working group within the Accessibility Interoperability Alliance. The AIA was launched in December 2007 and its initial focus is on four areas:-
- Consistent keyboard access. Developing a set of keyboard shortcuts to provide consistent behavior to users of assistive technology products in any Web browser
- Interoperability of accessibility APIs. Modifying and/or extending existing accessibility models (Microsoft UI Automation, IAccessible2 and others) to improve the interoperability and exchange of information between IT and assistive technology (AT) products
- UI Automation extensions. Adding features and capabilities to support additional rich document scenarios, address new Web scenarios and more.
- Accessible Rich Internet Applications Suite (ARIA) mapping through UI Automation. Designing the mapping of rich Web accessibility information through UI Automation to ensure maximum value for AT products and, therefore, for people with disabilities
AIA's members now include Acapela Group, Adobe Systems, Bayfirst Solutions, Claro Software, Design Science, Inc., Dolphin Oceanic, Eyetech Digital Systems, Inc., GW Micro, HiSoftware, HP, Madentec, Microsoft, Novell, Oracle, QualiLife, Serotek Corporation and TextHelp Systems.
Microsoft committed to contribute its UI Automation specification to the AIA earlier this year. As a member of the AIA, Microsoft has agreed to grant a royalty-free license for any Microsoft patents necessary to implement required portions of the UI Automation Specification, as the specification may be modified and eventually published by the AIA. Companies also can implement the latest version of the UI Automation Specification, which is publicly available from Microsoft. The Community Promise that accompanies the UI Automation Specification permits royalty-free access to Microsoft patent claims necessary to implement required portions of both mandatory and optional parts of the UI Automation Specification.
I imagine the most common question will be why we didn't use the OSP for this. The UI Automation Community Promise FAQ :-
How does this differ from the Open Specification Promise and why isn’t the UI Automation Specification available under the OSP?
A. The Community Promise for UI Automation is much more like the OSP than it is different. It differs in that this promise requires an implementer to support the minimum required set of functions described in the UI Automation Specifications as functions that must be supported. In order to ensure that the UI Automation support is consistent from one implementation to another, a certain minimum set of functionality is required.