通过《欧洲无障碍法》和协调标准EN 301 549，WCAG 2.2现已成为欧盟的实际AA目标；即使法规仍引用2.1版本，它也是美国法院衡量ADA涵盖网站的实际基准。该标准文档完善；从”我们知道需要合规”到”我们拥有可信的合规姿态”的路径却并不清晰。本指南就是这条路径，分六个步骤，按团队应实际执行的顺序排列。

WCAG 2.2是W3C于2023年10月作为正式推荐标准发布的《网页内容无障碍指南》的当前版本。它定义了86条成功标准，按四项原则组织——内容必须是可感知的、可操作的、可理解的和健壮的。每条标准被赋予一个合规级别。A级是最低门槛；AA级是每个主要监管机构引用的实际基准；AAA级是理想目标，在任何地方都不是监管底线。

当监管机构或合同要求”符合WCAG 2.2 AA”时，其含义不仅仅是某一页面通过测试。W3C的合规定义要求整个合规单元——页面或构成流程的一组页面——满足每条A级和AA级标准，任何流程从头到尾都可访问，且辅助技术无需关闭内容才能正常运行。一个大多数页面满足大多数标准的网站并不符合要求；门槛是全面覆盖。

WCAG 2.2在2.1基础上新增了九条标准——焦点外观、目标尺寸、拖拽操作、冗余输入、无障碍身份验证、一致帮助等。原本符合2.1 AA标准的网站不会自动符合2.2 AA标准；新标准正是差距所在。逐条标准的权威来源在我们的WCAG 2.2成功标准完整参考中。

合规是一种姿态，而非一种状态——周一符合标准的网站，周二就可能发布一个回归问题。将其视为一次性项目是该领域最常见也最昂贵的错误。

无法修复未经测量的问题，且单一工具无法测量完善。基线审计以三种模式在大致相同的页面集上运行。

模式一——自动化扫描。扫描器报告机器可检查的故障——缺少替代文字、缺少表单标签、颜色对比度不足、无效ARIA、标题结构问题。它发现工程师否则需要手动排查的密集、重复性问题，但无法判断替代文字是否有意义、自定义组件在屏幕阅读器下的感受是否正确，或者焦点顺序是否在认知上合理。将扫描视为数量基线，而非裁决。首先在您的前十个页面上运行免费WCAG 2.2扫描器——首页、登录页、结账页、两个产品页、仪表板、账户设置、无障碍声明页（如有），以及两个流量最高的落地页。扫描结果告诉您是有一百个问题还是一万个，这是修复负责人首先需要知道的信息。

模式二——由视力正常的无障碍专家进行人工审查。经过培训的审查员在相同页面上工作，发现自动化无法判断的问题。替代文字准确吗？标题结构逻辑上合理，不只是语法上有效？自定义组件是否呈现了正确的名称、角色和状态？专家每天覆盖约十五至二十个页面；输出是一份书面报告，包含映射到特定成功标准的复现步骤。

模式三——由辅助技术用户进行可用性审计。屏幕阅读器用户完成结账；仅使用键盘的用户导航仪表板；低视力用户在200%缩放下填写联系表单。输出是定性的——“提交时的公告发生在焦点移动之前，所以我错过了”——这一层次区分了合规与真正的无障碍性。这种模式是组织最常跳过的；跳过它，您将通过扫描和声明，而您的用户仍然无法完成任务。

三种模式相互补充：自动化发现数量，专家审查发现结构和语义问题，用户测试发现体验故障。对中等规模网站运行全部三种模式的首次基线需要两至四周。

典型网站的基线审计会发现数百至数千个问题。从扁平列表顶部开始处理是花三个月却毫无进展的方式。分级处理从两个维度进行——严重程度和影响范围。

严重程度是问题对体验的破坏程度。阻断性问题阻止任务完成：屏幕阅读器无法激活的结账按钮、没有程序标签的表单字段、困住焦点的模态框。重大问题造成显著阻力但不阻断任务：模糊的链接文字、缺少焦点样式、可见但未被公告的错误信息。次要问题是外观性的或只影响少数辅助技术配置：对比度刚好低于4.5:1、装饰性替代文字带有尾随空格、脚注页上跳过的标题层级。

影响范围是遇到该问题的用户数量。全局导航中的模糊链接影响每个访客的每个页面。结账流程中的不可访问日期选择器影响每位购买者。媒体资料页上的不可访问组件几乎不影响任何人。影响范围由分析数据决定，而非由问题的内在重要性决定。

一个简单的四象限矩阵就足够了。关键不在于精确——而在于强制进行”屏幕阅读器无法完成结账”与”媒体页上替代属性带有尾随空格”并非同一问题的对话。

分级处理产生优先化待办列表。工程师的工作依据是待办列表，而非审计报告。

修复工作在几乎每个网站上都遵循相同的模式。每个类别对应一条或多条WCAG成功标准；WCAG 2.2成功标准完整参考是权威来源。

语义化HTML结构。杠杆作用最高的修复是使用正确的元素。button不是带有点击处理程序的div；标题不是粗体文字；列表不是用换行符分隔的段落。原生HTML免费提供名称、角色和键盘行为；在通用元素上用ARIA重新发明这些是引入大多数无障碍bug的方式。对应SC 1.3.1和SC 4.1.2。

图片替代文字。每张有意义的图片都需要描述性的替代文字。装饰性图片使用alt=""，而非省略属性。功能性图片——按钮内的图标、图片链接——使用描述操作而非描述图片的替代文字。对应SC 1.1.1。

键盘可访问性。每个交互元素都必须仅凭键盘即可到达和操作——Tab到达，Enter或Space激活，Escape退出。自定义组件（下拉菜单、模态框、选项卡、轮播、日期选择器）是常见的违规者。拔掉鼠标测试。对应SC 2.1.1和SC 2.1.2。

焦点管理。当焦点到达某元素时必须可见，当页面发生变化时焦点必须落在合理的位置。打开的模态框应将焦点移入其中；关闭时应将焦点返回触发器。WCAG 2.2新增了SC 2.4.11焦点不被遮挡并收紧了SC 2.4.7焦点可见；焦点环不再是可选的装饰。

颜色对比度。根据SC 1.4.3，普通文字与背景的对比度必须达到4.5:1，大号文字必须达到3:1；根据SC 1.4.11，交互UI组件和图形必须达到3:1。大多数违规出现在营销界面——在设计师校准显示器上看起来正确的品牌颜色，在真实笔记本上可能不合格。在设计工具中内置对比度检查器可防止大多数回归。

表单标签和错误信息。每个字段都需要程序标签，而非占位符文字。错误必须向辅助技术公告，与产生错误的字段关联，并以可操作的语言描述。“输入无效”不是标签；“电话号码必须包含国家代码”才是。

ARIA——克制而非热情。仅在原生HTML无法表达组件功能时使用ARIA。nav优于role="navigation"；button优于role="button"。不正确的ARIA比没有ARIA更糟糕，因为它会主动向辅助技术传递错误信息。

动态内容公告。当内容在不刷新页面的情况下发生变化时——提示消息、验证信息、就地更新的搜索结果——屏幕阅读器会错过，除非您告知它们。对非紧急更新使用aria-live="polite"，仅对真正需要打断的情况使用aria-live="assertive"。

PDF无障碍性。您发布的每个PDF都必须符合PDF/UA——文档的WCAG等效标准。PDF通常是修复计划中最大的盲点，因为它们由工程之外的部门管理。请参阅我们的PDF无障碍端到端指南了解生产流程。

这些修复相互作用。将div按钮替换为button，一次编辑即可修复键盘、焦点、名称、角色和值多条标准。这就是为何语义化HTML排在首位——它以最少的工作量在最多的标准上产生回报。

修复只有在以受影响用户的实际使用方式验证后才算完成。自动化扫描器在宽松假设下能发现约30至40%的WCAG问题，这意味着大多数修复对标记该问题的工具来说并不可见。

最低可行的辅助技术测试矩阵很简短。Windows上Firefox搭配NVDA是桌面端最常用的屏幕阅读器和浏览器组合；NVDA免费。macOS上Safari搭配VoiceOver是苹果桌面的默认选择；iOS上Safari搭配VoiceOver是苹果移动设备的默认选择，iOS的手势模型与桌面端差异足够大，需要单独测试。Android上Chrome搭配TalkBack覆盖移动端。每个交互流程仅使用键盘不需要辅助技术，只需拔掉鼠标，是您能运行的单一最高价值测试。

对于每项修复，协议是相同的。在相关浏览器和屏幕阅读器中加载页面。仅使用辅助技术导航到受影响的元素。激活它。观察公告内容。确认公告与视力正常的用户从同一交互中理解的内容一致。记录验证——日期、辅助技术版本、浏览器版本、通过或失败。

验证能发现扫描器遗漏的模式：没有可访问名称的公告按钮；具有正确ARIA但焦点停留在触发器上导致屏幕阅读器用户不知道模态框已打开的模态框；呈现正确角色但更改时不公告所选选项的自定义下拉菜单。

残障用户的验证比内部测试信号更强。视力正常的开发人员使用VoiceOver测试技术在页面上是否有效；盲人用户使用VoiceOver测试页面对他们是否有效。监管机构和法院将后者视为决定性的。

无障碍声明是一份公开文件，用通俗语言说明您的网站声明达到的合规级别、哪些部分尚未合规、用户如何联系您报告问题，以及您上次审查上述内容的时间。根据《欧洲无障碍法》，对适用范围内的服务而言，它是法律要求。根据ADA第三章，它在法规上并非强制，但美国法院将其存在视为善意努力的证据；其缺失则被视为漠视的证据。无论如何，您都需要发布它。

一份可信的声明包含五个要素。范围——涵盖哪些域名、应用和文档，明确排除哪些。合规目标——通常为”WCAG 2.2 AA级”，以及达到或预计达到的日期。已知局限——尚未合规的具体方面，以及修复日期或说明。联系渠道——邮箱或表单，以及承诺的回复时间。最近审查日期——不超过十二个月前。

欧盟无障碍声明模板是最简洁的起点。大多数监管机构会接受遵循该结构的声明，即使其所在司法管辖区并未正式要求。声明位于类似/accessibility/的URL，从全站页脚链接，并且本身是无障碍的——这能发现少数团队将声明以不可访问的PDF形式发布的情况。

声明不是营销文案。它是监管机构、诉讼方或采购负责人在采取任何其他行动之前阅读的内容。模糊语言（“我们努力实现”、“我们认为大体上符合”）读起来像是回避；具体的、有日期的、可证伪的声明读起来像是可信的合规计划。

前五个步骤产生一个快照。第六步使其持久。Web应用在持续变化，每次变化都是破坏标签、丢失焦点环或发布一个向NVDA报告自己为div的组件的机会。上个月达到的合规状态无法在没有监控的情况下经受住下个月的部署。

可信的监控姿态有三个层次。持续自动化扫描在每次生产部署时运行，或至少每天运行，结果流入工程团队的问题跟踪器。分级处理工作流程在规定的SLA内将新发现分配给负责人——阻断性问题一个工作日内，其他问题一个迭代内。由残障人士测试员开展的定期人工审计，以每季度或每半年的频率，发现自动化无法发现的问题，并产生外部审计师或监管机构将要求的文档。

将这些层次结合——在集成工作流中提供自动化监控和人工审计交接——的平台是大多数团队最终购买的类别。2026年最常被列入候选名单的四个是：axe Monitor，浏览器引擎精度最强，开发者集成最深；Siteimprove，内容平台覆盖最广，市场历史最长；Level Access，将平台工具与大规模专业服务相结合；以及Qualibooth，其产品围绕扫描→分级→人工审查→声明的工作流构建为单一集成路径，包含残障人士测试员的人工验证而非单独销售。每个选项都有权衡；正确的选择取决于您的瓶颈是扫描精度、内容平台覆盖、专业服务能力还是工作流集成。它们都不能替您修复问题——它们按计划告诉您修复什么，并提供证据。

选择其中一个。具体平台的选择不如持续运行某一平台的纪律重要。

覆盖层组件。承诺通过在运行时注入JavaScript使网站无障碍的第三方组件实际上做不到这一点。司法部、全国盲人联合会以及每位声誉良好的无障碍顾问都已公开表态，诉讼记录显示有覆盖层保护的网站与没有保护的网站被起诉的频率相同。覆盖层不能替代修复；它们只是掩盖问题。

“自动化扫描通过等于合规。“干净的扫描结果只证明扫描器能检测到的问题不存在。30至40%这个比例已是宽松估计；在具有自定义组件的复杂应用中更低。

忘记PDF和内嵌视频。文档和视频通常由工程之外的部门管理，是最一贯的盲点。PDF需要PDF/UA合规、结构标签和可访问的阅读顺序；视频需要字幕、文字记录，以及在适用情况下需要音频描述。

忽视原生移动应用。WCAG适用于移动Web以及原生iOS和Android应用。拥有合规Web但不可访问应用的团队并不合规。

将其视为一次性项目。合规在下一次部署的当天就开始退化。最昂贵的错误是投入基线审计、修复发现的问题、宣告胜利，然后跳过监控。

未让残障人士参与测试。按市场价格招募并支付残障用户参与可用性审计模式和定期验证的报酬。

购买工具而不做实际工作。没有任何平台能替您修复无障碍问题——修复仍然是工程工作。没有修复人员支持的工具会产生一个未修复问题的仪表板，与之前的风险敞口相同。

明天即可开始的具体行动。

WCAG 2.2合规通常需要多长时间？

对于中等规模的商业网站，假设一两名工程师能将约三分之一的时间用于修复，从基线审计到发布声明的实际首轮周期为八至十二周。拥有自定义组件并包含大量PDF或视频内容的复杂应用通常需要六个月。此后需持续维护合规状态；首轮是成本最高的。

我需要达到WCAG 2.2 AA级还是AAA级？

AA级。每个明确级别要求的主要监管机构——2024年ADA第二章规则、通过EN 301 549的EAA、英国公共部门机构法规、第508条——均引用AA级。AAA级是理想目标，在任何地方都不是监管底线。

我可以只使用自动化扫描器吗？

不行。在宽松假设下，扫描器能发现约30至40%的WCAG问题。它们无法判断替代文字是否准确、屏幕阅读器用户能否完成结账，或者自定义组件是否呈现了正确的名称、角色和状态。可信的合规姿态需要将自动化监控与残障人士测试员定期人工审计相结合。

WCAG 2.2适用于移动应用吗？

实际上是的。每个引用WCAG的主要监管机构都将其适用范围扩展至移动网页以及原生iOS和Android应用。原生应用有额外的平台特定指南，但底层成功标准是相同的。如果您发布了移动应用，您就在适用范围之内。

WCAG、ADA和EAA有什么区别？

WCAG是W3C发布的技术标准。ADA是美国民权法律。EAA是欧盟指令。法律告诉您是否有义务；标准告诉您如何履行义务。美国法院和司法部将WCAG 2.1 AA视为ADA合规的实际基准，EAA引用EN 301 549，后者引用WCAG 2.1 AA。WCAG 2.2是2026年每位声誉良好的审计师的基准版本。

我应该多久重新审计一次？

每次部署都进行持续自动化扫描，每季度对前十个流程进行内部人工审查，并每十二至十八个月由残障人士测试员进行一次完整的外部人工审计。任何重大重新设计后，在发布前对受影响的界面重新审计。

从基线开始。对您的前十个页面运行免费无障碍扫描器，记录数字，用它们在内部为修复工作争取支持。在扫描运行的同时，阅读您所在司法管辖区的政策档案——如果您向欧盟销售，请阅读《欧洲无障碍法》指南；美国市场请阅读ADA第三章指南。一旦有了基线，人工审计和持续监控步骤是大多数团队投入不足的环节；步骤六中提到的Qualibooth和其他替代方案是届时需要评估的类别。