可访问性影响网站交付的各个层面——包括研究、用户体验（UX）、用户界面（UI）、内容、工程、质量保证、基础设施、运营和采购。这份指南以实用、以产品为导向的方式，介绍了 WCAG 2.1/2.2 AA，以便团队能够无需反复修改，就能交付包容性的体验。它可作为从发现、设计系统、组件模式、内容标准、媒体处理、键盘和屏幕阅读器支持、测试、部署以及持续监控的全流程参考。
1. 基础与心态
可访问性就是质量。WCAG 的四个核心原则——可感知性、可操作性、可理解性、健壮性——直接映射到产品风险：如果用户无法感知、操作或理解您的用户界面，那么转化率和信任度就会崩溃。将可访问性纳入“已完成/已完成”的定义中，而不是在发布后进行审计。从“仅仅通过审计”转变为“一个视力障碍用户是否可以使用屏幕阅读器和键盘完成结账？”或“一个弱视用户是否可以在阳光下阅读？”。
首选原生 HTML。 诸如按钮、输入框、下拉菜单、文本区域、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. 包含可访问性的组件
按钮和链接：用于操作的按钮，用于导航的链接。每个都需要清晰的文本、可见的焦点，以及禁用语义。避免低对比度的“幽灵”按钮。
Forms: every control gets a label tied with for/id; placeholders never replace labels. Use fieldset/legend for grouped controls (radio/checkbox sets). Provide inline help and clear error messages, surfaced both near the field and in a summary at the top with anchors back to errors. Preserve user input on validation failure. Mark required vs optional explicitly; avoid asterisks without explanation.
对话框和覆盖层： * 将焦点固定在对话框内部，设置 `aria-modal="true"`。 * 在关闭时，将焦点恢复到触发元素。 * 保持背景的可见性。 * 提供 Esc 键和显式关闭控件。 解释： 这段话描述了如何实现一个模态对话框或覆盖层，并强调了以下关键点： * `aria-modal="true"`: 这是一个 ARIA 属性，用于告诉屏幕阅读器该元素是一个模态对话框，应该被重点对待。 * 焦点管理: 在对话框打开时，焦点应该固定在对话框内部。 在关闭时，焦点应该恢复到触发该对话框的元素。 这对于用户体验至关重要，特别是对于使用辅助技术的用户。 * 背景保持可见: 在对话框关闭时，应该保持背景的可见性，避免用户感到困惑。 * Esc 键和显式关闭控件: 提供 Esc 键和显式关闭控件（例如一个 "关闭" 按钮）是标准的用户交互方式，方便用户关闭对话框。 总而言之，这段话强调了在实现模态对话框时，需要关注焦点管理、用户体验和标准交互方式。
导航：包括跳过链接、合适的标志（header/nav/main/aside/footer）、逻辑的标题顺序（一个表达目的的 H1 标题）、以及在整个网站上保持一致的标签。面包屑导航必须支持键盘和屏幕阅读器。对于巨型菜单，支持键盘方向键导航和按 Esc 键退出。
标签/展开面板：遵循 WAI-ARIA APG 模式——使用方向键进行切换，Home/End 键用于跳转，Space/Enter 键用于激活。 暴露 aria-selected/aria-controls，正确管理 tabIndex，并在 DOM 中保留面板，除非使用 aria-live 更新。
提示/弹窗：避免仅通过悬停触发；支持焦点和触摸。允许通过 Esc 键关闭，并提供足够的延迟时间。确保弹窗不会抢占焦点。
旋转式展示：提供暂停/停止功能，避免自动旋转速度过快，使用户难以阅读；确保控制按钮清晰易懂且尺寸足够大；尽可能保持内容在旋转式展示之外可见。对于关键信息，建议使用静态网格。
数据表格：使用 `
媒体播放器：支持完整的键盘控制、可清晰看到焦点、字幕、转录、可调节音量/播放速度，以及无自动播放带声音的功能。
5. 内容和媒体标准
替代文本：编写有目的的描述。装饰性图像的替代文本为空（`alt=""`）。用于表示状态的图标需要有可访问的名称。复杂的图表需要长描述或数据表格。
视频/音频：提供字幕（带有说话者标签）、文本稿以及在视觉内容有意义时，提供音频描述。对于网络连接较慢的情况，提供下载或低比特率的替代方案。
复制内容：使用简洁的语言、简短的句子，以及有意义的链接文本（避免使用“点击此处”）。采用标题和列表进行结构化。确保双语内容保持原意和清晰度——翻译替代文本、标题、表单标签和错误消息，而不仅仅是正文内容。
6. 运动模式、深色模式和主题
Respect 偏好：禁用视差效果、自动滚动或闪烁序列；提供简单的淡入淡出效果。避免内容每秒闪烁超过三次。对于深色模式，请使用设计标记、调整阴影/边框，并重新检查对比度；不要仅仅是反转颜色。确保在所有主题中，焦点状态仍然可见。
7. 性能和可靠性
以下是翻译： **性能是可访问性的一个重要方面。 优化核心 Web 指标，以减少认知负担。 避免因布局变化而导致焦点或控件移动的情况。 在使用大量 JavaScript 之前，优先加载关键 HTML。 逐步增强。 优雅地处理网络连接不稳定的情况，并提供清晰的提示信息。 确保表单在部分中断时仍能正常工作。
8. 测试计划
自动化：对 aria 的滥用进行 lint 检查，在关键模板上在 CI 中运行 axe/Lighthouse/Pa11y，并阻止关键违规合并。对自定义组件的焦点和键盘行为进行单元测试。
手册：仅使用键盘进行导航（不使用鼠标），屏幕阅读器扫描（NVDA+Chrome, VoiceOver+Safari），对比度检查，放大到200%，减少动画效果模式，深色模式测试，以及使用TalkBack和VoiceOver进行移动设备测试。 使用场景脚本（搜索、筛选、添加到购物车、支付）来发现实际应用中的问题。
用户测试：定期邀请使用辅助技术（如屏幕阅读器、开关设备、低视力设备）的用户参与测试。即使只有 5-8 名参与者，也能发现系统性问题。
9. 交付流程和治理
“已完成”的定义： 验收标准包括语义结构、焦点状态、标签、错误行为和对比。 “已完成”的定义： 自动化检查通过；针对该故事，已完成手动键盘和屏幕阅读器的测试。
设计交付包括标注的焦点状态、对比验证、ARIA 说明以及内容指导。代码审查强制执行语义 HTML 和焦点管理。质量保证将无障碍障碍视为关键流程的 P1 优先级。
设计系统：使用“Do/Don’t”示例、代码片段和键盘/ARIA要求，详细记录设计模式。在发布时，对版本组件进行版本控制，并运行回归测试以确保无障碍性。
所有权：指定一名负责人负责处理问题、跟踪指标并协调审计。每季度对设计师、工程师、项目经理、写作者和质量保证人员进行培训。
10. 监控、指标和分析
跟踪指标： 自动化审计得分、失败次数、键盘陷阱事件、ARIA-*验证错误、字幕/转录使用情况、使用辅助技术完成任务、错误恢复率以及相关支持工单。 监控日志，查找焦点异常和破坏导航的JS错误。 安排每季度一次的审计，以及在主要UI更改后进行突击检查。
11. 法律、风险和供应商管理
发布可访问性声明和反馈渠道。对于第三方组件（如聊天、分析和支付），要求提供 VPAT/ACR 证据，并自行进行测试。在合同中纳入修复服务水平协议 (SLA)。优先处理修复工作，以根据用户影响和法律风险进行排序。
12. 遗留UI的迁移策略
首先进行语义修复：标题、地标、标签、焦点顺序。将自定义控件替换为原生控件。为顶层媒体资产添加字幕/转录。逐步更新颜色标记，以满足对比度要求。用可访问的模式替换复杂的控件（日期选择器、下拉菜单）。
13. 移动和多模态
触摸目标：最小尺寸为 44x44 像素，并留有足够的间距。 确保触摸操作具有键盘快捷键。 支持设备旋转和动态字体，同时保持布局完整。 验证移动设备屏幕阅读器上的焦点顺序和提示信息。 提供可读且可操作的离线/错误状态。
14. 搜索引擎优化和内容运营
语义化 HTML、描述性标题、替代文本、快速性能和结构化数据，可以同时提高网站的可访问性和搜索引擎优化（SEO）。 培训内容编辑人员：强制使用替代文本、标题层级、有意义的链接和字幕政策。 添加 CMS 保护措施（例如：强制提供替代文本、对富文本进行对比检查、上传时提醒字幕）。
15. 变革管理与企业文化
庆祝取得的成果（例如，屏幕阅读器用户完成率的提高）。分享“前后”示例。组织午餐学习活动，维护一个设计规范库，并在入职培训中加入无障碍设计。建立无障碍问题升级流程，并表彰解决这些问题的贡献者。
总结：可访问性是一个持续改进的过程。 把它当作性能或安全一样来对待——进行监控、负责、迭代，这样每次发布都能让用户体验更接近“人人可用”。
16. 团队实用检查清单
设计检查清单：确认每个视图中只有一个 H1 标签；标题顺序合理；颜色搭配符合对比度要求；为所有交互状态定义了焦点样式；图标具有文本等效；动画模拟包括低动画效果版本；提供暗模式标记；组件注释包括键盘模式和 ARIA 映射。
内容检查清单：以下是翻译： * 每张图片都有替代文本（或装饰性空文本）；链接指向目标页面；标题和字幕已规划；表单包含清晰的说明和错误提示；语言简洁明了；双语版本保持原意和语境；表格数据包含摘要。
工程检查清单：以下是翻译： * 优先使用语义元素； tabindex 值不能大于 0；在 DOM 中尽早处理跳跃链接；存在 landmark；自定义控件应遵循 APG 规范；对话框具有焦点陷阱；关闭时恢复焦点；使用 aria-live 属性宣布状态消息；表单在出错时保留输入；避免重渲染时焦点丢失；避免滚动劫持。
测试检查清单：键盘仅限，完整流程测试；屏幕阅读器测试核心流程；对比测试通过；放大200%不影响功能；减少动画效果验证；深色模式验证；移动设备上的TalkBack/VoiceOver测试通过；针对关键问题的Axe/Lighthouse/Pa11y检查。
17. 避免使用的模式
- 使用占位符作为标签的形式（会丢失上下文，破坏自动填充/屏幕阅读器功能）。
- 缺少 `href` 属性的 `` 标签，请使用 `
18. 包含注释的示例流程
使用电子邮件验证注册：以下是翻译： * 对每个字段进行标签，并提供密码可见性切换功能，使用 aria-pressed 属性。 * 在输入密码之前，显示密码规则。 * 在行内和总结中，及时通知错误。 * 防止超时。 * 确保验证状态使用 aria-live 属性，以提供友好的提示。
搜索和筛选：确保搜索功能包含标签和提交按钮；筛选器使用复选框/单选按钮，并使用字段集/标题；显示结果数量；提供清晰的重置按钮。对于动态结果，在不失去焦点的情况下更新 aria-live 区域；在切换筛选器时，保持焦点。
结账：breadcrumb for steps, progress indicator with text, shipping/billing forms labeled, saved addresses selectable via radio, payment iframes from gateways tested for focus and labels, confirmation screen readable with order details in plain text. Avoid forcing CAPTCHAs; if unavoidable, provide accessible alternatives.
支持聊天：供应商要求： * 确保聊天启动器具有可聚焦、可标记的特性，并且在打开时不会抢占焦点。 * 在聊天界面中，确保消息历史记录可供屏幕阅读器读取，输入框具有标签，并且通知使用 aria-live 属性，但避免过度使用。
19. 国际化与本地化细微差别
制定替代字体方案，充分覆盖越南语的特殊符号；在 Windows 和 Android 上测试字体渲染效果。 调整示例、货币、地址格式和日期/时间选择器，以适应本地化设置。 提供带有 `lang` 属性的语言切换功能，并提供有意义的标签文本。 如果将来添加右向阅读的本地化设置，请尊重阅读方向。
20. 建立无障碍开发待办事项清单
进行初步审计，根据严重程度和流程对问题进行分类，并优先处理 P1（阻塞）问题，例如：缺少标签、键盘陷阱、对比度问题、焦点失效、缺少字幕。P2 涵盖可用性问题（如：指令不明确、目标尺寸不足）。P3 涵盖优化工作（如：aria-label 调整、实时区域调优）。跟踪负责人、截止日期和回归说明。
21. 确保高层管理人员和利益相关者之间的协调一致。
以下是将英文翻译成商务语言： 通过提升无障碍性，实现以下商业效益： * 降低法律风险： 确保符合相关法规，避免潜在的法律纠纷。 * 提高转化率： 扩大用户群体，提升网站或产品的用户体验，从而提高转化率。 * 降低支持成本： 减少因无障碍问题导致的客户投诉和支持需求。 * 拓展目标市场： 触达庞大的残疾人市场（约占总人口的 1/5），实现更大的市场份额。 * 提升 SEO 效果： 优化网站结构，提高在搜索引擎中的排名。 * 提升品牌声誉： 展现企业对社会责任的承诺，提升品牌形象。 展示竞争对手的无障碍性实践情况。 确保预算用于无障碍性相关的活动： * 审计： 评估现有网站或产品的无障碍性情况。 * 工具： 采用无障碍性测试和修复工具。 * 培训： 培训相关人员，提高无障碍性意识和技能。 * 修复： 修复网站或产品中的无障碍性问题。 总结: 这段话强调了通过提升无障碍性，企业可以从多个方面获得商业利益，包括降低风险、提高转化率、降低成本、拓展市场、提升品牌形象等。 同时，也强调了需要投入预算来支持无障碍性相关的活动，例如审计、工具、培训和修复。
22. 推荐的开发工具堆栈
- 设计：Figma 插件，用于对比和标注；包含对比功能的标记库。
- 代码：eslint-plugin-jsx-a11y、stylelint 的无障碍性规则、storybook+a11y 插件、以及使用无障碍查询的 testing-library。
- 自动化：axe-core 在单元/集成测试中，Lighthouse CI 预算，以及 Pa11y 用于回归测试。
- 手动辅助：颜色对比分析器、NVDA/VoiceOver 屏幕阅读器、焦点指示器浏览器扩展、用于放大测试的响应式设计。
- 内容：CMS 系统对替代文本和标题顺序的验证，以及上传媒体时提醒功能。
23. 分阶段实施
第一阶段：修复关键路径上的问题（导航、搜索、账户、结账），并更新颜色主题。 第二阶段：重构设计系统中的共享组件，并进行推广。 第三阶段：对长尾模板（博客、帮助中心、仪表盘）进行深入审计。 第四阶段：建立监控和定期用户测试。沟通里程碑，发布补丁说明，并邀请依赖辅助技术的用户的反馈。
24. 衡量结果
除了审计分数，还应跟踪键盘或屏幕阅读器用户（通过尊重、聚合的信号，如焦点/ARIA的使用）的转化率、完成时间、在表单步骤中的放弃率，以及每发布版本关闭的可访问性问题数量的比例。 突出展示改进案例——例如：“屏幕阅读器结账完成率从62%提高到88%。”
通过建立规范、加强管理并进行持续测试，可访问性将成为一种可重复利用的能力，而不再仅仅是产品发布前的临时措施。
25. 案例研究蓝图和维护节奏
蓝图：选择一个旗舰项目（例如，课程注册、贷款申请）。进行基准审计，制定包含所有责任人和截止日期的修复计划，首先对设计系统中的组件进行重构，然后再应用模板。将每次代码更改与测试配对：使用 Storybook 进行无障碍检查、键盘导航和屏幕阅读器脚本。发布包含指标的“前后对比”总结，以分享影响。
节奏：每季度进行全面的审计，每月对新发布的进行抽查，每周将CI报告发送到Slack，并定期与设计、工程和产品团队进行 backlog 的整理工作。同时，维护一份“已知问题”文档，其中包含缓解措施和目标修复日期。
26. 合作与交接仪式
在需求整理阶段，标记所有与交互性UI相关的需求，以便进行无障碍（a11y）方面的合作。在设计评审中，专门安排时间讨论对比度、焦点、动画和文本清晰度等问题。在工程启动会议上，审查键盘/ARIA相关笔记和测试脚本。在质量保证（QA）确认阶段，要求提供无障碍证据（例如焦点截图、审计日志）。
鼓励 QA 团队和设计师在测试环境中，利用屏幕阅读器进行联合测试；为每个功能点安排 30 分钟的测试时间。轮流让团队成员担任“冲刺期间的可访问性专家”，以推广专业知识。
27. 紧急应对方案
如果在使用前发现存在问题（例如：缺少标签、焦点问题、对比度不足），请采取以下措施进行临时修复：添加临时可见的文本标签、插入跳过链接、禁用自动播放、通过 CSS 覆盖来增加对比度，或提供替代静态内容。详细记录修复方案，并安排永久修复，以避免产生潜在的债务。
记住：修复那些能恢复系统正常运行的小而快速的错误，比发布一个完全阻止功能的解决方案更好。但是，请务必跟踪这些错误，以免它们长期存在。
通过建立健全的流程，您可以确保发布按计划进行，同时也能满足“每个人都可以使用”的承诺。
28. 保持势头
确保可访问性可见：在发布说明、仪表盘和冲刺评审中包含可访问性状态。定期举办“午餐演示”，让工程师和设计师展示对真实用户产生实际影响的修复方案。邀请客户支持团队收集辅助技术用户反馈的常见问题。在您的代码库中，始终保持一份简短的“可访问性指南”，以便新员工快速上手。
最后，建议每年设置一次预算，用于重构债务。随着框架、浏览器和 WCAG 的不断发展，定期回顾设计模式，特别是自定义组件，以确保它们仍然符合预期。持续关注可以防止出现问题，并证明包容性设计是一种永久性的产品原则，而不是一次性的项目。
29. 新项目快速启动指南
启动阶段： 将 WCAG AA 作为不可协商的要求，并选择 3 个关键的用户流程作为基准。 设计阶段： 使用系统标记，对键盘/ARIA 进行标注，并在早期验证对比度。 开发阶段： 首先使用语义 HTML，仅在需要时添加 ARIA，并编写焦点和键盘流程的测试。 测试阶段： 针对每个用户故事，进行键盘 + 屏幕阅读器的测试，在 CI 中自动化运行 Axe/Lighthouse，并监控回归问题。 发布阶段： 发布可访问性声明和反馈渠道。 发布后阶段： 监控日志、支持工单，并每月重新进行审计。
将此作为您在每个迭代周期中回顾的检查清单。 在模式、培训和审计方面的少量投资，将为您带来更少的障碍、更快的交付、更满意的用户以及更强大的搜索性能。 包容性的体验，本质上就是更好的体验。
持续前进，不断测量，并将无障碍设计融入日常，而不是将其视为一项挑战。
每个版本都应该让体验更加包容。
