网站无障碍检查报告很长，开发人员不一定能迅速判断哪些问题会挡住用户完成任务。AI 可以帮助解释扫描器发现的技术项、归纳重复问题、给出修复思路和测试步骤，但它不能只凭一段代码或一张截图就证明整个网站符合无障碍标准。更可靠的流程是：先选真实任务和关键页面，使用自动工具收集线索，再让 AI 辅助分析，最后由人员用键盘、读屏和真实页面完成复核。
一、先选择用户必须完成的任务
不要从“扫描全站得到多少问题”开始。先挑选访客常走的流程，例如打开导航、查找服务、填写咨询表单、提交预约或登录后台。列出每一步需要看到什么、操作什么、提交失败时如何修正。这样检查结果才能对应到真实的用户障碍，而不是只追求报告条数变少。
可先覆盖首页、主导航、服务详情、联系表单和关键确认页面；页面有不同模板时，每种模板都抽一页。W3C 的 WCAG 2.2 是当前发布的网页内容可访问性指南之一，可作为团队选择检查标准的参考；具体项目仍需先确认客户、合同或组织要求采用的标准与范围。W3C：Web Content Accessibility Guidelines (WCAG) 2.2
二、先用自动化工具找线索，再让 AI 解释
自动扫描工具适合发现部分可机器判断的问题，例如缺少标签、标题结构异常、部分颜色对比或表单控件信息不足。把扫描结果与页面地址、相关控件、测试环境和复现步骤一并保存。不要只把一张“问题清单”交给 AI，却不给它出现问题的页面上下文。
可以把脱敏后的扫描结果交给 AI，要求它按“报告原文、可能影响、需要人工确认的页面行为、建议复测步骤”整理，并明确区分工具证据和模型推测。不要要求模型给出“通过 WCAG”这样的认证结论。W3C 明确说明，自动工具不能单独判断网站是否满足无障碍要求，某些检查需要人工参与，工具结果也可能误报或误导。W3C WAI：Selecting Web Accessibility Evaluation Tools
三、用 AI 把报告变成可执行的修复任务
每个问题转成一张小任务卡，至少写清页面、用户操作、当前障碍、证据、期望结果和复测方式。比如“表单错误只用红色边框提示，键盘用户看不到下一步说明”比“修一下颜色”更容易执行和验收。若 AI 提出代码修改，先让它解释影响范围和预期行为，再由开发人员审查改动。
请仅依据下面的自动扫描结果和页面说明，整理最多五项需要复核的问题。每项列出扫描器原始证据、可能影响的用户任务、哪些判断不能仅靠当前材料确认，以及可以手工复测的步骤。不要声称网站已符合或不符合某项完整标准；不要直接重写页面代码。资料不足时标记“需要人工检查”。
先解决阻断关键流程的问题，例如焦点无法到达提交按钮、错误提示没有关联到输入框、弹窗打开后键盘无法操作。重复出现的同类问题可合并为一个组件级任务，但修复后仍要抽查所有使用该组件的页面。
四、用键盘和辅助技术完成人工检查
- 键盘路径：只用 Tab、Shift+Tab、Enter、方向键和 Esc 完成页面主要任务，观察焦点顺序、可见焦点和弹窗退出方式。
- 表单操作：确认每个输入项有清楚名称，必填与格式要求明确，错误信息能够被发现并对应到具体字段。
- 页面结构：核对标题层级、链接文字和按钮名称是否能说明用途，不依赖颜色或位置传达唯一信息。
- 缩放与布局：放大文字或缩小窗口后检查内容是否被遮挡，关键操作是否仍可完成。
- 读屏抽查：使用团队常见的屏幕阅读器检查一个关键流程，确认页面名称、控件信息、状态变化和错误提示能被听到。
五、修复后重新跑完整任务
不要只看扫描器问题是否消失。重新完成原先选择的任务，确认修复没有破坏焦点顺序、表单提交、校验提示和手机端布局。AI 生成的替代文字或标签也要回到页面语境核对：描述是否有助于理解当前内容，是否把装饰信息重复读出，是否错误地猜测图片中的产品或人物。
记录问题状态、影响的模板、修复版本、人工复测人和复测日期。后续修改公共导航、表单组件或弹窗时，把相关无障碍用例加入回归检查，避免同类障碍再次出现。
六、把 AI 当作分析助手，不当成验收凭证
AI 适合帮助团队更快读懂扫描报告、生成候选修复方案和补充测试思路。问题是否存在、是否影响用户、是否满足项目要求，仍需结合页面行为和人工证据判断。明确检查范围、保留复测记录，并让使用键盘或读屏的人员参与关键路径验收，才能把自动扫描结果变成真正有用的改进。
