我经常手动测试的 4 件事

当我还是一名 Drupal 开发者时，我对自动化可访问性测试非常感兴趣。我非常喜欢自动化测试，尤其是当它被整合到我们的持续集成中时。自动化测试可以解决引入可访问性错误的构建失败问题，这是一个很好的方法，可以确保我们从一开始就考虑可访问性问题，而不会增加新的问题。然而，我觉得我们喜欢用自动化来解决问题，它并不能解决所有问题。自动化可访问性测试可以捕获那些细微的 HTML 错误，这样您就可以专注于手动处理更重要、更主观的问题。

无障碍设计由同理心驱动，而你无法自动化同理心。自动化确实让很多事情变得更容易，比如捕捉没有关联标签的文本输入，但以下是我为确保我的网站尽可能无障碍而采取的一些措施。

使用我的键盘浏览网站

这通常是我测试的第一件事。你可以使用 键开始浏览网站tab。我实际上并不会特意去测试这个，因为我最近一直用键盘导航，所以我默认已经在测试并发现问题了。以下是我在使用键盘测试时会考虑的一些事项：

• 我可以轻松完成导航吗？
• 这是一个超级菜单吗？如果是，有没有办法快速跳转到下一个顶级链接并浏览它们？例如，当我在一个服装电商网站上浏览菜单时。如果我在“男装”顶级菜单链接上寻找女装，我不想浏览所有男装的“夹克”、“下装”、“配饰”和“手表”菜单链接。我想直接跳转到“女装”顶级菜单链接。
• 对于像模态框这样的弹出窗口，有没有直观且快速退出的方法？比如，有没有“不用了，谢谢”的链接，或者按“Esc”键退出的方法？
• 我如何与手风琴互动？
• 我可以与选择列表交互吗？这一点需要测试，因为很多人在设计这些列表时并没有使用默认的 HTML。
• 我按下 Tab 键时，有没有哪一刻会让我不确定自己当前在哪儿？我的注意力是不是集中在屏幕上看不见的东西上？

在下面的动图里，你可以看到，当我们将焦点放在顶部菜单链接上时，子菜单甚至都没有展开。不过，当我们将鼠标悬停在顶部菜单链接上时，子菜单会展开。在这个例子中，自动可访问性测试可能没有发现这个缺陷，但如果有人使用 Tab 键浏览菜单，他们可能会发现它。

我可以继续说下去，但这些是我通常会考虑的因素。如果你有能力，我建议你和一位用户体验专家合作；但如果没有，那就自己判断吧。

打开屏幕阅读器

你知道 MacOS 有内置的屏幕阅读器吗？你知道 NVDA 是一款适用于 Windows 的免费屏幕阅读器吗？我们至少应该打开屏幕阅读器，确保它不会错过关键信息。

我建议你做的第一件事就是熟悉基本的屏幕阅读器命令tab。这会对你有很大帮助，因为你在浏览页面时，需要的不仅仅是按键。

问自己这些问题：

• 如何浏览我的交互功能是否显而易见？如果不明显，屏幕阅读器会解释吗？
• 屏幕阅读器是否会按照页面的逻辑顺序以及我想象中的视力正常的用户如何浏览页面？

肯特·C·多兹 (Kent C Dodds)写了迄今为止最受欢迎的推文，表达了对使用屏幕阅读器的人们的同情。

我们自认为很新颖、很现代，但有时诸如过多的表情符号、花哨的字体和其他一些奇怪的元素会对屏幕阅读器产生负面影响。在部署某些功能之前，最好先发现这些问题。

熟悉了基本的屏幕阅读器命令后，戴上眼罩浏览你的网站。这样就能清楚地判断网站是否易于访问。

确保您的替代文本有意义

从技术上讲，如果您有替代文本或空的替代文本，则不会在可访问性报告中被标记。但是，您的替代文本有意义吗？

如果您想了解更多信息，强烈建议您阅读我之前关于替代文本的文章——撰写重要的替代文本。我对此进行了更详细的介绍，但我建议您在手动测试清单中继续检查图片的替代文本。

通过波形工具

从技术上讲，这在某种程度上是自动化的，但我总是喜欢用Wave Tool仔细检查我的网站。这已经成为我的一个习惯，以确保自动化测试中出现的任何问题都符合预期。我非常喜欢这个工具；我知道市面上有很多其他工具，但我总是会用到它。我最喜欢的一点是，它能记录错误的含义、重要性以及如何修复错误。

结论

虽然自动化可访问性测试是一个很好的工具，可以让我们的生活更加易于管理，但我始终提倡手动测试那些可能更细微的项目。此外，手动测试也是让你的用户体验专家参与进来的好时机。这将帮助你和你的团队成员找到最佳行为，让你的应用程序对所有用户（而不仅仅是残障用户）的挫败感最小化。

你会手动测试什么？如果你对这篇博文有任何疑问，请在Twitter上或推特上告诉我。