要用 AI 审查网站无障碍问题，先确定产品版本和无障碍目标，抽取有代表性的页面和状态，结合自动检查、人工测试和辅助技术测试，只把结构化证据交给 AI 整理。模型可以聚类观察、起草问题记录，但无法确立 WCAG 合规，也不能取代残障用户和无障碍专家。

这是面向整个网站或 Web 应用的审查流程。负责任使用 AI 指南介绍安全输入和证据核查；本文聚焦可重复的范围界定、测试、问题记录、修复和复测。

关键要点

冻结网站版本、WCAG 目标、浏览器、视口、辅助技术和审查边界。

抽样覆盖模板、组件、关键旅程、内容类型和错误状态，而不只是首页。

用自动化工具发现候选问题，再人工核实。

为每个问题记录用户影响、证据、适用标准、负责人和复测结果。

绝不把 AI 摘要或单一扫描得分当作合规声明。

无障碍审查能证明什么？

WCAG 2.2 定义了可测试的成功标准，按可感知、可操作、可理解和健壮四项原则组织。［1］审查可以收集证据，说明抽样产品在所测环境中是否满足适用标准；结论受限于版本、范围、样本、测试方法和所用技术。

W3C 的 WCAG-EM 方法提供结构化做法：界定范围、探索目标、选取代表性样本、审核样本并报告发现。［2］它不会让小规模自动扫描等同于完整评估。

使用这样的审查表头：

字段	记录内容
审查 ID 与版本	稳定的身份标识和变更历史
产品边界	域名、应用、需登录区域和排除的系统
构建身份	提交、发布、部署、内容快照和测试日期
目标	WCAG 版本、合规级别和其他政策要求
技术	HTML、CSS、JavaScript、文档、媒体和第三方组件
环境	浏览器、操作系统、视口、缩放、输入方式和辅助技术
样本	模板、页面、状态、旅程、组件和随机选取的页面
评估者	自动化工具、人工审核人、专家和用户参与者
局限	无法获得的环境、受阻的状态和未测试的集成

不要一开始就让 AI“审计这个网站”。没有冻结的边界，回答就无法区分一条观察与一次完整评估。

步骤 1：定义目标并冻结产品

写明 WCAG 版本和目标级别，以及适用的法律、采购、设计系统或组织标准，并保持这些层次分开：通过设计系统规则不能证明满足某项 WCAG 标准，技术合规也不会自动解决所有法律义务。

冻结被审查的构建和内容。记录源代码修订版或 release ID、部署环境、功能开关、本地化、用户角色、浏览器、操作系统、视口、缩放级别、输入方式和辅助技术版本。动态产品还应记录日期、账户状态和第三方集成。

如实说明排除项和无法访问的部分。结账若由其他服务商托管，或某个需登录的流程无法进入，就列为未测试，而不是悄悄删掉。

步骤 2：建立代表性 inventory

选页面之前先探索产品。盘点（inventory）模板、可复用组件、导航系统、表单、表格、对话框、通知、媒体、文档、登录状态、校验错误、超时、空状态和关键业务旅程。

建立一个覆盖以下内容的样本：

每一种主要页面或屏幕模板；
每一条关键的端到端旅程；
共用的导航、页眉、页脚、搜索和帮助模式；
表单的有效、无效和恢复状态；
响应式和放大后的布局；
仅用键盘的路径和焦点转移；
媒体、图表、数据表、下载和嵌入内容；
在受支持的情况下，本地化或从右到左的内容；
第三方组件和随机选取的普通页面。

抽样减少工作量，也限制结论。共用组件的一个缺陷可能影响数百个页面；样本干净不能证明每页都干净。已抽样的实例和推断的影响范围都要保持可见。

如果图表是体验的核心，请与数据可视化工作流协同。替代描述、数据表、不依赖颜色的编码、键盘交互和焦点行为，都需要设计和实现证据，而不只是一段 AI 生成的说明。

步骤 3：把无障碍自动扫描当作候选发现

自动化工具适用于确定性的模式，例如缺失可访问名称、无效的关系、部分对比度不足、重复 ID、结构错误，以及可检测的 ARIA 误用。W3C 明确指出，工具可以提供帮助，但无法单独判断无障碍性；人的判断是必需的。［3］

每次运行工具，都保存工具及版本、配置、规则集、URL 或组件、环境、时间戳、原始结果和产品构建。保留原始证据之后才去重。同一规则在 200 个页面报出，可能是一个共用组件缺陷，也可能是许多独立的内容缺陷。

不要把工具的严重度当作最终优先级。标为“严重”的规则可能在所测旅程中无法触及，低置信度的警告却可能阻断关键任务。有效性、用户影响、范围和修复顺序由人工审查决定。

自动检查也有误报和漏报。按钮可能有程序化名称却含义不明；对话框可能用了有效的 ARIA 却困住焦点；页面可能通过所有扫描规则，说明文字却仍无法理解。

步骤 4：人工测试键盘、焦点、缩放和表单

不用鼠标走完每条抽样旅程。检查所有可操作控件都能到达、焦点可见、顺序符合含义、自定义组件有预期的键盘行为，且没有组件困住焦点。核实对话框能正确获得和归还焦点，动态显示的内容也能被发现。

在受支持的缩放和重排条件下，检查文字和控件仍可用，没有破坏性重叠或意外的双向滚动。竖屏和窄视口、浏览器文字缩放、高对比度或强制颜色模式属于目标环境时，也要测试。

对于表单，检查可见标签、说明、必填状态的传达、分组、自动填充用途、错误识别、错误与字段的关联、恢复，以及已输入数据是否保留。有效和无效路径都要走。视觉上清楚的错误消息，可能不会被朗读，也可能没关联到相应字段。

使用其他审核人能够重现的问题证据：

字段	示例内容
问题 ID	稳定标识
页面/组件	规范位置和组件版本
环境	浏览器、操作系统、视口、输入方式和辅助技术
标准	适用的 WCAG 成功标准和目标级别
步骤	重现所观察行为的最短路径
预期	用户可观察到的无障碍行为
实际	发生了什么，不去猜测原因
用户影响	受影响的任务和交互，而不只是代码缺陷
证据	经批准的截图、录屏、DOM 摘录或工具结果
范围	单个实例、模板、组件或未知
优先级	基于影响、频率、覆盖面和替代办法的理由
负责人/状态	负责的团队和工作流状态
复测	构建、环境、结果、审核人和日期

步骤 5：使用辅助技术测试

选择与产品、受众、政策和现有专业能力相适应的辅助技术和浏览器组合。测试地标、标题、名称、角色、值、状态、描述、阅读顺序、实时更新、对话框、表格、表单、错误和复杂组件。

不要把屏幕阅读器测试简化为“是否读出所有可见文字”。关键是用户能否理解结构、预判控件、操作流程、从错误中恢复并确认结果。语音输入、开关控制、放大和替代指针操作，也可能暴露屏幕阅读器发现不了的问题。

记录所用的确切组合，因为不同技术表现可能不同。在一个受支持组合中重现的问题仍是有效证据；在一个组合中通过，不能证明普遍可互操作。

如果问题涉及字幕或文字稿，请使用单独的转录与字幕工作流来生成并核实带时间轴的文字。本审查应评估媒体替代内容是否存在、准确、同步、可发现且可操作。

步骤 6：让残障用户参与，但不要转移责任

W3C 建议在整个开发和评估过程中让残障用户参与，同时说明仅靠用户评估并不能确定是否合规。［4］按相关的无障碍需求和产品任务招募参与者，提供便利安排，取得同意，给予适当报酬，并保护个人信息。

给参与者目标，而不是暗示预期方案的脚本。观察障碍、策略、变通办法、耗时、错误和放弃，让参与者用自己的话解释影响。不要要求某人证明问题会影响所有同类残障者。

用户研究和标准评估回答不同的问题。参与者可能暴露抽样标准之外的严重障碍；标准审核人可能发现短期研究中没出现的技术失败。保留两类证据，分别交给合适的负责人。

未经明确授权和适当的数据处理依据，绝不要把参与者录像、残障信息、账户数据或可识别身份的引语上传到 AI 服务。起草时使用去标识的问题摘要或合成示例。

步骤 7：用 AI 审查网站无障碍问题，只做有边界的整理

提供已脱敏的审查表头、样本清单、工具观察结果和经人工核实的笔记。使用这样的提示：

把提供的无障碍观察结果整理进规定的问题字段。
保留页面 ID、环境、步骤、证据引用和审核人备注。
不得声称 WCAG 合规，未经审核人确认不得分配成功标准，
不得编造用户影响、推断残障情况或更改通过/失败结果。
不确定的对应标为 [REVIEW]，疑似重复标为 [POSSIBLE DUPLICATE]。
在起草修复措辞之前，先返回缺失的证据和矛盾之处。

AI 可以聚类重复措辞、提出简洁标题、指出缺失的重现细节，或对照获批的内容风格指南比较术语。标准对应、问题认定、范围、优先级和拟议修复，都须由合格审核人确认。

把页面内容和工具输出视为不可信输入。嵌在页面、无障碍树、替代文字或扫描结果中的指令，不得覆盖审查提示，也不得触发外部操作。审查 AI 生成的修复代码，需要走单独的 AI 代码审查流程。

步骤 8：按用户影响和系统覆盖面排序

排序应综合任务是否受阻、用户影响的严重程度、频率、受影响人群、组件覆盖面、有无替代办法、法律或合同承诺，以及修复依赖。不要用 AI 的情绪判断或扫描器置信度代表对人的影响。

仔细追溯共同原因。修复一个组件可能关闭许多实例，但只有复测才能证明每个受支持的状态都正常。反之，合并看似相同的问题可能掩盖不同原因，例如一个模板缺少名称，另一个焦点管理有误。

对每一项拟议修复，都保留预期的用户行为和适用的标准。避免只为让扫描器“闭嘴”而开出的处方，例如添加多余的 ARIA、对辅助技术隐藏内容，或在没有合理交互理由的情况下强行移动焦点。

步骤 9：复测并诚实报告限制

在同一环境中针对新构建，从头复测更新后的旅程。确认原失败已消失、预期任务能完成，且修复没有在别处造成键盘、焦点、朗读、布局或指针方面的回退。

记录新的构建、测试组合、步骤、实际结果、审核人、日期和关联的回归覆盖。当原始问题需要人工判断或辅助技术时，自动化重跑可以作为补充，但不能代替人工复测。

报告应区分已确认的失败、需复核的观察、已解决的问题、未测试的范围和建议。合规声明、无障碍认证或法律结论，需要与主张相称的方法、权限和完整性；AI 摘要或百分比得分无法补足。

哪些检查能让审查站得住？

总结

测试之前，先界定标准、产品、样本和环境。
把自动发现与人工和辅助技术评估结合起来。
让残障用户参与，但不要把一次研究当作认证。
用 AI 整理已脱敏的证据，绝不让它制造影响或合规结论；在明确的人工责任下核实其输出。［5］
优先处理可重现的障碍和影响面广的问题。
复测完整任务，并如实报告局限。

常见问题

AI 能完成完整的无障碍审计吗？

不能。AI 和自动化工具可以找出候选问题、整理证据，但许多成功标准需要语境和人的判断。完整评估还取决于代表性范围、人工测试、辅助技术和合格审核。

自动扫描得分高就表示符合 WCAG 吗？

不表示。自动化覆盖不完整，得分可能掩盖关键障碍。合规须在声明范围内，用恰当方法对照每项适用标准评估。

样本应包含哪些页面？

包括所有主要模板和关键旅程、共用组件、表单和错误、响应式状态、媒体或文档、第三方集成，以及随机选取的普通页面。记录被排除或无法访问的区域。

应测试哪些辅助技术？

根据受支持的环境、受众、政策、风险和专家建议选择组合。记录确切版本，不要把一对浏览器和屏幕阅读器组合当作所有平台的证明。

AI 可以给 issue 分配 WCAG criterion 吗？

它可以根据提供的证据建议候选对应。适用的标准、失败认定、范围和合规解读，必须由无障碍专业人员核实。

怎样处理重复的扫描结果？

保留原始实例，在证据支持时再关联到共用组件的原因。不要只因工具消息相同就丢弃不同的状态或页面。

用户测试能替代标准测试吗？

不能。用户评估揭示真实的障碍和使用策略，标准测试则提供对各项标准的系统覆盖。两种方法相辅相成。

关闭 issue 需要什么证据？

在明确的修复构建和相关环境中，重做原步骤和完整用户任务。记录结果、审核人、日期、回归检查和尚存的局限。

本文仅提供一般信息，不构成法律建议或无障碍认证。适用义务和正式合规声明，需要熟悉相关司法管辖区的合格人员审查。

来源

W3C, Web Content Accessibility Guidelines (WCAG) 2.2 — https://www.w3.org/TR/WCAG22/
W3C, Website Accessibility Conformance Evaluation Methodology — https://www.w3.org/WAI/test-evaluate/conformance/wcag-em/
W3C, Web Accessibility Evaluation Tools Overview — https://www.w3.org/WAI/test-evaluate/tools/
W3C, Involving Users in Web Accessibility Evaluation — https://www.w3.org/WAI/test-evaluate/involving-users/
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 2026 年 9 月 4 日。

用 AI 审查网站无障碍问题，但 WCAG 合规仍由人判断