假设我们制作了一个注册界面。用户在这个界面上输入电子邮件地址和密码，同意条款，然后点击注册按钮。使用鼠标操作时，看起来没有问题。但是，如果用键盘打开条款后无法移动到关闭按钮，就很难完成注册。如果仅用红色边框表示输入错误，难以分辨颜色的人就很难知道需要修改什么。
这个例子并不是对某项服务进行检查后得到的结果，而是用于说明无障碍的假设情境。学习 Web 无障碍的起点，就是在这样的情境中考察用户能否获取信息并完成所需的任务。理解标准后，就能说明问题产生的原因；设计评估方法后，也能确认修改后的结果。
本系列将结合 WCAG 与 AI，帮助大家学习这一过程。我们会说明各项标准旨在保障的用户需求，分析实现示例，然后提供评估所需的资料和提示词。第一篇文章将梳理整体学习路径，以及开始评估的方法。
设计能让用户获取信息并使用功能的服务
W3C 的 Web 无障碍介绍说明了如何设计网站和工具，使残障人士能够感知、理解、浏览和操作 Web 上的信息。这不仅涉及视觉和听觉，还包括肢体、认知、学习等多种无障碍需求。W3C 的 Web 无障碍介绍
用户会以不同的方式使用同一个界面。他们可能使用屏幕阅读器浏览标题和输入项，也可能放大屏幕，只查看其中一部分区域。他们可能用键盘或其他输入设备代替鼠标，也可能通过字幕理解视频中的语音。设计和实现必须在这些使用方式下同样传达信息并提供功能。
在手部受伤而难以使用鼠标的情况下，或在无法听到声音的环境中，考虑了无障碍的功能也会有所帮助。不过，如果仅用这些附加益处来解释无障碍，就会模糊残障人士使用服务所必需的条件。本系列将以用户的无障碍需求和实际要完成的任务作为判断依据。
在前面的注册界面中，阅读说明、理解输入项的用途、查看条款、修正错误并完成注册的过程，都是评估对象。仅确认条款弹窗能否打开还不够。还需要考察能否进入弹窗、查看内容，以及关闭弹窗后继续输入。
将 WCAG 作为实现与评估的共同依据来理解
WCAG 是 Web Content Accessibility Guidelines 的缩写。本系列以 W3C 推荐标准 WCAG 2.2 为依据。表示无障碍的 a11y，是将 accessibility 的首字母 a 与末字母 y 之间的 11 个字母用数字缩写而成的写法。
熟悉 WCAG 的四项原则，有助于在阅读具体条目时理解相应要求为何必要。下表中的问题和注册界面示例，是为了将各项原则与实际工作联系起来而提供的说明。W3C 的无障碍原则
| 原则 | 设计时需要确认的问题 | 注册界面中需要考察的示例 |
|---|---|---|
| 可感知性 — Perceivable | 是否以用户能够感知的形式提供所需信息？ | 是否在使用颜色的同时，也用文字说明错误内容？ |
| 可操作性 — Operable | 用户能否通过自己的输入方式操作功能？ | 能否用键盘打开并关闭条款，然后继续注册？ |
| 可理解性 — Understandable | 用户能否理解信息和操作方法，并预期操作结果？ | 密码要求和错误修正方法是否具体明确？ |
| 稳健性 — Robust | 浏览器和辅助技术能否解析元素的含义与状态？ | 输入项的名称和错误状态能否以程序可确定的方式传达？ |
每项原则下都有指南和成功标准。例如，1.1.1 是关于非文本内容的替代文本的成功标准。在实际判定时，需要阅读其适用条件和例外情况。Understanding 文档说明标准的目的和示例，Techniques 文档则有助于参考实现方法。满足标准的实现方式并不局限于某一个特定示例。WCAG 2.2 标准
成功标准被划分为 A、AA、AAA 三个级别。AA 符合性要求同时满足 A 和 AA 的要求，AAA 符合性则涵盖三个级别的全部要求。如果将级别理解为实现难度或问题严重程度的排序，就可能错误地确定优先级。W3C 不建议将完整满足 AAA 的所有要求作为适用于所有网站的一般政策，因为某些内容无法满足全部 AAA 标准。W3C 的符合性说明
WCAG 2.2 中有效的成功标准共有 86 项。其中 A 级 31 项、AA 级 24 项、AAA 级 31 项，本系列计划用一篇文章和一个提示词分别介绍每一项。WCAG 2.2 中已删除的 4.1.1 Parsing 不纳入当前评估条目。WCAG 2.2 标准、WCAG 2.2 的变更
如果是第一次设计评估，我们建议先将 WCAG 2.2 AA 作为工作目标的初稿，再审查服务用户和内容所需的额外标准。这是本系列提出的实务建议。不能仅凭本文确定某个具体项目的目标级别。
将界面状态和完整使用过程纳入评估范围
注册页面即使只有一个 URL，也会有多种状态。首次访问状态、显示密码要求的状态、条款弹窗打开的状态、发生错误的状态，以及注册完成状态，各不相同。在移动端界面和放大后的界面上，布局也可能发生变化。
因此，评估时应在记录 URL 的同时，记录状态、操作顺序和执行环境。对最初显示的界面进行检查所得的结果，只适用于当时确认过的范围。不能将其解读为已经确认了登录后的界面或错误处理。
WCAG 的符合性要求也涉及完整页面和完整过程。在跨多个页面的注册或购买过程中，该过程所需的页面都必须满足目标级别。不能仅凭对部分元素的检查结果汇总而成的分数，就宣称该过程符合要求。WCAG 的符合性要求
如果网站规模较大，可以选择有代表性的页面和状态进行评估。W3C 的 WCAG-EM 2.0 说明了定义范围、探索目标、选取代表性样本、评估和报告结果的流程。应将样本评估的范围与针对整个网站的声明区分开来记录。WCAG-EM 2.0 评估方法
如果从注册界面开始，可以像下面这样划分状态。下表是评估计划的示例，并不表示已经发现了实际问题。
| 状态 | 希望确认的内容 | 需要准备的证据示例 |
|---|---|---|
| 首次访问 | 能否找到输入项的用途和要求？ | 渲染后的 DOM、界面、无障碍树 |
| 条款弹窗打开 | 能否操作弹窗并返回输入界面？ | 键盘操作顺序、焦点记录、各状态下的界面 |
| 提交错误的电子邮件地址 | 能否知道错误项及其修正方法？ | 错误状态下的 DOM、提示文字、辅助技术的输出 |
| 修正输入后重新提交 | 错误是否消除，能否进入下一步？ | 修正前后的状态和操作记录 |
| 注册完成 | 能否感知处理结果？ | 完成界面、状态变化记录、所需辅助技术的输出 |
从核心使用过程开始，是因为这样更容易说明问题对任务完成的影响。在评估最初选定的过程后，再将范围扩展到其他功能和共用组件。不能将这一过程通过评估记录为整个网站已完成评估。
利用多模态 AI 扩展对语义和行为的评估范围
无障碍工具能够找出可通过既定规则快速检查的问题。检查范围和结果的含义，会随工具实现的规则、输入资料和实际执行的状态而变化。W3C 说明，仅靠评估工具无法自动判定无障碍的所有方面，而且结果也可能不准确。无障碍评估工具的作用与选择方法
本系列将探索通过 AI 评估语义、上下文和交互的方法，这些方面以往较难通过规则检查处理。向能够同时处理文本和图像的多模态模型提供所需资料，并连接浏览器操作工具，可以扩大评估时能够观察的范围。针对每个条目设计并验证收集方法和判断流程，是本系列的方向。
以替代文本为例。图像具有 alt 属性这一事实，与该属性的内容是否恰当地传达了图像用途的判断，是两回事。即使是同一张配送卡车图像，它是配送说明中的装饰，还是通往物流查询功能的链接，所需的替代信息也会不同。W3C 的替代文本决策树同样指导我们根据图像的功能和上下文进行选择。替代文本决策树
除了图像和替代文本，还可以向 AI 提供周围文字、是否为链接、目标地址等信息。也就是说，应设计评估问题，让模型不只是描述图像的外观，而是审查它是否传达了该位置所需的信息。实际判断的准确程度如何，需要收集案例进行验证。
在行为评估中，需要收集的证据会进一步有所不同。条款弹窗的截图可以用来考察布局和部分视觉状态，但键盘焦点移动到了哪里，需要实际操作和记录。错误是否传达给屏幕阅读器，也不能仅凭界面来确定。必须收集该判断所需的观察资料，例如所用辅助技术的输出。
这时，区分“缺少资料”与“AI 判断失败”这两种情况，就能明确下一步工作。如果未获得焦点记录，就增加收集步骤。如果已有所需记录，判定却仍不稳定，就应审查输入组织方式、标准解读、提示词和模型性能。这样可以逐步扩展评估范围。
还需要明确数值测量与语义判断各自的作用。例如，评估对比度时，与其让模型看着界面猜测数值，不如通过工具确认该界面的颜色和计算所需条件，再提供测量结果，这样更容易验证。可以将智能体设计为进入所需状态、运行测量工具，并将结果与相应标准关联起来。
从近期 AI 评估研究中了解可能性与条件
2025 年公开的研究*《Towards Scalable Web Accessibility Audit with MLLMs as Copilots》*提出了一种将多模态模型用于页面样本选取和无障碍审计的架构。这是将 AI 的应用从单个界面判定扩展到评估过程的研究案例。研究原文
2026 年 9 月公开的预印本*《Agentic Web Accessibility Auditing》*探讨了接受针对各项标准的指导后，智能体如何检查页面并运行工具。研究人员使用由 11 个学术平台的 24 个页面构成的 250 条页面—标准记录进行了评估。在报告存在问题的 78 条页面—标准记录中，智能体找出了 67 条，召回率为 86%；被判定为存在问题的记录中，与参考答案一致的比例，即精确率，为 56%。研究原文与评估范围
这些数值是在该研究条件下获得的结果。虽然研究实现了针对 40 项标准的智能体，但包含问题案例的标准只有 15 项，而且研究将报告中未提及存在问题的记录推定为无问题案例。保存下来的页面行为可能与实际服务不同，开发过程中曾接触评估页面这一点，也限制了结果的泛化。因此，不能将 86% 作为所有网站上的检出率使用。
在本系列的评估设计中，我们建议为每个条目准备正常案例、问题案例和边界案例。在确认发现的问题数量的同时，还要检查误报、漏报、暂缓判断和重复执行的一致性，并记录复现结果所需的工作量。我们计划根据这样收集到的依据，判断提示词是否得到改进。
第一次练习：为一个使用过程制定评估计划
第一篇文章的练习，是从自己的服务中选择一个常用过程。可以是资料申请、用户注册、商品搜索等能够说明开始条件和完成条件的过程。同时记录是否连接了能够打开 URL 的工具，以及是否需要登录或测试环境。仅将 URL 放入提示词，并不意味着所有模型都能够访问或操作页面。
勾选下面的清单，表示已经审查了准备内容，并不表示已通过无障碍标准。
- 已写明用户想完成的任务和完成条件。例如：查看条款并注册，然后感知完成提示。
- 已梳理起始界面以及错误、弹窗、完成状态。尚未确认的状态保留为未确认。
- 已记录目标 WCAG 版本和级别，以及浏览器、屏幕尺寸、输入方式、辅助技术等评估环境。尚未确定的条件也已标明。
- 已区分将要提供的资料与已连接的工具。已移除个人信息和身份验证信息，并同时记录了截取时点和状态。
将这些资料填入概览评估计划提示词，就可以请求整理使用过程、所需证据、收集顺序和未确认事项。如果还没有实际执行所获得的资料，输出也应被理解为评估计划。
例如，“需要用屏幕阅读器确认错误”这一输出，是后续工作。而要作出“错误未被传达”的判定，则需要已观察的状态和实际输出。核查结果时，除了模型的说明，还应查看其依据所指向的原始资料。
评估实施后，应分别记录执行情况与判定。资料收集或操作失败记录为执行状态，对标准的结果则记录为满足、不满足、不适用、暂缓判断等。如果将未执行改成满足，或将尚未确认适用性的条目处理为不适用，就很难了解评估范围。
如果确认了问题，应先记录其对用户的影响和复现步骤。可以根据问题属于无法继续注册、难以理解提示，还是在多个界面中反复出现的共用组件问题，确定修改顺序。改进后，应在相同环境和状态下再次确认，并检查改动是否导致其他行为出现问题。
将逐项学习连接成可复用的评估过程
从下一篇文章开始，我们将逐一介绍 WCAG 2.2 的成功标准。每篇文章都会从需要该标准的用户情境出发，说明适用条件、例外情况和实现示例。随后，将 AI 所需的资料和提示词、阅读输出依据的方法，以及改进后需要确认的内容联系起来。
整体目录将按照四项原则和标准编号组织，以便浏览。可以从头按顺序阅读，也可以先查找与前面选定的使用过程有关的文章。如果将 AA 设为工作目标，应同时审查 A 和 AA 标准；在 AAA 文章中，则可以考察需要额外应用于服务的要求。
在系列最后，我们计划介绍一种智能体架构，将各条目的评估连接起来，依次确定范围、收集证据、报告结果，并再次确认改进效果。提示词和验证方法也会根据案例和研究进行更新。在每篇文章中，我们都会区分用于说明的示例与实际评估结果，并同时记录已验证的环境和范围。
在对标准进行评估的同时，也应考察用户体验。W3C 说明，让残障用户参与评估，有助于发现仅靠标准检查无法充分显现的使用问题。不能将 AI 模拟用户视角给出的回答，记录为已经替代了这类用户参与。与用户共同开展无障碍评估
第一阶段需要准备的，是一个待评估的使用过程，以及用于观察该过程的资料。下一篇文章将从非文本内容标准 1.1.1 开始，探讨应通过哪些替代方式提供图像所传达的信息。
参考资料
标准与研究资料核查日期：2026 年 10 月 1 日。以下研究结果由研究人员报告，并非运行本系列提示词所得的结果。
- W3C — Web 无障碍介绍：无障碍所面向的用户及多样化的使用方式。
- W3C — 无障碍原则：四项原则与主要要求。
- W3C — WCAG 2.2：成功标准和符合性要求的权威文本。
- W3C — 理解符合性：级别与符合性的说明。
- W3C — WCAG 2.2 的新增内容：新增标准及 4.1.1 的删除。
- W3C — WCAG-EM 2.0，2026-07-23 小组说明：评估范围、代表性样本和报告流程。
- W3C — 选择 Web 无障碍评估工具：工具的检查范围与结果解读。
- W3C — alt 决策树：根据功能和上下文选择替代文本。
- Gu 等 — Towards Scalable Web Accessibility Audit with MLLMs as Copilots，2025-11-05：利用多模态模型辅助审计的研究。
- Mishra 等 — Agentic Web Accessibility Auditing，2026-09-10 v2，预印本：针对各项标准的智能体、实验结果及局限。
- W3C — 让用户参与 Web 无障碍评估：用户参与与标准评估并行开展。
请提供所需资料后再运行提示词。
你是一位设计 Web 无障碍评估计划的顾问。 本次工作的目的是制定一个使用过程的评估范围与证据收集计划。 在实际审查资料或执行操作之前，不要作出无障碍判定。 [输入——仅填写已知内容，未知条件标记为“未定”] 服务说明： 用户想完成的任务： 完成条件： 目标 URL 与测试环境： 目标标准与级别：WCAG 2.2 / 级别未定或 A·AA·AAA 评估环境：浏览器、屏幕尺寸、缩放设置、输入方式、辅助技术 已知状态：初始、弹窗、错误、完成等 提供的资料：DOM、截图、无障碍树、操作记录、音频、视频等 已连接的工具与实际权限：打开 URL、键盘输入、截取、测量等 允许的操作：测试数据的使用范围及是否允许提交 各份资料的标识符、收集时点、对应状态： [编写原则] 1. 区分已提供的事实、评估者作出的假设，以及尚未确认的内容。 2. 不要因为存在 URL，就写成已完成访问、登录、操作或观察。 本次请求是编写计划。不要执行表单提交等实际操作。 3. 根据用户输入的目标级别选择标准。AA 包含 A 和 AA。 不要将 WCAG 2.2 中已删除的 4.1.1 Parsing 纳入评估对象。 如果无法确认标准原文或适用条件，应保留为“需要核查原文”。 4. 不要将规则检查、语义与上下文评估、实际操作作为固定类别，对某项标准整体进行归类。 即使在同一项标准内，所需方法和证据也可能随检查问题与状态而变化。 5. 不要仅凭截图确定焦点移动或屏幕阅读器的输出。 说明观察不足的原因和需要额外收集的资料。 6. 提醒不要提交包含个人信息和身份验证信息的资料。 [输出] A. 评估范围：选定的使用过程、开始与完成条件、包含与排除的范围、 目标版本与级别、尚未确定的执行环境。同时标明与整个网站评估的区别。 B. 状态与证据计划表： 状态 ID | 进入与退出条件 | 用户任务 | 候选 WCAG 标准及适用理由 | 所需证据与工具 | 已提供的资料 | 额外收集 | 完成确认方法 区分计划中的状态与实际观察到的状态。 C. 建议执行顺序：将必要的状态恢复、资料收集、规则检查与语义评估、 操作记录确认、审查与修改后的重新评估连接起来。 对于缺少工具或超出允许范围的工作，仅保留为执行建议。 D. AI 评估验证计划：提出正常、问题、边界案例的构建方法， 审查参考答案依据的流程，以及误报、漏报、暂缓判断和执行失败、 重复执行的一致性及复现结果所需工作量的记录方法。 在测量之前，不要作出关于准确度或成本的断言，也不要声称评估已完成。 E. 后续结果记录模板： 状态与环境 | 标准与检查问题 | 执行状态 | 判定 | 证据 ID 与位置 | 用户影响 | 假设与反证 | 修改建议 | 重新评估条件 执行状态分为未执行、已执行、失败、受阻。 判定分为未评估、满足、不满足、不适用、暂缓判断。 “未评估”是尚未作出判定的状态；“暂缓判断”是已经尝试评估， 但证据或解读还不充分的状态。对于不适用，应写明不适用的原因。 F. 立即准备的资料：按优先级列出推进计划所需的最少资料和问题。 请用简体中文撰写输出。不要将假设的问题、用户体验或测量值编造成实际结果。