到目前为止，您在本课程中已了解数字无障碍功能的个人、业务和法律方面，以及数字无障碍功能合规性的基础知识。您已探索与包容性设计和编码相关的特定主题，包括何时使用 ARIA 与 HTML、如何衡量颜色对比度、何时必须使用 JavaScript 等主题。
在剩余的模块中，我们将从设计和构建转向无障碍功能测试。我们分享了一个三步测试流程，其中包含自动化、手动和辅助技术测试工具及技巧。在这些测试模块中，我们将使用相同的演示来逐步将网页从无法访问变为可访问。
每项测试（自动化测试、手动测试和辅助技术测试）对于打造尽可能无障碍的产品都至关重要。我们的测试以《Web 内容无障碍指南》(WCAG) 2.1 合规性 A 级和 AA 级作为标准。
请注意，您所属的行业、商品类型、当地和国家/地区的法律法规和政策，或总体无障碍目标决定了您应遵循哪些指南以及应达到哪些级别。如果您的项目不需要遵循特定标准，建议遵循最新版本的 WCAG。如需了解有关无障碍功能审核、一致性类型/级别、WCAG 和 POUR 的一般信息，请参阅“如何衡量数字无障碍功能？”。
现在您应该知道，在支持残障人士方面，无障碍功能合规性并非全部。不过，它是一个很好的起点，因为它可以提供一个可供测试的指标。除了进行一致性测试之外，我们还建议您采取以下措施，以帮助您打造更具包容性的产品：
- 与残障人士一起运行易用性测试。
- 聘用残障人士加入您的团队。
- 咨询具有数字无障碍专业知识的个人或公司。
自动化测试基础知识
自动化无障碍功能测试使用软件扫描您的数字产品，以检查其是否符合预定义的无障碍功能合规性标准。
自动化无障碍测试的优势：
- 在产品生命周期的不同阶段快速重复测试。
- 只需几步即可运行，结果很快就会显示。
- 您只需具备少量无障碍功能知识，即可运行测试或了解结果。
自动化无障碍功能测试的缺点：
- 自动化工具无法捕获产品中的所有无障碍功能错误
- 报告的误报（报告的问题并非真正的 WCAG 违规问题）
- 不同产品类型和角色可能需要使用多种工具
自动化测试是检查网站或应用无障碍功能的第一步，但并非所有检查都可以自动化。我们将在手动无障碍功能测试模块中详细介绍如何检查无法自动化的元素的无障碍功能。
自动化工具的类型
1996 年，应用特殊技术中心 (CAST) 开发了首批在线自动化无障碍功能测试工具之一，名为“Bobby 报告”。如今，有超过 100 种自动化测试工具可供选择！
自动化工具的实现方式各不相同，从无障碍浏览器扩展程序到代码检查器、桌面应用和移动应用、在线信息中心，甚至还有可用于构建自己的自动化工具的开源 API。
您决定使用哪种自动化工具可能取决于多种因素，包括：
- 您是根据哪些一致性标准和级别进行测试的？这可能包括 WCAG 2.2、WCAG 2.1、美国 508 条款或修改后的无障碍功能规则列表。
- 您要测试哪种类型的数字产品？可以是网站、Web 应用、原生移动应用、PDF、自助服务终端或其他产品。
- 您在软件开发生命周期的哪个阶段测试产品？
- 设置和使用该工具需要多长时间？个人、团队还是公司？
- 测试由谁进行：设计师、开发者、质量检查人员还是其他人？
- 您希望多久检查一次无障碍功能？报告中应包含哪些详细信息？问题是否应直接与工单系统相关联？
- 哪些工具在您的环境中效果最好？您的团队？
此外，还有许多其他因素需要考虑。如需详细了解如何为自己和团队选择最佳工具，请参阅 WAI 的文章“选择 Web 无障碍评估工具”。
演示：自动化测试
在自动化无障碍功能测试演示中，我们将使用 Chrome 的 Lighthouse。 Lighthouse 是一款自动化的开源工具，旨在通过不同类型的评估（例如性能、SEO 和无障碍功能）来提升网页的质量。
我们的演示网站是为虚构的组织“医学谜团俱乐部”而建的。此网站故意设为无法访问，以便进行演示。您可能会发现部分无障碍问题，而我们的自动化测试会发现部分（但并非全部）无障碍问题。
第 1 步
使用 Chrome 浏览器安装 Lighthouse 扩展程序。
您可以通过多种方式将 Lighthouse 集成到测试工作流中。在此演示中，我们使用的是 Chrome 扩展程序。
第 2 步
我们已在 CodePen 中构建了一个演示。
在调试模式下查看，以便继续进行后续测试。这一点很重要，因为它可以移除演示网页周围的 <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 或使用其他选项。根据您的环境和代码限制，一种方法可能比另一种方法更可取。
使用最简单的模式选项，并尽可能覆盖辅助技术，即向 <svg> 标记添加 role="img" 并添加 <title> 元素。
<a href="#!">
<svg role="img">
<title>Connect on our Twitter page.</title>
<path>...</path>
</svg>
</a>
问题 6：颜色对比度
背景色和前景色没有足够高的对比度。 对许多用户而言，对比度低的文本都是难以阅读或无法阅读的。 详细了解色彩对比度规则。
系统报告了两个示例。
#01aa9d，背景十六进制值为 #ffffff。
颜色对比度为 2.9:1。
#7c7c7c，而背景的十六进制颜色为 #ffffff。颜色对比度为 4.2:1。
我们来解决这个问题。
网页上检测到许多色彩对比度问题。正如您在颜色和对比度模块中所学到的，常规大小的文字（小于 18pt / 24px）的色彩对比度要求为 4.5:1，而大号文字（至少 18pt / 24px 或 14pt / 18.5px 粗体）和基本图标必须满足 3:1 的要求。
对于网页标题，由于其文字大小为 24 像素，属于大号文字，因此青绿色文字需要满足 3:1 的颜色对比度要求。不过，青色按钮上的文字为 16 像素粗体，属于常规大小的文字，因此必须满足 4.5:1 的色彩对比度要求。
在这种情况下，我们可以找到深到足以满足 4.5:1 对比度的蓝绿色，也可以将按钮文字的大小增加到 18.5 像素粗体，并稍微更改蓝绿色值。这两种方法都符合设计美学。
白色背景上的所有灰色文字（页面上的两个最大标题除外）在色彩对比度方面也未通过检查。此文本必须调暗，才能满足 4.5:1 的色彩对比度要求。
#008576，背景颜色保持为 #ffffff。更新后的颜色对比度为 4.5:1。点击图片即可查看完整尺寸的版本。
#767676，背景保持为 #ffffff。颜色对比度为 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 中。
下一步
干得漂亮。您已经取得了长足的进步，但我们还没有大功告成！ 接下来，我们将继续介绍手动检查，详情请参阅手动无障碍功能测试模块。