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