除了自动化访问性测试，我还对构建的页面做的六件事

本文翻译自《Beyond automatic accessibility testing: 6 things I check on every website I build》。如有翻译不当之处，请不吝指正。

我刚对客户端完成一次可访问性审核（accessibility audit），然后我决定将我在审核和构建站点过程中执行的各种测试分享给大家。你可以立即应用到项目中，而无需学习一种工具或软件。

Step 0：Automatic tests 自动化测试

我进行可访问性检测的第一件事就是使用LightHouse检查一下有没有明显的错误。自动化可访问性测试很好，但也只是检查了所需要全部测试的子集而已。就算得到100分或0个错误，但实际上也没有完成。这只意味着我们为手工测试打下了基础。

Step 1：Check image descriptions 检查图片描述

我执行的第一个半手工测试是检查图片是否都有描述以及描述是否正确。我使用了一个叫做Web Developer的拓展（译者注：文中的链接是firefox插件，chrome商店同样能找到该插件）。我们可以高亮没有alt属性的图片或在图片旁边展示alt属性值。

Step 2：Disable all styles 禁用所有样式

Web Developer拓展的另一个特性是能禁用页面的CSS。通过禁用CSS，你可以执行一些检查：

• 没有CSS（以防不能加载）网页能工作吗？
• 页面中的元素顺序有意义吗？
• 图片和图标尺寸正确吗？
• 文档结构合理吗？
  

Step 3: Validate HTML 验证HTML

我们能使用W3C Markup Validation Service来检查HTML结构。验证服务不能完成所有的事情，但在找出像重复的id或损坏的aria引用这些HTML中明显的bug中非常有用。

Step 4: Check the document outline 检查文档大纲

合理的文档大纲很重要。像应该以h1开头，然后是h2、h3等依次排列。这会对搜索引擎和屏幕阅读器很友好，因为它们在导航站点时可以从一个标题跳到另一个标题。

可以使用W3C Markup Validation Service来验证大纲，也可以使用totally工具来进行验证（如上图所示）。

Step 5: Grayscale mode 灰度模式

我使用一款叫做High Contrast的插件来观察站点在灰度模式下的表现。这是一项很重要的检查，因为这能告诉我们某些设计是否只能在有颜色时工作。我们应该确保不会仅用颜色传达信息。链接是一个很好的例子，它们应该有下划线，以使之和普通文本区分开来。下划线很美好！

Underline your fucking links you sociopaths. 给你的社交链接加上下划线
- Heydon Pickering

我们不需要安装浏览器拓展，使用CSS能实现类似的效果。

body {
  filter: grayscale(100%);
}

Step 6: Use the keyboard 使用键盘

移走鼠标，按tab键浏览页面，查看是否可以在没有鼠标、触摸板的情况下使用站点的每个部分。tab键是个很强大的测试工具，能告诉我们关于站点的很多东西：

• focus样式清晰可见吗？
• 任何可聚焦的东西都表现正常吗？
• 按钮是真的吗？
• 使用键盘的整个交互好吗？
• 是否正确的管理了focus？
• 是否能正确地隐藏或展示元素？
• 视觉顺序与DOM顺序是否匹配？
• 能在没有鼠标的情况下使用自定义JS组件吗?

甚至有个由Marcy Sutton构建的用于禁用鼠标光标的npm包。

故事还没完，我们还能检查更多东西，但现在就这些了。我将在另一篇文章中分享更多。