数字无障碍用户体验 - 小型团队完整指南

数字无障碍通常看起来像是一项“成人运动”。当我们了解 WCAG（网页内容可访问性指南）及其数十个成功标准（A、AA 和 AAA 级）时，小团队很容易感到不知所措。

“我们只有 3 名开发人员和 1 名设计师。我们如何能够提供新功能、修复错误并仍然处理所有这些 [辅助功能12?？”

好消息是：您不必一次完成所有事情。对于小型团队来说，[无障碍13]的关键不是立即完美，而是持续进步和智能集成到工作流程中。

在本指南中，我们将展示精益团队如何实现省力、高影响力的可访问性。

可访问性中的帕累托原则 (80/20)

对于小团队来说，尝试实现 100% WCAG 合规性可能会阻碍开发。相反，专注于解决 80% 用户问题的 20% 修复。

1. 正确的低对比度

这是网络上最常见的错误（根据 WebAIM，存在于 83% 的主页上）。

• 快速操作：检查您的调色板。文本与背景的对比度必须至少为 4.5:1。
• 影响：帮助视力低下、色盲的人和在强烈阳光下使用手机的人。

2. 图像中的替代文本（Alt Text）

• 快速操作：在代码 linter 中安装一条规则（如 React/Vue 的 ESLint），该规则要求所有 1 标签上都有 0 属性。
• 影响：让盲人能够理解图像的内容并提高他们在 Google 图片上的 SEO。

3. 表单上的标签（标签）

对于屏幕阅读器来说，未标记的输入是一个谜。

• 快速操作：确保每个2都有一个关联的3（使用45）。
• 影响：对于任何用户导航和完成注册、登录和结账都至关重要。

4. 标题结构

• 快速行动：不要跳过级别。该页面应该有 6，然后是7，然后是8。不要仅仅因为您希望文本更小而使用 9；为此使用CSS。
• 影响：屏幕阅读器用户通过从一个标题跳转到另一个标题进行导航，以了解页面的结构。

适合小型团队的敏捷工作流程

不要创建单独的“辅助功能冲刺”。这使得 [accessibility15] 看起来像是额外的东西。融入日常生活。

设计中（编码之前）

设计师是守门员。它可以防止错误到达代码。

• 使用 Figma/Sketch/Adobe XD 中的插件来模拟色盲并检查对比度。
• 定义交付给开发人员的屏幕上的焦点顺序（Tab 顺序）。

开发中（代码期间）

• Linting：自动化。使用像 10（用于 React）这样的插件。如果您忘记替代文本或使按钮无法访问，它会实时通知您。计算机完成钻孔检查工作。
• 可重复使用的组件：不要固定 50 个按钮，而是创建一个可访问的 11 组件并在任何地方使用它。修复一次，修复各处。

没有代码审查

向 Pull Request 模板添加一个简单的问题：

• 您测试过键盘导航吗？ 这迫使开发人员花费 30 秒在没有鼠标的情况下测试该功能。

“节省时间”的工具

小团队需要效率。使用可以完成繁重工作的工具。

1. axe DevTools（浏览器扩展）：允许您扫描页面并自动查找错误。免费版本已经很优秀了。
2. Lighthouse CI：配置为每次部署时自动运行。如果[辅助功能16分]下降太多，你就知道出现了问题。
3. 可访问的 UI 库：如果可能，请不要重新创建轮子。使用默认情况下已可访问的组件库，例如 Radix UI、Chakra UI 或 Material UI。他们已经为您处理了菜单、模式和选项卡的复杂性。

向团队传播福音（文化）

在小团队中，沟通更容易。享受这个。

• 模拟：在团队会议中，尝试蒙住眼睛使用您的产品，仅使用手机屏幕阅读器（VoiceOver/TalkBack）。挫折的经历往往是改正的强大动力。
• 庆祝小胜利：“今天我们将 Lighthouse 得分从 60 提高到 85。”这可以保持士气高昂。

＃＃ 结论

不要让完美主义成为善良的敌人。一个持续解决[可访问性17]问题的小团队比一个因为“没有能力完成所有事情”而忽略问题的团队要好得多。

从基础开始。尽可能自动化。养成习惯。可访问性并不在于拥有一个庞大的团队；而是在于拥有一个庞大的团队。这是关于同理心和技术纪律。您的代码变得更好，您的产品变得更好，您的用户会感谢您。

另请阅读

• [数字辅助用户体验 - 扩展完整指南18
• [数字无障碍用户体验 - 初创公司完整指南19
• [网页辅助功能（A11y）：开发人员实用指南20
• [移动应用程序中的辅助功能 - 带示例的完整指南21
• [移动应用程序的辅助功能 - 完整的实践指南22
• 【移动应用无障碍-日常生活完全指南23