通过

辅助功能测试

  • 项目

本主题介绍各种工具和过程，帮助你验证 Windows 和 Web 应用程序的辅助功能实现。

成功的用户体验

编程访问和键盘访问是支持应用程序中辅助功能的关键要求。 对于存在各种残障和限制（包括视力、学习、敏捷性/移动性以及语言/沟通障碍）或只喜欢使用键盘的人员，测试 Windows 应用程序、辅助技术 (AT) 工具和 UI 框架的辅助功能对确保此类人员获得成功的用户体验至关重要。

如果没有对辅助技术（AT）（例如屏幕阅读器和屏幕键盘）的充分支持，具有视觉、学习、敏捷性/移动性以及语言/通信障碍或限制的用户（以及那些只喜欢使用键盘的用户）可能会发现使用应用程序很难（如果不是不可能）。

辅助功能测试工具

辅助功能见解

Accessibility Insights 可帮助开发人员查找和修复网站和 Windows 应用程序中的辅助功能问题。

  • Accessibility Insights for Windows 可帮助开发人员查找并修复 Windows 应用中的辅助功能问题。 该工具支持三个主要方案：
    • Live Inspect 使开发人员只需将鼠标悬停在元素上或在元素上设置键盘焦点，即可验证应用中的元素是否具有正确的 UI 自动化属性。
    • FastPass - 一个分两步的轻型过程，可以帮助开发人员在不到五分钟的时间内识别常见的、高影响的辅助功能问题。
    • 故障排除支持诊断和修复特定的辅助功能问题。
  • Accessibility Insights for Web 是 Chrome 和 Microsoft Edge Insider 的扩展，可以帮助开发人员查找并修复 Web 应用和站点中的辅助功能问题。 它支持两个主要方案：
    • FastPass - 一个分两步的轻型过程，可以帮助开发人员在不到五分钟的时间内识别常见的、高影响的辅助功能问题。
    • 评估 - 允许任何人验证网站是否 100% 符合辅助功能标准和准则。 Accessibility Insights 还支持查看 UI 自动化元素、属性、控件模式和事件（类似于以下部分所述的 Inspect 和 AccEvent 旧工具）。

旧版测试工具

注意

此处介绍的工具仍可在 Windows SDK 中使用，但我们强烈建议过渡到 辅助功能见解。

Windows 软件开发工具包（SDK）包括多个辅助功能测试工具，包括 AccScope、检查和 UI 辅助功能检查器等。

可以从 Microsoft Visual Studio 命令提示符启动以下辅助功能测试工具，也可以导航到 开发计算机上安装 Windows SDK 的 bin 文件夹。

AccScope

AccScope 支持在早期设计和开发阶段对应用程序的辅助功能进行视觉评估。 AccScope 专门用于测试讲述人辅助功能方案，并使用应用提供的UI 自动化信息来显示可改进辅助功能的位置。

检查

你可以使用 Inspect 选择任何 UI 元素并查看其辅助功能数据。 可以查看Microsoft UI 自动化属性和控制模式，并测试UI 自动化树中自动化元素的导航结构。 它对于确保在扩展公共控件或创建自定义控件时正确设置属性和控件模式尤其有用。

开发 UI 时使用“检查”来验证辅助功能属性在UI 自动化中是如何公开的。 在某些情况下，属性来自已为默认 XAML 控件实现的UI 自动化支持。 在其他情况下，这些属性来自在 XAML 标记中设置的特定值，因为 AutomationProperties 附加属性。

下图显示了“检查”工具，用于查询记事本中“编辑”菜单元素的UI 自动化属性。

“检查”工具的屏幕截图。

UI Accessibility Checker

UI 辅助功能检查器（AccChecker） 可帮助你在运行时发现潜在的辅助功能问题。 AccChecker 包括针对 UI 自动化、Microsoft Active Accessibility 和 Accessible Rich Internet Applications (ARIA) 的验证检查。 它可对各种错误（例如缺少名称、树问题等）进行静态检查。 它有助于验证编程访问，并纳入用于自动执行辅助功能测试的高级功能。 可以在 UI 或命令行模式下运行 AccChecker 。 若要运行 UI 模式工具，请在 Windows SDK bin 文件夹中打开 AccChecker 文件夹，运行acccheckui.exe，然后单击“帮助”菜单。

UI 自动化验证

UI 自动化验证（UIA 验证）是一个框架，用于在控件或应用程序中手动和自动测试UI 自动化实现（可以记录结果）。 UIA 验证可以集成到测试代码中，并定期对UI 自动化方案执行自动测试或抽查，并可用于验证对具有已建立功能的应用程序所做的更改没有新问题或回归。 可以在 Windows SDK bin 文件夹的 UIAVerify 子文件夹中找到 UIA 验证。

Accessible Event Watcher

辅助事件观察程序（AccEvent）测试应用 UI 元素在 UI 更改发生时是否激发适当的UI 自动化和Microsoft活动辅助功能事件。 当焦点更改或调用 UI 元素、选择或具有状态或属性更改时，UI 中的更改可能会发生。 AccEvent 通常可用于调试问题并验证自定义控件和扩展控件是否正常工作。

辅助功能测试过程

测试键盘辅助功能

测试键盘辅助功能的最佳方式是拔出鼠标，或者在使用平板电脑设备时使用屏幕键盘。 使用 Tab 键测试键盘辅助功能导航。 应该能够使用 Tab 键循环访问所有交互式 UI 元素。 对于复合 UI 元素，请使用箭头键验证是否可以在元素的各个部分之间导航。 例如，应该能够使用键盘键导航项目列表。 最后，确保在这些元素具有焦点后，可以使用键盘调用所有交互式 UI 元素，通常通过使用 Enter 或空格键。

验证可见文本的对比度

使用颜色对比度工具验证可见文本对比度是否可接受。 这些例外包括非活动 UI 元素，以及徽标或装饰性文本，这些元素不传达任何信息，并且无需更改含义即可重新排列。 有关对比度和异常的详细信息，请参阅 辅助文本要求 。 有关可以测试对比度的工具，请参阅 WCAG 2.0 G18（资源部分） 的技术。

注意

WCAG 2.0 G18 技术列出的某些工具无法与 UWP 应用交互使用。 可能需要在工具中手动输入前景和背景色值，对应用 UI 进行屏幕捕获，然后在屏幕捕获图像上运行对比度工具，或在图像编辑程序中打开源位图文件时运行该工具，而不是当应用加载该图像时运行该工具。

验证应用是否具有高对比度

在高对比度主题处于活动状态时使用你的应用来验证所有 UI 元素是否都正确显示。 所有文本都应可读，所有图像都应清晰。 调整 XAML 主题字典资源或控件模板以更正来自控件的任何主题问题。 如果突出的高对比度问题不是来自主题或控件（例如来自图像文件），则提供在高对比度主题处于活动状态时要使用的单独版本。

使用显示设置验证应用

使用系统显示选项调整显示点/英寸（dpi）值，并确保应用 UI 在 dpi 值更改时正确缩放。 （某些用户将 dpi 值更改为辅助功能选项，可从 轻松访问 以及显示属性。如果发现任何问题，请按照 布局缩放 指南进行操作，并为不同的缩放因素提供其他资源。

使用讲述人验证主要应用方案

使用讲述人测试应用的屏幕阅读体验。

使用以下步骤通过鼠标和键盘使用讲述人测试应用：

  1. 按 Windows 徽标键 + Ctrl + Enter 启动讲述人。 在 Windows 10 版本 1607 之前的版本中，使用 Windows 徽标键 + Enter 启动讲述人。
  2. 使用 Tab 键、箭头键和 Caps Lock + 箭头键导航应用。
  3. 导航应用时，侦听讲述人读取 UI 的元素并验证以下内容：
    • 对于每个控件，请确保讲述人读取所有可见内容。 此外，请确保讲述人读取每个控件的名称、任何适用的状态（已选中、选定等），以及控件类型（按钮、复选框、列表项等）。
    • 如果该元素是交互式的，请通过按 Caps Lock + Enter 验证是否可以使用讲述人调用其操作。
    • 对于每个表，请确保讲述人正确读取表名称、表说明（如果可用），以及行标题和列标题。
  4. 按 Caps Lock + Shift + Enter 搜索应用，并验证所有控件是否显示在搜索列表中，以及控件名称是否已本地化且可读。
  5. 关闭监视器并尝试仅使用键盘和讲述人完成主要应用方案。 若要获取讲述人命令和快捷方式的完整列表，请按 Caps Lock + F1。

从 Windows 10 版本 1607 开始，我们在讲述人中引入了新的开发人员模式。 当“讲述人”已经在运行时，通过按 Control + Caps Lock + F12 打开开发人员模式。 启用开发人员模式后，屏幕将被屏蔽，仅突出显示可访问的对象和以编程方式向讲述人公开的关联文本。 这为你提供了向讲述人公开的信息的良好视觉表示形式。

使用以下步骤使用讲述人的触摸模式测试应用：

注意

讲述人会自动在支持 4+ 联系人的设备上进入触摸模式。 讲述人不支持主屏幕上的多监视器方案或多点触控数字化器。

  1. 熟悉 UI 并浏览布局。

    • 使用单指轻扫手势浏览 UI。 使用向左或向右轻扫在项目之间移动，向上或向下轻扫可更改正在导航的项目类别。 类别包括所有项、链接、表、标头等。 使用单指轻扫手势导航类似于使用 Caps Lock + Arrow 进行导航。
    • 使用制表符手势在可聚焦元素中导航。 向右或向左轻扫三指与使用 键盘上的 Tab 和 Shift + Tab 导航相同。
    • 用一根手指空间调查 UI。 向上和向下或向右拖动一根手指，让讲述人阅读手指下的项目。 可以使用鼠标作为替代方法，因为它使用与拖动单指相同的命中测试逻辑。
    • 阅读整个窗口及其所有内容，用三根手指向上轻扫。 这相当于使用 Caps Lock + W。

    如果无法访问重要的 UI，则可能会出现辅助功能问题。

  2. 与控件交互以测试其主要操作和辅助操作及其滚动行为。

    主要操作包括激活按钮、放置文本插入符号和将焦点设置为控件等内容。 辅助操作包括选择列表项或展开提供多个选项的按钮等操作。

    • 若要测试主要操作：双击或用一根手指按，然后用另一根手指点击。
    • 若要测试辅助操作：三次点击，或用一根手指按，然后双击另一个。
    • 若要测试滚动行为：使用双指轻扫在所需方向滚动。

    某些控件提供其他操作。 若要显示完整列表，请输入一个四指点击。

    如果控件响应鼠标或键盘，但不响应主要或辅助触摸交互，则控件可能需要实现其他UI 自动化控件模式。

还应考虑使用 AccScope 工具通过应用测试讲述人辅助功能方案。 AccScope 工具主题介绍如何配置 AccScope 以测试讲述人方案。

检查应用的UI 自动化表示形式

前面提到的一些UI 自动化测试工具提供了一种以有意不考虑应用外观的方式查看应用的方法，而是将应用表示为UI 自动化元素的结构。 这就是UI 自动化客户端（主要是辅助技术）将在辅助功能方案中与应用交互的方式。

AccScope 工具提供了一个特别有趣的应用视图，因为你可以将UI 自动化元素视为视觉表示形式或列表。 如果使用可视化效果，可以向下钻取到部件，以便能够与应用的 UI 的视觉外观相关联。 甚至可以在将所有逻辑分配给 UI 之前测试最早 UI 原型的辅助功能，确保应用的视觉交互和辅助功能方案导航均处于平衡状态。

可以测试的一个方面是，在不想出现在UI 自动化元素视图中的元素是否显示。 如果从视图中找到要省略的元素，或者相反，如果缺少元素，则可以使用 AutomationProperties.AccessibilityView XAML 附加属性来调整 XAML 控件在辅助功能视图中的显示方式。 查看基本辅助功能视图后，这也是重新检查选项卡序列或空间导航（由箭头键启用）的好机会，以确保用户可以访问控件视图中交互和公开的每个部件。