无障碍性触及网站交付的每个层面——研究、用户体验、用户界面、文案、工程、质量保证、基础设施、运营和采购。本手册以实用、以产品为中心的方式讲解 WCAG 2.1/2.2 AA，以便团队能够交付包容性体验，而无需无休止的返工。将其用作发现、设计系统、组件模式、内容标准、媒体处理、键盘和屏幕阅读器支持、测试、发布和持续监控的端到端参考。
1. 基础与思维模式
无障碍性即质量。WCAG 的四大支柱——可感知、可操作、可理解、健壮——直接映射到产品风险：如果用户无法感知、操作或理解您的用户界面，转化率和信任度就会崩溃。将无障碍性作为“准备就绪/完成”定义的一部分，而不是发布后的审计。从“仅仅通过审计”转变为“盲人用户能否仅使用屏幕阅读器和键盘完成结账？”或“低视力用户能否在明亮的阳光下阅读此内容？”
优先使用原生 HTML。像 button、input、select、textarea、details/summary 和语义化标题等元素已经暴露了角色、状态和键盘行为。仅在填补空白时使用 ARIA，切勿覆盖原生语义。保持 DOM 顺序与视觉顺序一致；避免仅通过 CSS 重新排序导致焦点混乱。
2. 发现与需求
在发现访谈中纳入残障人士。绘制关键旅程——搜索、导航、身份验证、结账、账户管理——并记录观察到的障碍（自动播放的轮播、焦点缺失、模糊的错误消息）。定义成功指标：使用 NVDA/VoiceOver 完成任务、表单错误恢复时间、字幕使用率、对比度通过率、辅助技术用户的流失率、标记为无障碍性的支持工单。
捕获非功能性需求：WCAG 2.1 AA（以及 2.2 焦点可见性更新）、仅键盘操作性、屏幕阅读器支持（NVDA、JAWS、VoiceOver）、高对比度主题、减少动画、暗模式影响、双语需求以及法律背景（ADA 式义务、采购标准、行业法规）。将它们融入用户故事和验收标准中。
3. 颜色、字体和布局令牌
定义内置对比度的颜色令牌：正文文本目标为 4.5:1，大文本和 UI 控件目标为 3:1。为背景、表面、边框、交互状态（悬停、活动、焦点、禁用）和警报（信息/成功/警告/错误）提供单独的令牌。切勿仅依赖颜色——应与图标或文本搭配使用。
排版：建立清晰的层级结构，具有一致的比例，每行 45-75 个字符，行高约 1.5，足够的字距/段落间距，以及强大的越南语字形支持。提供备用字体堆栈。确保字体粗细选择在小尺寸下不会变细。
间距和网格：使用支持宽裕触摸目标（最小 44x44 像素）的间距令牌，避免控件拥挤，并防止文本放大到 200% 时重叠。
4. 附带无障碍性的组件
按钮和链接：按钮用于操作，链接用于导航。每个都需要可辨别的文本、可见的焦点和禁用语义。避免使用低对比度的幽灵按钮。
表单：每个控件都应有一个通过 for/id 关联的标签；占位符绝不能替代标签。对分组控件（单选/复选框组）使用 fieldset/legend。提供内联帮助和清晰的错误消息，既显示在字段附近，也显示在顶部的摘要中，并带有指向错误的锚点。在验证失败时保留用户输入。明确标记必填项和可选项；避免使用没有解释的星号。
对话框和覆盖层：将焦点限制在内部，设置 aria-modal="true"，关闭时将焦点恢复到触发器，并使背景失效。提供 Esc 键和明确的关闭控件。
导航：包括跳过链接、适当的地标（header/nav/main/aside/footer）、逻辑标题顺序（表达目的的单个 H1）以及全站一致的标签。面包屑必须对键盘和屏幕阅读器友好。对于大型菜单，支持键盘箭头导航和 Esc 键退出。
选项卡/手风琴：遵循 WAI-ARIA APG 模式——使用箭头键移动，Home/End 键跳转，Space/Enter 键激活。暴露 aria-selected/aria-controls，正确管理 tabIndex，并为屏幕阅读器将面板保留在 DOM 中，除非使用 aria-live 更新。
工具提示/吐司：避免仅悬停触发；支持焦点和触摸。允许使用 Esc 键关闭并提供足够的显示时间。确保吐司不会窃取焦点。
轮播：提供暂停/停止功能，避免自动旋转速度快于用户阅读速度，确保控件有标签且足够大，并尽可能在轮播外部提供内容。对于关键信息，优先使用静态网格。
数据表：对复杂数据使用带 scope 的 th、标题、摘要，并对可排序的表头使用 aria-sort。保持响应性，同时不向辅助技术隐藏表头。
媒体播放器：完整的键盘控制、可见焦点、字幕、文字稿、可调节音量/速度，以及无声自动播放。
5. 内容和媒体标准
替代文本：编写有目的的描述。装饰性图片使用空的 alt=""。传达状态的图标需要可访问的名称。复杂的图表需要长描述或数据表。
视频/音频：提供字幕（带说话人标签）、文字稿和音频描述，以传达视觉信息。为慢速连接提供下载或低比特率替代方案。
文案：使用简洁的语言、短句和有意义的链接文本（避免“点击此处”）。使用标题和列表进行结构化。确保双语内容保持意义和清晰度——翻译替代文本、字幕、表单标签和错误消息，而不仅仅是正文内容。
6. 动画、暗模式和主题
尊重 prefers-reduced-motion：禁用视差、自动滚动或闪烁序列；改为提供简单的淡入淡出效果。避免内容每秒闪烁超过三次。对于暗模式，使用设计令牌，调整阴影/边框，并重新检查对比度；不要仅仅反转颜色。确保焦点状态在所有主题中都保持可见。
7. 性能与可靠性
性能是无障碍性的一项特性。优化核心网络指标以减少认知负荷。避免移动焦点或控件的布局偏移。在加载大量 JS 之前流式传输关键 HTML；渐进增强。通过清晰的消息传递优雅地处理不良连接。使表单能够抵御部分中断。
8. 测试计划
自动化：对 aria 滥用进行 lint 检查，在 CI 中对关键模板运行 axe/Lighthouse/Pa11y，并阻止关键违规的合并。对自定义小部件的焦点和键盘行为进行单元测试。
手动：仅键盘遍历（无鼠标）、屏幕阅读器扫描（NVDA+Chrome、VoiceOver+Safari）、对比度检查、放大到 200%、减少动画模式、暗模式通过以及使用 TalkBack 和 VoiceOver 进行移动测试。使用场景脚本（搜索、筛选、添加到购物车、支付）来捕获实际障碍。
用户测试：定期与辅助技术用户（屏幕阅读器、切换设备、低视力）进行会话。即使是 5-8 名参与者也能发现系统性问题。
9. 交付工作流与治理
准备就绪定义：验收标准包括语义结构、焦点状态、标签、错误行为和对比度。完成定义：自动化检查通过；为该故事完成手动键盘和屏幕阅读器冒烟测试。
设计交付包括带注释的焦点状态、对比度证明、ARIA 注释和内容指南。代码审查强制执行语义 HTML 和焦点管理。质量保证将无障碍性障碍视为关键流程的 P1 优先级。
设计系统：使用“应做/不应做”示例、代码片段和键盘/ARIA 要求记录模式。版本化组件并在发布时运行回归无障碍性测试。
所有权：指派一名无障碍性负责人来分类问题、跟踪指标并协调审计。每季度培训设计师、工程师、产品经理、文案和质量保证人员。
10. 监控、指标和分析
跟踪：自动化审计分数、对比度失败次数、键盘陷阱事件、aria-* 验证错误、字幕/文字稿使用情况、辅助技术任务完成情况、错误恢复率以及相关的支持工单。监控日志中的焦点异常和导致导航中断的 JS 错误。安排季度审计以及在重大 UI 更改后进行抽查。
11. 法律、风险和供应商管理
发布无障碍性声明和反馈渠道。对于第三方小部件（聊天、分析、支付），要求提供 VPAT/ACR 证据并自行测试。将修复 SLA 纳入合同。根据用户影响和法律风险优先进行修复。
12. 遗留 UI 迁移策略
从语义修复开始：标题、地标、标签、焦点顺序。将自定义控件替换为原生等效项。为顶级媒体资产添加字幕/文字稿。逐步更新颜色令牌以达到对比度目标。用无障碍模式替换复杂的小部件（日期选择器、下拉菜单）。
13. 移动和多模态
触摸目标：最小 44x44 像素，并有足够的间距。确保手势有键盘等效项。支持设备旋转和动态类型而不破坏布局。验证移动屏幕阅读器上的焦点顺序和公告。提供可读和可操作的离线/错误状态。
14. SEO 和内容运营
语义化 HTML、描述性标题、替代文本、快速性能和结构化数据既能改善无障碍性，也能改善 SEO。培训内容编辑：强制执行替代文本、标题层级、有意义的链接和字幕策略。添加 CMS 护栏（必需的替代文本、富文本的对比度检查、上传时的字幕提醒）。
15. 变更管理与文化
庆祝成功（例如，屏幕阅读器用户的完成率提高）。分享前后对比示例。举办午餐学习会，维护模式库，并将无障碍性纳入入职培训。为无障碍性问题创建升级路径，并表彰解决问题的贡献者。
底线：无障碍性是持续改进。像对待性能或安全性一样对待它——进行监控、负责并迭代——这样每次发布都能使体验更接近“人人可用”。
16. 团队实用清单
设计清单：确认每个视图一个 H1；标题顺序逻辑；颜色对满足对比度；为所有交互状态定义焦点样式；图标有文本等效项；动画模型包括减少动画变体；暗模式令牌可用；组件注释包括键盘模式和 ARIA 映射。
内容清单：每张图片都有 alt（或装饰性空白）；链接描述目的地；媒体计划有字幕和文字稿；表单有清晰的说明和错误语言；语气保持简洁明了；双语文案保留意义和上下文；表格数据有摘要。
工程清单：语义元素优先；tabindex 不大于 0；DOM 中尽早放置跳过链接；地标存在；自定义控件遵循 APG；对话框的焦点陷阱；关闭时恢复焦点；使用 aria-live 宣布状态消息；表单在错误时保留输入；防止重新渲染时焦点丢失；避免滚动劫持。
测试清单：键盘端到端通过；核心流程的屏幕阅读器冒烟测试；对比度通过；放大 200% 不损失功能；减少动画验证；暗模式验证；移动 TalkBack/VoiceOver 通过；axe/Lighthouse/Pa11y 清除阻碍性问题。
17. 应避免的模式
- 将占位符用作标签的表单（丢失上下文，破坏自动填充/屏幕阅读器）。
- 没有 href 的锚标签（应使用按钮）。
- 带有点击处理程序但没有角色或键盘支持的 Div/span 控件。
- 没有暂停功能的自动前进轮播。
- 丢失焦点的模态堆栈。
- 过度使用 aria-hidden 隐藏可见的交互内容。
- 仅依赖颜色的验证（应添加文本/图标）。
- 没有地标、分页或“加载更多”的无限滚动。
- 重新构建得很差的自定义下拉菜单，而不是使用原生 select 或经过验证的模式。
18. 带有注释的示例流程
带电子邮件验证的注册：标记每个字段，提供带 aria-pressed 的密码可见性切换，在输入前显示密码规则，内联和摘要中宣布错误，防止超时，确保验证状态使用 aria-live polite。
搜索和筛选：确保搜索有标签和提交按钮；筛选器使用带 fieldset/legend 的复选框/单选按钮；宣布结果数量；提供清晰的重置。对于动态结果，更新 aria-live 区域而不窃取焦点；在切换筛选器时保留焦点。
结账：步骤面包屑，带文本的进度指示器，标记的配送/账单表单，通过单选按钮选择已保存的地址，测试来自网关的支付 iframe 的焦点和标签，确认屏幕可读，订单详情以纯文本显示。避免强制使用 CAPTCHA；如果不可避免，提供无障碍替代方案。
支持聊天：审查供应商；确保聊天启动器可聚焦、有标签，并且在打开时不会劫持焦点。在聊天内部，确保消息历史记录可被屏幕阅读器读取，输入框有标签，并且通知使用 aria-live 而不滥发。
19. 国际化和区域差异
规划完全覆盖越南语变音符号的备用字体；测试 Windows 和 Android 上的字体粗细渲染。根据区域设置调整示例、货币、地址格式和日期/时间选择器。提供带有 html 上的 lang 属性和有意义标签文本的语言切换。如果以后添加 RTL 区域设置，请尊重阅读方向。
20. 建立无障碍性待办事项
进行初步审计，按严重性和流程标记问题，并优先处理 P1（阻碍性）项目以用于即时冲刺：缺失标签、键盘陷阱、对比度失败、焦点中断、缺失字幕。P2 涵盖可用性摩擦（不清晰的说明、目标尺寸不足）。P3 涵盖优化（aria-label 改进、live-region 调整）。跟踪负责人、截止日期和回归说明。
21. 高管和利益相关者协调
将无障碍性转化为商业语言：降低法律风险、提高转化率、降低支持成本、扩大可触达市场（五分之一的人口有残障）、提升 SEO 和品牌声誉。展示竞争对手的无障碍性状况基准。为审计、工具、培训和修复争取预算。
22. 工具栈推荐
- 设计：用于对比度和注释的 Figma 插件；内置对比度的令牌库。
- 代码：eslint-plugin-jsx-a11y、stylelint a11y 规则、storybook+a11y 附加组件、带有可访问查询的 testing-library。
- 自动化：单元/集成测试中的 axe-core、Lighthouse CI 预算、用于回归扫描的 Pa11y。
- 手动辅助：颜色对比度分析器、NVDA/VoiceOver 屏幕阅读器、焦点指示器浏览器扩展、用于缩放测试的 Responsively。
- 内容：CMS 对替代文本和标题顺序的验证、媒体上传时的字幕提醒。
23. 分阶段推出
阶段 1：修复主要旅程（导航、搜索、账户、结账）上的障碍，并更新颜色令牌。阶段 2：重构设计系统中的共享组件并推广。阶段 3：对长尾模板（博客、帮助中心、仪表板）进行深入审计。阶段 4：建立监控和定期用户测试。沟通里程碑，发布补丁说明，并邀请依赖辅助技术的用户提供反馈。
24. 衡量成果
除了审计分数，还要跟踪依赖键盘或屏幕阅读器的用户的转化率（通过焦点/ARIA 使用等尊重的、聚合的信号）、完成时间、表单步骤的放弃率以及每个版本关闭的无障碍性工单比例。庆祝提升的故事——例如，“屏幕阅读器结账完成率从 62% 提高到 88%。”
通过严谨的模式、强大的治理和持续的测试，无障碍性成为一种可重复的能力——而不是发布前的紧急演练。
25. 案例研究蓝图和维护节奏
蓝图：选择一个旗舰旅程（例如，课程注册、贷款申请）。运行基线审计，编写包含负责人和截止日期的修复计划，首先重构设计系统中的组件，然后改造模板。将每个代码更改与测试配对：Storybook 无障碍性检查、键盘演练和屏幕阅读器脚本。发布带有指标的对比摘要，以宣传影响。
节奏：季度全面审计，每月对新版本进行抽查，每周向 Slack 发送 CI 报告，以及与设计、工程和产品团队进行滚动待办事项梳理会议。维护一份包含缓解措施和目标修复日期的“已知问题”实时文档。
26. 协作与交接仪式
在待办事项梳理中，标记涉及交互密集型 UI 的故事以进行无障碍性配对。在设计评审中，预留明确时间用于对比度、焦点、动画和文案清晰度。在工程启动时，审查键盘/ARIA 注释和测试脚本。在质量保证签核时，要求提供无障碍性证据（焦点截图、审计日志）。
鼓励质量保证人员和设计师在预发布环境中使用屏幕阅读器进行配对测试；为每个史诗级任务安排 30 分钟的会话。让团队成员轮流担任“冲刺无障碍性冠军”以传播专业知识。
27. 紧急模式
如果在发布前发现阻碍性问题——例如标签缺失、焦点中断、对比度不可读——请采取战术性缓解措施：添加临时可见文本标签、插入跳过链接、禁用自动播放、通过 CSS 覆盖增加颜色对比度，或提供替代的静态内容。记录补丁并安排永久修复，以避免累积隐藏的技术债务。
请记住：小而快的修复，恢复可操作性，胜过发布一个阻碍性问题。但是，要跟踪它们，以免它们长期存在。
通过健壮的流程，您可以在按时发布的同时，兑现“人人可用”的承诺。
28. 保持势头
保持无障碍性的可见性：在发布说明、仪表板和冲刺评审中包含无障碍性状态。每季度举办一次“午餐学习”演示，工程师和设计师展示对用户产生实际影响的修复。邀请客户支持部门提出辅助技术用户反复遇到的痛点。在您的代码库中置顶一份简短的“无障碍性护栏”文档，以便新员工快速上手。
最后，每季度为重构技术债务预留时间。随着框架、浏览器和 WCAG 的发展，重新审视模式——特别是自定义小部件——以确保它们仍然符合预期。持续的关注可以防止回归，并证明包容性设计是一个永久的产品原则，而不是一次性项目。
29. 新项目快速手册
启动：将 WCAG AA 设为不可协商的要求，并选择 3 个主要用户旅程进行基准测试。设计：使用系统令牌，注释键盘/ARIA，尽早验证对比度。构建：从语义化 HTML 开始，仅在需要时添加 ARIA，为焦点和键盘流程编写测试。测试：为每个故事运行键盘 + 屏幕阅读器通过测试，在 CI 中自动化 axe/Lighthouse，并观察回归。发布：发布无障碍性声明和反馈渠道。发布后：监控日志、支持工单，并每月重新运行审计。
将其作为您每个冲刺都会回顾的清单。在模式、培训和审计方面的小额投资，将带来更少的障碍、更快的交付、更满意的用户和更强的搜索性能。包容性体验就是更好的体验。
持续前进，不懈衡量，让无障碍性成为一种习惯，而不是障碍。
每一次发布都应使体验比上一次更具包容性。
