无障碍审计：找出 HTML 障碍，再验证真实操作流程

从重要任务开始

选择一个具体流程，例如申请报价、创建账户、阅读规格或联系支持。记录准确的 URL、页面语言和预期完成结果。同时说明页面是否公开，还是需要登录。公开页面的审计不能验证登录后的完整操作流程。

先检查一个有代表性的页面，再分别检查其他模板。共享导航中的缺陷可能影响许多页面；首页没有警告，并不能说明订单表单或弹窗可用。应优先解决阻碍任务完成的问题，再处理外观整理。发现的严重程度应根据使用情境及其实际影响判断，而不能仅由分数决定。

理解实际测量了什么

目前 Sitelemetry 的检查引擎分析一个页面的静态 HTML。检查内容包括图片缺少替代文本、文档标题或语言缺失、可能没有标签的表单字段、没有名称的链接或按钮、标题顺序问题、缺少主要区域、正值 tabindex 和重复 ID 等。部分检查属于启发式判断，需要进一步确认。

引擎也检查部分内联颜色组合，但这不是完整的对比度评估。继承的 CSS、背景图片、叠加层和交互状态可能不在范围内。抓取失败、中间验证页面、内容截断或非 HTML 响应会导致评估不可用或不适用，而不表示通过无障碍检查。W3C 的工具选择指南解释了为什么仍然需要人工判断。

分配修复任务前先读证据

可执行的修复任务应注明 URL、受影响元素或示例、待验证行为，以及可能被阻断的任务。“三张图片缺少 alt”比“改善无障碍”更具体。但替代文本存在，并不证明它正确描述了图片的作用。

请在浏览器中确认有歧义的发现。静态模式可能漏掉包裹输入框的标签，也可能接受指向不存在元素的 aria-labelledby。应在无障碍树中查看实际计算出的名称。标题顺序警告也需要结合内容审阅，不能直接当作对全部 WCAG 要求的判决。对于重复出现的问题，应按共享组件归类，而不是逐页孤立修补。

修复源头组件

优先使用原生 HTML 控件和可见标签。显式关联时，for 必须指向正确字段的 ID。占位文字会在输入过程中消失，不能替代可靠的标签。W3C 表单标签教程说明了适当的关联方式。对于只有图标的按钮，应使用“打开搜索”这类描述操作的名称，而不只是说明图形本身。

根据图片的目的决定替代内容：传达信息、触发操作，还是纯粹装饰。功能性图片需要恰当的替代文本；纯装饰图片可以使用空替代文本。不要为了消除警告而把所有文本清空。参考 W3C 图片教程，修复组件或内容模型，避免新增内容继续重复同类问题。

补充浏览器检查

1. 仅使用键盘到达并激活控件。确认焦点可见、移动顺序合理，并能退出对话框。
2. 使用屏幕阅读器检查标题、名称、说明和错误。重点是能否理解任务，而不只是有没有文字被读出。
3. 测量正常、悬停、聚焦和错误等相关状态的对比度，同时检查图片和叠加层。
4. 测试放大显示及狭窄视口，寻找消失的控件和难以使用的滚动方式。

这些是补充使用测试，不是声称静态引擎已经执行的能力。W3C 初步检查可以作为起点。根据服务的重要性，邀请具有不同访问需求的用户参与验证。

复测并记录剩余范围

修改后，在同一 URL 上重新运行审计并比较具体证据。共享组件是否已修复？是否引入新的名称或结构问题？同时重复最初选择的手动流程。如果警告消失了，但对话框依然无法用键盘操作，就不能认定修复完成。

记录日期、页面和修改内容，并分别列出静态与手动结果。在面向客户的报告中，说明检查过哪些模板和交互，以及哪些不在范围内。分数既不是能够成功操作的用户百分比，也不是法律证明。保留尚待执行的手动检查，并把关键流程纳入后续发布前的检查。