从头开始认识可访问性
假设你从0开始或者重做一个网页或者网页应用，并且你希望把它做好。你显然无法忽视可访问性，而且你知道它很重要，食物链上的任何人（都是老板）都没有质疑这一点（或投入足够的资金来关心）。这真是个好消息！让我们让项目变得可 访 问吧。✨
不过，这可能让人感觉有点害怕。想知道如何开始执行如此大的任务可能会很棘手。但不要害怕！在这篇文章中，我们将看到如何开始实现可访问性，以便在项目的整个开发周期中考虑它，而不是像往常一样最后再考虑。
认识可访问性性
我在2020 年 A11y Advent Calendar 的第一部分写了关于什么是可访问性，👇简单说一下。
总体思路是为每个人提供平等的内容访问权限，无论他们是谁或他们如何上网。因此，界面的可访问性需要考虑任何人，无外乎他们的身体健全性，或他们访问内容的上下文。实际上，我们可以将障碍分为 5 大类，每一类的范围都十分广泛，需要考虑的因素有很多：视觉、运动、认知、听觉和声音。
因此，当（重）新构建项目时，你必须记住，你使用它的方式很可能与许多其他人不同。无须多言，在构建软件时避免做出太多假设并保持开放的心态是好的。
如果有人要求你提供更具体的内容，你可以告诉他们可访问性是通过Web 内容可访问性指南（简称 WCAG）审核的。WCAG 提供了根据 POUR 原则组织的十几个准则，代表可感知、可操作、可理解和健康性。每个准则都可以通过指定标准（总共超过 80 个）进行测试，每个准则都有 3 个级别：A、AA 和 AAA。
符合标准意味着至少得通过 A 标准。可以进一步努力实现更高的级别（如果可以的话），但它本身并不一定是目标。除了完全遵守 WCAG 之外，很多工作都可以（并且应该）投入到可访问性中。
编写文档
因为可访问性测试不能完全自动化（我们将在后面看到），所以你在工作时记录期望和实现很重要，尤其是对于更复杂的界面组件，如交互式小部件。
作为一个团队编写无障碍手册是确保每个人都参与该计划的好方法，并将部分内容在产品团队中分散开来，因此不会落到某人的肩上以确保一切都可以访问。
我写过关于我们如何在 N26 上使技术文档成为一等公民，里面有一些趣的提示来确保文档保持相关性和最新性。
弄一个清单
如果你的团队在可访问性方面不是很有经验，那么创建在添加新功能时可以参考的小清单可能是个好主意。举个例子，这是我为 Gorillas 编写的清单：
- 确保内容可读性、可理解性和结构化。文字不能太小，对比度要适量（并通过对比度标准）。副本应该有意义，即使用户可能不是母语人士（注意双关语、行话和习语），并且应该使用相关的文档大纲（语义元素、标题级别、部分等）进行适当的结构优化。
- 确保该功能在颜色失真的情况下看起来可用（可以使用各种浏览器扩展程序进行模拟，例如 NoCoffee 或 See），包括完全缺少颜色。颜色不应用作唯一的信息载体。
- 确保链接一目了然。链接可以通过辅助技术展示出来而不用依赖上下文，因此它们本身应该是有意义的。这对于使用屏幕阅读器的人进行有效导航很重要，并且可以使用此可访问性扩展进行测试。
- 确保对图片进行正确描述，如果它们不是装饰性图像。图像并不总是可见的，至少不是每个人都能看到。确认它们的关联描述，以便每个人都能理解它们。
- 确保所有表格均可操作。表单是用户与网站交互的主要方式之一，它们的使用方式因用户而异。确保无论用户和他们的设备如何，它们都可以有效地被操作和填充。这意味着具有悬停、活动、聚焦、禁用状态以及所有元素的正确标记。
- 当使用视频或音频作为内容的关键部分时，确保它有字幕并提供书面版本。不是每个人都可以或想要以听觉方式处理信息。
- 确保动画是适当的，不要闪来闪去。确保它们出现时时尊重用户的行为偏好，并提供一种禁用或暂停动画的方法。这里的风险范围从简单的头晕和偏头痛到癫痫发作。
请记住，这些只是为了确保一定程度的可访问性而提供的建议。然而，重要的是要走得更远，确保我们不仅符合WCAG 2.1 的 AA 标准，而且尽可能地适用于每个人。
自动化
可以自动化的就那么多。审查 HTML 和 CSS 的潜在缺陷是一个很好的起点，但它最后并不会取代一些精细的手动测试。尽管如此，它依旧可以成为一个很好的安全网，尤其是在 HTML 被抽象化的环境中（例如使用 JavaScript 框架）。
我建议集成ax来审查 DOM 以解决潜在的可访问性问题。它在开发环境中的集成非常简单，并且在开发时会在控制台中提供有用的提示。
如果你正在配置自动化测试（你可能应该这样做），你甚至可以将 ax 与 Cypress 集成。在 React 应用程序中，React 测试库鼓励在编写单元测试时采用面向可访问性的思维方式。
你可以在 A11y Advent Calendar 的中找到有关可访问性测试和工具的更多信息。
逻辑聚合
可访问性是一场持续的战斗。它永远不会结束，你和你的团队永远不会忽视它。为了避免重复地修改，基于组件的架构就显得相当重要了。
最终目标是创建可在整个应用程序中复用的可访问组件，确保从一开始就满足许多功能。就像你有一个集中的方式来处理翻译一样——你不会在每个组件中实现一个翻译器。
尝试依赖复杂组件的现有（轻量级和灵活）实现。对话框、脚注、选项卡和高级表单控件等界面可能很难正确构建，最好使用久经考验的解决方案，而不是冒着损害用户利益的风险推出自己的解决方案。
我在 A11y Advent Calendar 中对该主题进行了一些扩展，你还可以开始使用Smashing Magazine 上令人难以置信的可访问组件列表。
如果对于某些事情不太确定，你可以在 Twitter 上使用 #a11y 主题标签提问，或在web-a11y Slack 中提问。它需要邀请（因为 Slack）才能进去，但拥有数千名成员，并且是一个由无障碍爱好者和专家组成的充满活力的社区，你可以在那里获得信息和支持。
提高认知
可访问性是一个团队游戏。它不可能由一个人独自实现。每个人都必须一直参与。这就是为什么在组内提高对它的了解非常重要，暨此来让它成为一个常见话题。
进一步说，在面试过程中应该讨论（并评估）可访问性，尤其是对于工程师和设计师，还有 QA 工程师和产品负责人。实现这一目标是每个人的责任，而这种负担往往完全由开发人员承担。
看到这里应该让你可以开始了。花点时间从头开始构建好东西，你会在后面得到回报的。将可访问性视为工作的重要组成部分，而不是负担或其他人的责任。使你的界面可访问，然后进行大量测试，筛选后重复这一过程。它不需要完美，只要让每个人都能用就行。
