自动化无障碍测试是一个好的开始——但你也需要进行手动测试。
“有没有什么工具可以检查我的网站是否符合无障碍标准？”这是我有时会被问到的问题。（顺便说一句，答案是没有。）这通常会引出关于在开发流程中加入无障碍测试的讨论。
我也曾与一些人交流过，他们认为如果代码无法通过自动化测试，那就是糟糕的代码。我并不认同这种观点。就网站的可用性和可访问性测试而言，完全自动化是不可能的。目前还有太多因素无法通过程序进行检查。
这篇博文将简要探讨我所说的自动化无障碍测试的含义，并给出一些示例。我还会讨论为什么自动化测试还不够，并提供一些关于手动测试网站的技巧和延伸阅读材料。
我还想指出，最好是聘请真正的残障人士进行测试。例如，一位视力正常的测试人员，如果不经常使用屏幕阅读器，就只能发现网站上的有限问题。但是，我也明白这并非总是可行，所以作为开发人员，我们需要知道如何手动测试（至少）一些基本功能。
自动化无障碍测试
进行（半）自动化可访问性测试的方法有很多种。可以向代码检查工具添加插件，也可以使用插件来检查测试环境中的可访问性。此外，浏览器本身也内置了一些自动化工具，例如 Lighthouse。
所以，当我提到自动化测试时，我指的是所有获取代码、解析代码并以编程方式确定网站是否可访问的过程。
我将介绍一些可用于此目的的工具。这并非一份详尽的列表，而是我用过的一些工具。请注意：我主要使用 React 编写代码，因此这些工具也来自 React 领域。
行内检查器
eslint-plugin-jsx-a11y这是一个 eslint 插件。它可以在开发过程中检测辅助功能问题。我使用 VSCode 和 eslint-extension，所以如果我编写的代码违反了规则，代码编辑器就会发出警告：
这个插件可以帮助你发现一些容易发现的问题，例如缺少 alt 属性或缺少已声明角色的属性。
测试
测试是插件能够带来更多可访问性洞察的另一个领域。我根据测试环境的不同使用了两个插件：jest-axe和
cypress-axe。它们都将Deque 的测试解决方案axe-core 添加到了测试环境中。
也可以将 Google 的Lighthouse添加为npm模块，并将其测试集成到 CI/CD 流水线中。我猜其他工具也支持这些功能，但我还没试过。
浏览器中的工具
有很多扩展程序可以用来测试网站的可访问性。首先，谷歌的Lighthouse就是一种测试网站可访问性的方法。它内置于 Chrome 浏览器中，也可以作为插件添加到 Firefox 浏览器中。它的功能不仅限于检查可访问性；正如其网站上的介绍所说：
Lighthouse 是一款开源的自动化工具，用于提升网页质量。您可以将其应用于任何网页，无论是否公开访问，也无论是否需要身份验证。它提供性能、可访问性、渐进式 Web 应用、SEO 等方面的审核。
在Chrome浏览器中，您可以在开发者工具中找到它：
还有其他一些工具：Deque 的aXe和 WebAIM 的Wave都是用于以编程方式检查网页可访问性的实用工具。它们的工作方式略有不同。Axe 执行的检查与上面提到的测试库扩展程序相同。插件和测试库扩展程序都使用axe-core.
然而，Wave 会将问题所在之处可视化。在我看来，Wave 的呈现方式可能会显得相当混乱，难以理解。摸索了一段时间后，我才逐渐掌握了它的使用方法，但一开始可能会比较困难。事先提醒一下。
Axe 和 Lighthouse 都意识到他们的结果并不全面，他们还列出了需要手动检查的事项。
手动测试
我所说的手动测试，是指完全手动完成的测试。例如，这意味着使用屏幕阅读器或键盘——这些工具是残障人士用来上网的。
我想强调的是，如果您自己不使用屏幕阅读器（或其他辅助技术），您就无法真正了解使用这些技术的用户是如何使用网络的。所以，如果用户提出意见，请务必认真倾听。不过，学习一些使用这些技术进行测试的基础知识也很有帮助。
为什么要手动测试？
2019年，芬兰《数字服务提供法》正式生效。这意味着所有公共部门网站都必须遵守欧盟的无障碍指令要求。过渡期已于去年秋季结束，期间出现了一些关于公共部门网站是否符合无障碍标准的文章。
这些文章的典型特点是，对无障碍环境的评估通常仅采用灯塔无障碍审计的评分。此外，针对得分较低的城市和市政当局代表提出的问题也都是关于如何提高评分。
我查看并深入研究了那些得分100分的网站。用键盘快速测试了一下，立刻发现了一些问题。例如，在一个网站上，链接仅通过颜色区分。查看替代文本还发现一些文本，例如“这是网站的标志”。
这些产品已经不符合 WCAG 2.1 中的部分成功标准，而通过认证是必要条件。（具体来说，分别是 SC 1.4.1 和 SC 1.1.1）
总之，获得 Lighthouse 的完美无障碍评分只是一个开始。遵循这些要求通常会带来诸多好处，而且大多数容易实现的无障碍功能都能迎刃而解。另一方面，值得注意的是，即使网站获得了 Lighthouse 的完美评分，也可能完全无法访问。
根据不同的研究，自动化测试只能检测出大约 15% 到 40% 的故障。自动化测试容易忽略的一个典型例子是替代文本的质量。也就是说，它们可以检测到替代属性的存在，但无法判断这些文本是否具有描述性，或者图像是否纯粹是装饰性的，而替代文本应该为空字符串。
手动测试网站的技巧
使用键盘进行测试
测试网站的第一个方法，或许也是最简单的方法，就是只用键盘浏览——用 Tab 键在界面上移动。看看你能不能一边浏览一边判断自己身处何处。如果焦点消失，记下这些情况，并加以修复。
此外，请记住，除了使用 `\`tab和 ` \ enter` 进行导航之外，键盘导航还有一些其他规则。如需了解更多信息，请参阅WAI-ARIA 创作实践文档，其中提供了这些模式的完整列表。
屏幕阅读器测试
另一种可以用来测试的辅助技术是屏幕阅读器。我不会详细介绍它的使用方法，因为有很多其他有用的资源，而且我也不是这方面的专家。例如，WebAIM 就解答了很多关于屏幕阅读器测试的问题。
其他工具
还有一些其他工具可以帮助进行手动测试。首先要介绍的是浏览器开发者工具中的辅助功能。它们提供了多种调试和测试辅助功能的方法。阅读更多关于不同浏览器开发者工具的信息：
不过需要注意的是：不知何故，在 Firefox 和 Safari 中，您必须显式地启用它们。
还有其他一些有助于手动测试的工具。例如，Web Developer 扩展程序就是一个用于检查和可视化网站各个方面的实用工具。例如，您可以显示网站上的替代文本，以检查它们是否有意义：
我用过的另一个工具是可汗学院的tota11y。它是一个书签小程序，可以用来可视化标题、标签、颜色对比度和 alt 属性等方面的问题。我特别喜欢它的屏幕阅读器魔棒功能。有了它，我可以把鼠标悬停在某个项目上，看看屏幕阅读器会读出什么内容。这是一个实验性功能，不能替代实际的屏幕阅读器测试，但对于快速检查非常有用。
总结
自动化辅助功能测试和工具是发现代码中辅助功能缺陷的良好开端。这些缺陷通常是所谓的“唾手可得”的问题，相对容易修复。然而，仅仅修复这些问题并不能保证完全实现辅助功能。
使用键盘和屏幕阅读器等辅助技术进行手动测试，可以更深入地了解网站的可访问性。例如，仅使用键盘浏览网站可能会带来启发——您可能会发现，对于不使用鼠标的用户来说，该网站无法访问。
资源
工具
- eslint-plugin-jsx-a11y
- 杰斯特斧
- 柏树轴
- 斧核
- 斧头延伸
- Chrome开发者工具
- Firefox中的开发者工具
- Safari中的开发者工具
- 灯塔
- Web 开发人员扩展
- tota11y -书签小程序
其他链接
- GOV.UK——我们在世界上最难访问的网页上测试工具时发现了什么
- Manuel Matuzovic - 最难到达的地方，拥有完美的灯塔记分牌
- WAI-ARIA 创作实践
- WebAIM - 使用屏幕阅读器进行测试