A11Y 101：可访问性审核的几种姿势
A11Y 101：可访问性审核的几种姿势
在《如何检测和修复可访问性》一文中和大家一起探讨了怎么让开发者在开发过程中检测和修复Web应用可访问性的问题。尽管近63%的开发者没有这方成的习惯，但如果我们想构建一个具有高可访问性的Web网站或Web应用就必须考虑可访问性相关的事项。而可访问性的一个关键方面就是审核（Accessibility Auditing）。了解应用程序是否具备可访问性，其最佳方法就是对其进行测试和度量；通过这种方式，可以确定在发布到生产环境之前是否需要进行修改。
事实上大多数开发人员在开发完成的定义中都排除了“可访问性”相关的任务。比如推特上这条推文就足以说明一切：
Web可访问审核是什么？
根据上述描述，那么可访问性审核（Accessibility Audit，缩写AA）是由开发人员、测试人员或无障碍环境专家对可访问性进行的审核，评估。并根据这些审核与评估出具一份能够指出开发工程师在开发可访问性的Web网站或Web应用中存的不足或需要改进的地方，以及提供相关的改进建议。
作为一名Web应用开发者，哪怕是你对可访问性的关注非常高，也可能需要一段时间才能掌握所有的指导原则（可访问性指导原则，即WCAG 指南），并能够从头到尾构建一个可访问性的应用，帮不会出现任何错误（事实上要做到这一点，难度还是非常的大）。换句话说，开发者掌握可访问性相关的技术和学习其他技术一样，除了了解相关的知识之外，还需要不断的练习，只有这样才能习惯A11Y的相关标准。而其中最简单的一种实践方法就是在开发过期间对代码进行审核（监测），并将所有不符合A11Y标准的错误按照修改建议进行修正。
在开发过程中要对代码进行可访问性审核，我们有一些工具、浏览器插件和库可以使用。这些都是一些强大的工具，可以自动检查可访问性问题，并在出现问题时得到通知。
为什么要审核？
大多数可访问性工具应该在已经部署的应用程序上运行，这可能会导致延迟和严重的调试问题。但这种现象也不是绝对的，因为我们有些工具和浏览器插件也可以让你在开发的过程中对可访问性进行检测和审核。呆会会和大家聊到这方面的知识。
但对于开发者而言，更喜欢的是一些自动审核的工具或库，比如：
- 它可能是一个命令（CLI，例如
pa11y） - 它可能是开发者调试器，比如Chrome浏览器中的Lighthouse Audits
- 它可能是一个浏览器插件，比如axe
- 它可能是构建工程中的一个NPM包，比如
eslint-plugin-jsx-a11y
这些工具或者库可以帮助开发者：
- 节省时间，提高效率
- 避免额外的调试
- 掌握可访问性的相关技术
接下来我们来看看在开发一个可访问性应用时有哪些可访问审核的方式可以帮助开发者。
使用可访问性CLI工具来检测Web应用的可访问性
对于很多开发者而言，会使用可访问性CLI工具来审核自己代码的同学较少，毕竟有近63%的开发者不测试（也不检测）有关于可访问性相关的事项。部分开发者，特别是对于前端同学而言，出于习惯性，总是喜欢手动来检测。事实上，没有必要这么做，我们可以借助可访问性的CLI来帮助我们对Web应用进行自动检测。
在社区中，用来检测Web可访问性的CLI工具，最流行的应该是 pa11y 和 axe-cli。接下来，我们简单地来看看这两款CLI怎么实现可访问性相关的检测。
Pa11y
Pa11y是我接触的第一款有关于检测可访问性的CLI工具。使用Pa11y不需要做过多的配置，我们只需要在本地电脑中安装Pa11y即可。你只需要在命令终端执行下面命令：
❯ npm install -g pa11y
执行完上述命令之后，在命令终端执行:
❯ pa11y -h
就可以查看到Pa11y CLI所有的参数：
这样一来，可以在命令终端对任何一个Web网站或域名（包括本地的）做可访问性相关的检测。比如：
正如上图所示，会将所有碍于可访问性的原因都罗列出来，开发者可以根据每条信息进行相应的修改。
上面我们看到的是一个全局的CLI命令，如果你不太喜欢这种方式，也可以在相应的项目中配置pa11y。在相应的工程中执行下面的命令：
❯ npm install pa11y --save
然后在相应的package.json文件中的scripts项配置npm命令，比如：
// package.json
"scripts": {
"test-a11y": "pa11y ./index.html"
}
然后在命令终端回到项目根目录之下，然后执行：
❯ npm run test-a11y
执行完上面的命令之后在命令终端会得到相应的结果，类似下图这样：
有关于pa11y更详细的介
剩余80%内容付费后可查看 本部分为付费内容，支付后可查看 支付3.99元 已支付？输入手机号查看 包月会员登录 购买包月会员推荐