自动化无障碍功能测试

到目前为止，在本课程中，您已了解数字无障碍功能的个人、业务和法律方面，以及数字无障碍功能合规性的基础知识。您还探索了与包容性设计和编码相关的特定主题，包括何时使用 ARIA 而不是 HTML、如何衡量颜色对比度、何时 JavaScript 至关重要等主题。

在剩余的模块中，我们将从设计和构建转向无障碍功能测试。我们将分享一个三步测试流程，其中包括自动化、手动和辅助技术测试工具和技术。在这些测试模块中，我们将使用相同的演示，将网页从无法访问变为可访问。

每项测试（自动化、手动和辅助技术）对于实现尽可能无障碍的产品至关重要。我们的测试以《网络内容 无障碍指南》(WCAG) 2.1 合规性 A 级和 AA 级为 标准。

请注意，您所在的行业、产品类型、当地和国家/地区的法律和政策或总体无障碍功能目标决定了要遵循哪些指南以及要达到哪些级别。如果您的项目不需要特定标准，建议您遵循最新版本的 WCAG。 如需了解有关无障碍功能审核、合规性类型/级别、WCAG 和POUR 的一般信息，请参阅“如何衡量数字无障碍功能？”。

正如您现在所知，在为残障人士提供支持方面，无障碍功能合规性并非全部内容。 不过，这是一个很好的起点，因为它提供了一个可供测试的指标。我们建议您除了进行合规性测试外，还采取以下措施，以帮助您构建更具包容性的产品：

• 与残障人士一起运行可用性测试。
• 聘请残障人士加入您的团队。
• 咨询具有数字无障碍功能专业知识的个人或公司。

自动化测试基础知识

自动化无障碍功能测试使用软件扫描您的数字产品，以检查是否存在违反预定义的无障碍功能合规性标准的问题。

自动化无障碍功能测试的优势：

• 在产品生命周期的不同阶段快速重复测试。
• 只需几个步骤即可运行，且结果非常快速。
• 运行测试或了解结果所需的无障碍功能知识很少。

自动化无障碍功能测试的缺点：

• 自动化工具无法捕获产品中的所有无障碍功能错误
• 报告误报（报告的问题并非真正的 WCAG 违规行为）
• 对于不同的产品类型和角色，可能需要使用多种工具

自动化测试是检查网站或应用无障碍功能的第一步，但并非所有检查都可以自动化。在 手动无障碍功能测试模块中，我们将详细介绍如何检查无法自动化的元素的无障碍功能。

自动化工具的类型

最早的在线自动化无障碍功能测试工具之一是由应用特殊技术中心 (CAST) 于 1996 年开发的，名为 "The Bobby Report。"如今，有 100 多种自动化测试工具可供选择 ！

自动化工具的实现方式各不相同，从无障碍功能浏览器扩展程序到代码检查器、桌面和移动应用、在线信息中心，甚至还有可用于构建自己的自动化工具的开源 API。

您决定使用哪种自动化工具可能取决于许多因素，包括：

• 您要测试哪些合规性标准和级别？这可能 包括 WCAG 2.2、WCAG 2.1、美国 508 条款、 或修改后的无障碍功能规则列表。
• 您要测试哪种类型的数字产品？这可能是网站、Web 应用、原生移动应用、PDF、自助服务终端或其他产品。
• 您要在软件开发生命周期的哪个阶段测试产品？
• 设置和使用该工具需要多少时间？对于个人、团队或公司？
• 谁在进行测试：设计人员、开发者、质量检查人员还是其他人？
• 您希望多久检查一次无障碍功能？报告中应包含哪些详细信息？问题是否应直接链接到问题跟踪系统？
• 哪些工具在您的环境中效果最好？对于您的团队？

还有许多其他因素需要考虑。如需详细了解如何为自己和团队选择最佳工具，请查看 WAI 关于 “选择 Web 无障碍功能评估工具” 的文章。

演示：自动化测试

对于自动化无障碍功能测试演示，我们将使用 Chrome 的 Lighthouse。 Lighthouse 是一款自动化的开源工具，旨在通过不同类型的审核（例如性能、SEO 和无障碍功能）来提升网页的质量。

我们的演示是一个为虚构组织“Medical Mysteries Club”构建的网站。为了进行演示，此网站特意设置为无法访问。您可能会看到一些无法访问的情况，而我们的自动化测试会捕获一些（但不是全部）无法访问的情况。

第 1 步

使用 Chrome 浏览器安装 Lighthouse 扩展程序。

有很多方法可以将 Lighthouse 集成到测试工作流程中。在此演示中，我们使用 Chrome 扩展程序。

第 2 步

我们在 CodePen 中构建了一个 演示。 在调试模式下查看该演示，以继续进行后续测试 。这一点很重要，因为这样可以移除围绕 演示网页的 <iframe>，而该 iframe 可能会干扰某些测试工具。

详细了解 CodePen 的调试模式。

第 3 步

打开 Chrome 开发者工具，然后 前往 Lighthouse 标签页。清除“无障碍功能”以外的所有类别选项。 将模式保留为默认模式，然后选择您要在其上运行测试的设备类型。

第 4 步

点击分析网页加载 ，让 Lighthouse 有时间运行其测试。

测试完成后，Lighthouse 会显示一个分数，用于衡量您要测试的产品的 无障碍程度。 Lighthouse 分数 是根据检测到的问题数量、问题类型以及 问题对用户的影响计算得出的。

除了分数之外，Lighthouse 报告还包含有关检测到的问题的详细信息，以及指向相关资源的链接，以便您详细了解如何解决这些问题。该报告还包含通过或不适用的测试，以及需要手动检查的其他项的列表。

第 5 步

现在，我们来了解一下发现的每个自动化无障碍功能问题的示例，并修复相关样式和标记。

问题 1：ARIA 角色

第一个问题指出：“具有 ARIA [role] 且要求子元素必须包含特定的 [role] 的元素缺少部分或全部必需子元素。 一些 ARIA 父角色必须包含特定子角色，才能执行它们的预期无障碍功能。” 详细了解 ARIA 角色规则。

在我们的演示中，新闻简报订阅按钮失败：

<button role="list" type="submit" tabindex="1">Subscribe</button>

我们来修复一下。

输入字段旁边的“订阅”按钮应用了不正确的 ARIA 角色。在这种情况下，可以完全移除该角色。

<button type="submit" tabindex="1">Subscribe</button>

问题 2：ARIA 隐藏

"[aria-hidden="true"] 元素包含可聚焦的下级元素。有一个 [aria-hidden="true"] 元素包含可聚焦的 下级元素，导致这些交互式 元素都无法被辅助技术（如屏幕 阅读器）用户使用。详细了解 aria-hidden 规则。

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>

我们来修复一下。

输入字段应用了 aria-hidden="true" 属性。添加此属性会向辅助技术隐藏该元素（及其下方的所有嵌套元素）。

<input type="email" placeholder="Enter your e-mail address" tabindex="-1" required>

在这种情况下，您应从输入中移除此属性，以便使用辅助技术的人员能够访问表单字段并在其中输入信息。

问题 3：按钮名称

按钮缺少可供访问的名称。当某个按钮没有可供访问的名称时，屏幕阅读器会将它读为“按钮”，这会导致依赖屏幕阅读器的用户无法使用它。

详细了解按钮名称规则。

<button role="list" type="submit" tabindex="1">Subscribe</button>

我们来修复一下。

当您从 问题 1中的按钮元素中移除不准确的 ARIA 角色时，“订阅”一词将成为可供访问的按钮 名称。此功能内置于语义 HTML 按钮元素中。对于更复杂的情况，还有其他模式选项可供考虑。

<button type="submit" tabindex="1">Subscribe</button>

问题 4：图片 alt 属性

图片元素缺少 [alt] 属性。说明性元素应力求使用简短的描述性替代文字。未指定 alt 属性的装饰性元素可被忽略。详细了解图片替代文字 规则。

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>

我们来修复一下。

由于徽标图片也是一个链接，因此您从 图片模块中了解到，它被称为可操作 图片，并且需要提供有关图片用途的替代文字信息。 通常，网页上的第一张图片是徽标，因此您可以合理地假设辅助技术用户会知道这一点，并且您可以决定不在图片说明中添加此额外的上下文信息。

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png"
    alt="Go to the home page.">
</a>

问题 5：链接文字

链接缺少可识别的名称。请确保链接文字（以及用作链接的图片替代文字）可识别、独一无二且可聚焦，这样做会提升屏幕阅读器用户的导航体验。 详细了解链接文字规则。

<a href="#!"><svg><path>...</path></svg></a>

我们来修复一下。

网页上的所有可操作图片都必须包含有关链接将用户发送到何处的信息。解决此问题的一种方法是，像在示例中的徽标图片上一样，向图片添加有关用途的替代文字。此方法非常适用于使用 <img> 标记的图片，但 <svg> 标记无法使用此方法。

对于使用 <svg> 标记的社交媒体图标，您可以使用 针对 SVG 的其他替代说明模式 ，在 <a> 和 <svg> 标记之间添加信息，然后 以视觉方式向用户隐藏该信息，添加受支持的 ARIA 或其他选项。根据您的环境和代码限制，一种方法可能比另一种方法更可取。

使用最简单的模式选项，并尽可能覆盖辅助 技术，即向 role="img" 添加 <svg> 标记并 添加 <title> 元素。

<a href="#!">
  <svg role="img">
    <title>Connect on our Twitter page.</title>
    <path>...</path>
  </svg>
</a>

问题 6：颜色对比度

背景色和前景色没有足够高的对比度。 对许多用户而言，对比度低的文本都是难以阅读或无法阅读的。 详细了解颜色对比度规则。

报告了两个示例。

我们来修复一下。

网页上检测到许多颜色对比度问题。正如您在 颜色和对比度模块中所了解的那样， 常规大小的文本（小于 18pt / 24px）的颜色对比度要求为 4.5:1，而大号文本（至少 18pt / 24px 或 14pt / 18.5px 粗体）和 基本图标必须满足 3:1 的要求。

对于网页标题，青色文本需要满足 3:1 的颜色对比度要求，因为它是 24px 的大号文本。不过，青色按钮被视为 16px 粗体的常规大小文本，因此必须满足 4.5:1 的颜色对比度要求。

在这种情况下，我们可以找到一种足够深的青色来满足 4.5:1 的要求，也可以将按钮文本的大小增加到 18.5px 粗体，并稍微更改青色值。这两种方法都符合设计美学。

白色背景上的所有灰色文本（网页上的两个最大标题除外）的颜色对比度也未通过测试。必须将此文本调暗，以满足 4.5:1 的颜色对比度要求。

问题 7：列表结构

列表项 (<li>) 未包含在 <ul> 或 <ol> 父元素中。 屏幕阅读器要求列表项 (<li>) 必须包含在父 <ul> 或 <ol> 中，这样才能正确读出它们。

详细了解列表规则。

<div class="ul">
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</div>

我们来修复一下。

在此演示中，我们使用 CSS 类来模拟无序列表，而不是 使用 <ul> 标记。当我们编写此代码不正确时，我们移除了此标记中内置的固有语义 HTML 功能。通过将类替换为真实的 <ul> 标记并修改相关的 CSS，我们解决了此无障碍功能问题。

<ul>
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</ul>

问题 8：tabindex

某些元素的 tabindex 值大于 0。值大于 0 意味着明确的导航顺序。尽管这在技术上可行，但往往会让依赖辅助技术的用户感到沮丧。 详细了解 tabindex 规则。

<button type="submit" tabindex="1">Subscribe</button>

我们来修复一下。

除非有特定原因需要中断网页上的自然 Tab 键顺序，否则无需在 tabindex 属性中使用正整数。如需保留自然 Tab 键顺序，我们可以将 tabindex 更改为 0，也可以完全移除该属性。

<button type="submit">Subscribe</button>

第 6 步

现在，您已修复所有自动化无障碍功能问题，请打开一个新的调试模式页面。再次运行 Lighthouse 无障碍功能审核。您的分数应比第一次运行时的分数高得多。

我们已将所有这些自动化无障碍功能更新应用于新的 CodePen。

下一步

干得漂亮。您已经完成了很多工作，但我们还没有完成！ 接下来，我们将继续进行手动检查，如 手动无障碍功能测试模块中所述。