This section briefly describes the architecture of the Windows Automation technologies Microsoft Active Accessibility and Microsoft UI Automation, and the components that allow interoperability between applications based on the two different technologies.

Microsoft Active Accessibility Architecture

Microsoft Active Accessibility exposes basic information about custom controls such as control name, location on screen, and type of control, as well as state information such as visibility and enabled/disabled status. The UI is represented as a hierarchy of accessible objects; changes and actions are represented as WinEvents.

Microsoft Active Accessibility consists of the following components:

• Accessible object—A logical UI element (such as a button) that is represented by an IAccessible COM interface and an integer child identifier (ChildID).
• WinEvents—An event system that enables servers to notify clients when an accessible object changes.
• OLEACC.dll—The run-time, dynamic-link library that provides the Microsoft Active Accessibility API and the accessibility system framework. OLEACC implements proxy objects thah provide default accessibility information for standard UI elements, including USER controls, USER menus, and common controls.

For Microsoft Active Accessibility, the system component of the accessibility framework (OLEACC) helps the communication between accessibility tools and applications, as the following illustration shows.

The applications (Microsoft Active Accessibility servers) provide UI accessibility information to tools (Microsoft Active Accessibility clients), which interact with the UI on behalf of users. The code boundary is both a programmatic and a process boundary.

UI Automation Architecture

With UI Automation, the UI Automation Core component (UIAutomationCore.dll) is loaded into both the accessibility tools' and applications' processes. The core component manages cross-process communication, provides higher level services such as searching for elements by property values, and enables bulk fetching or caching of properties, which provides better performance than the Microsoft Active Accessibility implementation.

UI Automation includes proxy objects that provide UI information about standard UI elements such as USER controls, USER menus, and common controls. It also includes proxies that enable UI Automation clients to get UI information from Microsoft Active Accessibility servers.

The following illustration shows the relationships among the various components in UI Automation providers (Accessibility Tools) and clients (Applications).

Interoperability Between Microsoft Active Accessibility-Based Applications and UI Automation-Based Applications

The UI Automation to Microsoft Active Accessibility Bridge enables Microsoft Active Accessibility clients to access UI Automation providers by converting the UI Automation object model to a Microsoft Active Accessibility object model. The following illustration shows the role of the UI Automation-to-Microsoft Active Accessibility Bridge.

Similarly, the Microsoft Active Accessibility-to-UI Automation Proxy translates Microsoft Active Accessibility-based server object models for UI Automation clients. The following illustration shows the role of the Microsoft Active Accessibility-to-UI Automation Proxy.

By using the IAccessibleEx interface, you can improve existing Microsoft Active Accessibility Server implementations by adding only required UI Automation object model information. The Microsoft Active Accessibility-to-UI Automation Proxy takes care of incorporating the added UI Automation object model. For more information, see The IAccessibleEx Interface.

See Also

Windows Automation API: Overview

Send comments about this topic to Microsoft

Build date: 7/13/2009