比较 Microsoft Active Accessibility 和 UI 自动化
Windows 自动化 API 包含两种技术：Microsoft Active Accessibility 和 Microsoft UI 自动化。 Microsoft Active Accessibility 是作为 Windows 95 平台加载项引入的旧辅助功能技术，而 UI 自动化是一种较新的、更强大的技术，可克服 Microsoft Active Accessibility 固有的限制。
本主题总结了 Microsoft Active Accessibility 和 UI 自动化之间的主要差异。 它包括以下各部分：
- 基本设计原则
- 属性和控件模式
- MSAA 角色和 UI 自动化控件模式
- 对象模型导航
- 对象模型扩展性
- 从 MSAA 转换
- 选择 Microsoft Active Accessibility、UI 自动化或 IAccessibleEx
- 相关主题
基本设计原则
虽然 Microsoft Active Accessibility 和 UI 自动化是两种不同的技术，但二者的基本设计原则相似。 这两种技术的目的都是公开 Windows 应用程序中所用 UI 元素的丰富信息。 辅助功能工具的开发人员可以使用此信息创建相关软件，让 Windows 上运行的应用程序更便于在视、听或移动方面有障碍的人士访问。
Microsoft Active Accessibility 和 UI 自动化都将 UI 对象模型以植根于桌面的具有层次结构的树的形式公开。 Microsoft Active Accessibility 将单个 UI 元素表示为辅助对象，UI 自动化将其表示为自动化元素。 两者都将辅助功能工具或软件自动化程序称为客户端。 但是，Microsoft Active Accessibility 是指作为服务器来提供辅助功能 UI 的应用程序或控件，而 UI 自动化则指作为提供程序来提供同等内容的应用程序或控件。
属性和控件模式
Microsoft Active Accessibility 提供单个组件对象模型 (COM) 接口，其中包含固定的一小组属性。 UI 自动化提供更丰富的一组属性，以及一组称为控件模式的扩展接口，可采用 Microsoft Active Accessibility 无法实现的方式来操作可访问的对象。
有关详细信息，请参阅 UI 自动化属性概述和 UI 自动化控件模式概述。
MSAA 角色和 UI 自动化控件模式
Microsoft 在 Windows 95 发布的同时期设计了 Microsoft Active Accessibility 对象模型。 该模型基于十年前定义的“角色”，无法支持新的 UI 行为或将两个或多个角色合并。 例如，没有可帮助辅助技术处理复杂 Web 内容的文本对象模型。 UI 自动化通过引入使对象能支持多个角色的控件模式克服了这些局限性，并且 UI 自动化文本控件模式提供了一个完整的文本对象模型。
对象模型导航
Microsoft Active Accessibility 的另一个局限性涉及对象模型导航。 Microsoft Active Accessibility 将 UI 表示为可访问对象的层次结构。 客户端通过可访问对象提供的接口和方法从一个可访问对象导航到另一个可访问对象。 服务器可以使用 IAccessible 接口的属性或标准 IEnumVARIANT COM 接口公开可访问对象的子级。 但这要求客户端对于任何服务器都能同时使用这两种方法。 这种不确定性意味着客户端实现者需要执行额外工作，而服务器实现者会面临有问题的可访问对象模型。
UI 自动化将 UI 表示为自动化元素的层次结构树，并提供一个用于导航该树的单个接口。 客户端可以通过界定范围和筛选来自定义树中元素的视图。
对象模型扩展性
在不中断或更改 IAccessible COM 接口规范的情况下无法扩展 Microsoft Active Accessibility 属性和函数。 其结果是无法通过对象模型公开新的控件行为；它往往是静态的。
使用 UI 自动化时，随着 UI 元素的创建，应用程序开发人员可以引入自定义属性、控件模式和事件来描述新元素。 有关详细信息，请参阅自定义属性、事件和控件模式。
从 MSAA 转换
Windows 自动化 API 框架支持从 Microsoft Active Accessibility 服务器转换到 UI 自动化提供程序。 IAccessibleEx 接口支持将特定的 UI 自动化属性和控制模式添加到旧的 Microsoft Active Accessibility 服务器，而无需重写整个实现。 IAccessibleEx 接口还使进程内 Microsoft Active Accessibility 客户端可直接访问 UI 自动化提供程序接口，而无需通过 UI 自动化客户端接口访问。 有关详细信息，请参阅 IAccessibleEx 接口。
选择 Microsoft Active Accessibility、UI 自动化或 IAccessibleEx
本部分可帮助你确定用于实现辅助技术产品或使应用程序可让辅助技术产品访问的 Windows 自动化 API 解决方案。
新的应用程序和控件
如果要开发新的应用程序或控件，Microsoft 建议使用 UI 自动化。 虽然 Microsoft Active Accessibility 更易于在短期内实现，但这项技术固有的局限性（例如过时的对象模型、无法支持新的 UI 行为或合并角色）使其在长期更难利用且成本更高。 这些局限性在引入新控件时尤其明显。
UI 自动化对象模型比 Microsoft Active Accessibility 更易于使用且更灵活。 UI 自动化元素反映了用户界面的演变，开发人员可定义自定义 UI 自动化控件模式、属性和事件。
对于进程外运行的客户端，Microsoft Active Accessibility 往往运行缓慢。 为了提高性能，辅助功能工具程序的开发人员通常选择挂钩到目标应用程序进程中并在其中运行其程序：这是一种极其困难且有风险的方法。 对于进程外客户端，UI 自动化更容易实现、性能更好且更可靠。
现有 Microsoft Active Accessibility 实现
如果要更新基于 Microsoft Active Accessibility 的现有应用程序或控件，请考虑通过实现 IAccessibleEx 接口来添加对 UI 自动化的支持。 首先，确保应用程序或控件满足以下要求：
- 基线 Microsoft Active Accessibility 服务器的可访问对象层次结构须有良好的组织架构且无错误。 IAccessibleEx 无法解决现有可访问对象层次结构的问题。
- IAccessibleEx 实现必须同时符合 Microsoft Active Accessibility 规范和 UI 自动化规范。 Microsoft 提供了一组可验证是否符合这两种规范的工具。 有关详细信息，请参阅测试辅助功能。
如果不满足上述任一要求，请考虑以本机方式实现 UI 自动化。 如必要，可保留旧 Microsoft Active Accessibility 服务器实现以获得向后兼容性。 从 UI 自动化客户端的角度来看，UI 自动化提供程序与正确实现 IAccessibleEx 的 Microsoft Active Accessibility 服务器之间没有区别。
有关详细信息，请参阅 IAccessibleEx 接口。
相关主题