为什么无障碍设施如此重要
无障碍设计是一项基本职责，而非次要考虑因素。每个人都应该能够使用您的应用，包括那些行动不便的人。包容性设计确保了用户能够平等地使用您的产品，无论他们是否有视力障碍、行动障碍或认知障碍。
在许多国家，无障碍设施也是一项法律要求（例如美国的 ADA、欧洲的 EN 301 549）。
a11y React 开发者最佳实践
1. 使用语义HTML
- 偏好本土元素
- 避免使用 div 进行交互式 UI — 屏幕阅读器会跳过它们
2. 确保键盘导航性
- 每个交互元素都应该可以通过 Tab 和 Enter 访问和操作
- 慎重使用 tabindex （避免 tabindex="0" 过载）
3. 需要时添加 ARIA 属性
- 使用 aria-label、aria-hidden、aria-live 为屏幕阅读器提供上下文
- 但是当语义 HTML 可以完成工作时，不要过度使用 ARIA
4. 为图片提供替代文本
- 对重要图片使用有意义的 alt=""
- 使用 alt="" 来隐藏装饰性的
5. 颜色对比度和焦点指示器
- 确保文本具有高对比度（根据 WCAG AA/AAA 检查）
- 不要删除焦点轮廓——如果需要，可以自定义它们
6. 表单错误处理
- 使用 aria-scribeby 链接表单错误
- 在模糊或提交时进行验证，而不仅仅是在更改时
确保年度合规性的工具
- axe DevTools（Chrome 扩展程序）——实时分析 WCAG 违规行为
- eslint-plugin-jsx-a11y — 查找缺失的角色、替代文本、标签陷阱
- Lighthouse (Chrome/CI) — 审核中的 a11y 评分
- 屏幕阅读器：NVDA（Windows）、VoiceOver（macOS）、ChromeVox
现实世界的可访问性审计技巧
- 仅使用键盘即可导航整个应用程序
- 使用屏幕阅读器浏览常见流程
- 使用 contrast-ratio.com 等工具测试颜色对比度
- 避免可能引发运动障碍的动画（尊重
prefers-reduced-motion）
编写可测试的无障碍代码
- 使用自动化测试框架（如 Jest + Testing Library）确保交互元素的可访问性
- 示例：
getByRole('button', { name: /提交/i })能验证按钮是否具备正确语义 - 利用
axe-core集成到测试流程中，防止无障碍回归
组件库与设计系统中的无障碍策略
- 选择已通过 WCAG 检测的组件库（如 Reach UI、Radix UI）
- 在设计阶段加入辅助功能审核，比如组件状态下的焦点样式、键盘操作流
- 定义通用的 a11y 设计 token，例如：焦点边框、aria 属性规范、alt 文案策略
团队协作与文化建设
- 将无障碍视为团队代码评审中的一部分，而不是事后补救
- 对设计师、开发者、测试人员进行基础的无障碍培训
- 分享无障碍提升成果（如 Lighthouse 分数、用户正反馈），增强团队使命感
最终要点：以人为本，确保代码面向未来
Web 应该属于所有人
作为开发者，我们的代码承载着一种责任——让技术成为助力，而非障碍。
从一个有意义的 alt 文案，到为按钮保留焦点样式，哪怕是一个小小的调整，也可能极大改善一位用户的体验。
别等需求单提出来才去优化无障碍。把 a11y 当作质量保障的一部分，你做出的产品会更稳定、更持久，也更被信任。
