可访问性测试

到目前为止，我们一直专注于构建具有强大功能和可视化测试功能的 UI 组件，并在此过程中增加了复杂性。但我们尚未解决 UI 开发的一个重要方面：可访问性。

为什么需要可访问性（A11y）？

可访问性确保所有用户都能有效地与我们的组件进行交互，无论他们的能力如何。这包括有视力、听力、运动或认知障碍的用户。可访问性不仅是正确的事情，而且由于法律要求和行业标准，它正变得越来越强制性。鉴于这些要求，我们必须尽早并频繁地测试我们的组件是否存在可访问性问题。

使用 Storybook 捕获可访问性问题

Storybook 提供了一个 可访问性插件 (A11y)，可帮助您测试组件的可访问性。它基于 axe-core 构建，可以捕获高达 57% 的 WCAG 问题。

让我们看看它是如何工作的！运行以下命令来安装插件

yarn exec storybook add @storybook/addon-a11y

重新启动您的 Storybook 以在 UI 中看到新启用的插件。

在我们的故事之间切换，我们可以看到该插件发现了一个测试状态的可访问性问题。 颜色对比度违规基本上意味着任务标题和背景之间的对比度不足。我们可以通过在应用程序的 CSS（位于 src/index.css）中将文本颜色更改为更深的灰色来快速修复它。

.list-item.TASK_ARCHIVED input[type="text"] {
- color: #a0aec0;
+ color: #4a5568;
 text-decoration: line-through;
}

就是这样。我们已经迈出了确保 UI 保持可访问性的第一步。但是，我们的工作还没有结束。维护可访问的 UI 是一个持续的过程，我们应该监控 UI 中是否存在新的可访问性问题，以防止随着我们应用程序的发展和 UI 复杂性的增加而引入回归。

使用 Chromatic 进行可访问性测试

借助 Storybook 的无障碍插件，我们可以在开发过程中测试无障碍性问题并获得即时反馈。但是，跟踪无障碍性问题可能具有挑战性，并且确定要优先解决哪些问题可能需要专门的努力。这时 Chromatic 可以帮助我们。如我们所见，它帮助我们进行视觉测试以防止回归。我们将使用其无障碍测试功能来确保我们的 UI 保持无障碍，并且我们不会意外引入新的违规行为。

启用可访问性测试

前往您的 Chromatic 项目并导航到管理页面。点击启用按钮以激活您项目的可访问性测试。

运行可访问性测试

现在我们已经启用了可访问性测试并在 CSS 中修复了颜色对比度问题，让我们推送我们的更改以触发新的 Chromatic 构建。

git add .
git commit -m "Fix color contrast accessibility violation"
git push

当 Chromatic运行时，它会建立 可访问性基线 作为后续测试与之比较的起点。这使我们能够更有效地优先处理、解决和修复可访问性问题，而不会引入新的回归。

我们现在已经成功构建了一个工作流程，可确保我们的 UI 在开发的每个阶段都保持可访问性。Storybook 将帮助我们在开发过程中捕获可访问性问题，而 Chromatic 则会跟踪可访问性回归，从而可以随着时间的推移逐步修复它们。