Skip to main content

无障碍测试

学习目标

完成本单元后,您将能够:

  • 解释为什么除了要执行自动化测试,还一定要执行手动无障碍测试。
  • 总结在 MacOS 上执行键盘和焦点管理测试的步骤。
  • 确定使用 VoiceOver 执行屏幕阅读器测试时要完成的检查。
  • 识别要包含在无障碍测试计划中的要素。
  • 描述有效执行手动无障碍测试的策略。

了解手动测试的重要性

虽然自动化无障碍测试可以发现许多问题,但这种测试无法理解上下文,也无法识别更微妙的无障碍问题。它们有时候甚至会遗漏严重的问题。这就是为什么还必须执行手动测试,以发现自动化测试未能识别的屏障。手动测试还能帮助您验证自动化测试中发现的问题,识别出“假阳性”结果。

一位开发人员正在执行手动无障碍测试。

与自动化无障碍测试不同,手动测试将用户旅程作为一个整体进行评估,以模拟残障或使用辅助技术的用户的体验。例如,手动键盘测试模拟用户仅使用键盘导航您的软件,而手动屏幕阅读器测试模拟视障用户如何体验您的软件。

让我们仔细了解一下手动无障碍测试,从键盘和焦点管理测试开始。

执行键盘和焦点管理测试

键盘和焦点管理测试是确保用户能够以直接、预期的方式导航并与 UI 交互的好方法。

在执行键盘测试时,探索以下几个问题:

  • 内容是否可通过多种输入方式访问?用户应该能够通过各种输入设备(例如语音指令、触摸屏和开关控制)来导航内容。如果某些内容仅在鼠标悬停时可用,那么使用触摸屏、语音听写和键盘的用户将会错过这些内容。
  • 焦点顺序是否合乎逻辑?焦点顺序是指交互元素(例如链接、按钮和表单字段)获得焦点的顺序。不合逻辑的焦点顺序会导致导航变得困难。
  • 用户能否高效且一致地导航内容?导航中的意外变化(例如不同的按键操作或命令)会给最终用户带来挑战,尤其是在他们使用辅助技术时。
  • 所有用户都能导航这些内容吗?请考虑存在运动、灵巧性和视力障碍的用户。

在 Mac 上进行测试时,您需要在键盘系统首选项中启用全键盘访问。按以下步骤操作。

在 MacOS 上启用键盘导航

  1. 打开 System Preferences(系统首选项)中的 Keyboard(键盘)设置。
  2. 选择 Shortcuts(快捷方式)选项卡。
  3. 在 Full Keyboard Access(全键盘访问)下,选择 All controls(所有控制项)

MacOS 中的 Keyboard Settings(键盘设置)界面中的 Shortcuts(快捷方式)选项卡,其中突出显示了 Full Keyboard Access(全键盘访问)字段并选中了 All controls(所有控制项)。

为 Safari 启用键盘访问

  1. 打开 Safari Preferences(首选项)
  2. 选择 Advanced(高级)选项卡。
  3. Accessibility(无障碍)下勾选 Press Tab to highlight each item on a webpage(按 Tab 键突出显示网页上的每个项目)

使用以下按键进行网页导航:

使用:

作用:

Tab 和 Shift+Tab

浏览链接、输入字段和其他交互式控件。按 Tab 在 UI 中向前移动,按 Shift+Tab 向后移动。如果您不能通过 Tab 键访问页面上的每一项,只能访问互动项,别担心。

Ctrl+Tab

浏览框架。

Enter

激活链接。

Enter 加空格

激活按钮。

空格

激活输入字段复选框并选择下拉菜单。

向上箭头和向下箭头

导航菜单和选项列表,以及自动完成下拉菜单。

向左箭头和向右箭头

浏览选项卡集或轮播中的选项卡。

Esc

关闭菜单、模式和面板。

您能触及每一个交互元素并触发其操作吗?

一些具有多个交互元素的复杂组件除了基础交互之外还具有更多独特的键盘交互,包括组合框、菜单、数据网格、非模式和模式对话框以及选项卡集。这些键盘交互遵循万维网联盟 (W3C) ARIA 创作实践指南所定义的特定预期。

Salesforce 根据这些预期构建其键盘指南,并将这些指南用于 Lightning 和 Lightning Design System 的 React 组件库。我们在 Lightning Design System 2 站点上汇总了一些有用的资源,以帮助您构建和测试这些组件。

测试键盘导航

测试键盘导航时,请验证以下项目:

  • Tab 顺序符合逻辑。使用键盘上的 Tab 键来浏览您的应用程序。默认导航顺序应该合乎逻辑并且感觉自然。
  • 键盘焦点可见。使用键盘浏览页面并确认视觉指示器显示键盘焦点所在的元素。
  • 可操作项获得焦点。使用键盘浏览页面。测试所有按钮、链接、表单域、选项卡和任何其他交互项是否可以接受键盘焦点。如果用户可以单击一个项目来执行操作或将鼠标悬停在它上面以显示信息,那么它就必须能够接受键盘焦点。
  • 可以导航交互元素。验证您是否可以导航所有交互式元素,例如菜单、模式、拖放元素、选项卡集、面板和自动完成下拉菜单。验证您是否可以使用键盘来选择和激活项目。
  • 可以导航模式对话框。使用键盘打开和导航模式对话框并操作其中的每个控件。确认您只能与当前模式窗口交互,而不是它后面的页面。当一个模式窗口打开时,焦点应该限制在窗口中。确保当模式框关闭时,焦点返回到页面上的正确位置。
备注

请记住,键盘测试和屏幕阅读器测试是不一样的。在使用屏幕阅读器进行测试之前,请先尝试键盘测试,以突出显示许多屏幕阅读器可能无法捕捉到的问题。

执行屏幕阅读器测试

我们建议在 macOS 和 Windows 上测试屏幕阅读器。MacOS 内置了一个名为 VoiceOver 的屏幕阅读器,它会大声朗读出所选元素,并读出其标签或替用文本。当您使用屏幕阅读器进行测试时,请确定您的替用文本是否准确,然后进行必要的调整。

以下是您可以在 MacOS 上使用 VoiceOver 完成的一些简单检查。

  • 使用 Cmd+F5 开启或关闭 VoiceOver。
  • 使用 Cmd+u 打开 Web Rotor。
  • 使用 Web Rotor 检查:
    • 链接和按钮具有简洁、有意义的标签。
    • 标题顺序正确。
    • 页面上有良好的陆标。
  • 用 Tab 键遍历 UI 以确认:
    • 可编辑字段说出它们的标签、输入类型和单词编辑。
    • 选项卡集指示选择了哪个选项卡,并且可以使用箭头键进行导航。
    • 使用空格键切换复选框时,复选框会发出声音说出它们的状态。

如果您无法通过屏幕阅读器使用 Tab 键遍历 UI 来访问所有内容,请不要担心。屏幕阅读器用户有特定的键盘快捷键,用于在页面中进行逐个元素导航,包括非交互式元素,所以 Tab 键不必(而且实际上不应该)触及所有内容。使用 VoiceOver,您可以使用 Ctrl+Option+向左箭头Ctrl+Option+向右箭头分别线性向后或向前阅读页面内容。

在 Windows 中,我们建议使用 NVDA

备注

使用多个屏幕阅读器执行无障碍测试。如果您只使用 VoiceOver 进行测试,则可能会遗漏其他屏幕阅读器(如 JAWS 或 NVDA)会捕获的特定问题。

如果您不经常使用屏幕阅读器,使用屏幕阅读器进行测试通常会出现用户错误。请参考“资源”部分中的 A11ycasts 视频,了解有关使用屏幕阅读器的细微差别的更多信息。

编写无障碍测试计划

将无障碍纳入组件规范、验收标准和用户故事中,让无障碍成为您测试计划的一部分。

示例:应用程序启动器

要打开应用程序启动器,请选择 应用程序。在应用程序启动器中,用户可以搜索应用、打开应用、阅读应用程序描述和重新排列应用程序。

展开了“所有应用程序”部分的应用程序启动器。

您可以为重新排列应用程序创建哪些测试用例?

这是与应用程序启动器相关的不同用例的测试计划示例。

为了便于理解,功能是指一个产品或系统能够做什么——即其功能和操作。功能可见性是一种设计元素,即通过对象的外观或行为建议应该如何使用对象。

类型

鼠标

键盘

屏幕阅读器

功能

单击磁贴打开应用程序

在磁贴上按 Enter 打开应用程序

所有键盘预期均适用

功能可见性

悬停时磁贴上显示移动光标

磁贴移动按钮具有明显的视觉焦点指示器

通知用户可能的交互

功能

单击并按住磁贴开始拖动

空格键启动拖动模式

用户进入拖动模式时读出的抓取状态、位置和指令

功能可见性

拖动模式具有明显的视觉状态(磁贴倾斜并呈现蓝色边框)

拖动模式具有明显的视觉状态(磁贴倾斜并呈现蓝色边框)

功能

拖动磁贴时移动鼠标

箭头键将应用程序移动到列表中的下一个/上一个位置

功能可见性

用户看到应用程序位置的预览

用户看到应用程序位置的预览

应用程序位置变化时读出

功能

松开鼠标结束拖动

Enter 键退出拖动模式

用户离开拖动模式时读出最终位置和抓取状态

您还可以添加哪些其他测试案例?如何去执行这些测试?您也许可以为屏幕阅读器属性和键盘行为编写自动化测试,但您仍需要进行一些手动测试以确保顺畅的体验。

使用手动测试策略

准备将所有内容整合在一起了吗?以下是执行高效手动无障碍测试的一些策略。

编写一个测试计划

可以包含以下内容:

  • 调用 $A.test.assertAccessible 以获取关键视觉状态(用于组件测试)。
  • 手动检查键盘流。
  • 考虑您的用例特有的因素。

尽早测试,经常测试

在构建用户界面时:

  • 手动测试。
  • 启用测试自动化。
  • 寻找机会通过自定义测试锁定无障碍。

记录和修复错误

在 Salesforce,我们优先考虑无障碍错误,无论受影响的用户数量有多少。因为对受影响的用户来说,这些错误可能成为阻碍他们完成工作的一道根本性屏障。但是,您的组织非常重视这些错误,主张将未解决的无障碍问题保持在最低限度。

通过执行自动化与手动无障碍测试并清除无障碍屏障,您将提供真正具有包容性的数字体验,让每个人都能参与并享受其中!

资源

在 Salesforce 帮助中分享 Trailhead 反馈

我们很想听听您使用 Trailhead 的经验——您现在可以随时从 Salesforce 帮助网站访问新的反馈表单。

了解更多 继续分享反馈