The New Accessibility Model for Windows
Thomas Logan, Microsoft, USA
Whether an individual with a disability uses a computer for programming/development, at work/home or for entertainment/gaming chances are that they use some type of assistive technology. If they are blind, they use a screen reader. If they can not use a standard keyboard/mouse because of a physical disability, they use an alternate input device. If they have a learning disability, they use a talking word processor and a scanning device to read for them. If they can't see or hear well as a result of the aging process, they use a screen magnifier AND turn up the volume on their system's speakers.
The availability of these assistive technology products and their compatibility with state-of-the-art operating systems and applications requires much vigilance on the part of major information technology companies, the enterprises that employ individuals with disabilities, disabled student services at schools/colleges around the world and the entire programming/development community that need to remember, not to forget, that individuals with disabilities and functional limitations will need to use the products that are required to be used independently and interacted with daily.
The actual design and development of assistive technology products is difficult and challenging. The current method used to develop hardware and software assistive technology that is compatible with the Windows operating system, and the applications that run on top of it, requires a significant investment from the programmer/developer. Today, these applications use a variety of UI technologies-each with a different object model (FIGURE 1). This approach is:
- Expensive
- Does not yield optimal results for end-users
- Leads to instability
- Makes it difficult for programmer/developers to know what to do in order to make their products accessible
- Makes it difficult for manufacturers of assistive technology products to innovate
As a result, historically individuals with disabilities have not had complete access to all applications that have been developed for the Windows operating system. In general, new applications or innovative technology are not compatible with existing assistive technology hardware and software. Because of the fact that assistive technology manufacturers are typically represented by small companies, these same companies are unable to provide their users with broad and deep access to the range of capabilities of a PC system. Complicating matters further, the ability of these companies and their developers to keep pace with the evolution of operating systems and applications, in particular with the low-level development required to make things work, is almost an impossible task.
Even though Microsoft Active Accessibility was developed to alleviate the necessity of having to do low level coding there is no architectural accessibility support provided by the Windows platform. As a result each development team must create its own infrastructure. This development challenge takes time away from product features. In addition, such investment rarely translates to other products or UI libraries.
Microsoft's goal with the release of the next version of Windows, code named Longhorn, is to offer a better solution and give manufacturers and developers of assistive technology products the time and opportunity to innovate. In other words, to give assistive technology product developers the time to focus on the customers instead of having to spend all their time finding a clever way to obtain the requisite information out of the GUI. At the same time, to provide programmers/developers in general with the architecture to use in order to make their applications more accessible. The proposed solution is UI Automation.
FIGURE 1:
UI Automation (FIGURE 2) is code provided by Microsoft's Accessible Technology Group (ATG) that programmatically drives another application's UI to yield a desired result and is a key part of the new accessibility model for Longhorn and other future versions of Windows. It gathers information about the user interface (UI) and dynamically discovers UI structure-extracting property information, receiving event notifications when the UI changes and querying for its behavior. UI Automation also interacts with UI elements (e.g. clicks a button, scrolls a list, moves a window, injects keystrokes and mouse input).
One consistent way to collect information from any application is to isolate the provider from client. In this case an assistive technology manufacturer/developer would not have to special case everything in order to insure a computer user with a disability had access to everything in the operating system/application. The UI Automation core sits between UIA Providers and UIA Clients. It exposes two sets of interfaces, one for providers and one for clients.
Provider interfaces allow a developer to:
- Plug their object model into UI Automation's tree
- Expose standard property information and fire events
- Expose custom properties and custom events
- Implement control patterns
Client side interfaces allow a developer to:
- Query the logical structure of a tree
- Discover UI elements - including Find and Query features
- Determine what functionality a control supports
- Call control-independent methods to drive a control
Proxies:
- Allow 3rd parties to easily plug their model into UI Automation
- Provides an easy way for developers to support UI Automation without modifying their code
In summary, UI Automation is managed code that provides platform level support, a consistent model for all UI elements and a security model that prevents un-trusted clients from using it. It will insure compatibility of assistive technology products with future versions of Windows, allow assistive technology manufacturers to create hardware and software products that are easier to use and insure that computer users with disabilities/functional limitations have access to a wider range of applications.
FIGURE 2:
