网站无障碍采购与验收：范围、测试和责任

网站无障碍采购与验收：范围、测试和责任的重点不是堆关键词或批量生成页面，而是把业务边界、资料输入、流程交接、验收状态和持续维护做成可检查的执行系统。

直接判断

在直接判断环节，验收团队以WCAG 2.1 AA级为唯一基准，输入您的站点URL、目标用户场景（如纯键盘操作、屏幕阅读器朗读）以及具体的页面清单。我们不依赖模糊印象，而是逐项核对可感知性、可操作性、理解性和健壮性四个原则下的每一项成功标准。工作输出是一份结构化缺陷清单，每条记录包含问题所在DOM位置、对应WCAG条款、严重级级别以及可执行的修改建议。每个问题都会获得明确的审查状态：通过、不通过或需人工复核。若某项不通过，我们会直接标注阻塞项，并给出优先级排序建议；您只需按清单修复后，我们会在下一轮验收中仅对变更区域进行定向回归，确保问题闭环。

除了静态检查，直接判断还包括动态交互验证。这里的具体输入是一组预定义的用户任务，比如通过屏幕阅读器完成表单提交、通过键盘遍历导航菜单、调整浏览器缩放至200%后阅读正文。工作输出是一份交互测试记录，逐条记录操作步骤、实际反馈、预期结果以及是否达到无障碍要求。审查状态分为“自动工具通过”与“人工判断确认”，因为某些视觉焦点顺序或语义标签必须由人工确认才可放行。如果关键任务失败，例如焦点丢失或朗读顺序错乱，我们会立即终止验收并输出失败证据包，同时附上最小化复现步骤；您的开发团队修复后，我们会在同一任务集上执行完整回归，而非只验证单点问题。

适用边界

本节界定网站无障碍验收的适用边界。适合的情形包括：已完成开发并提交验收的企业官网、B2B交易平台、SaaS控制台，以及多语言企业站点（如中外文官网需同步发布无障碍结果）。开始前必须具备的资料包括：绑定 WCAG 2.1 AA 成功标准的可访问性测试清单、真实用户操作路径（键盘操作与读屏路径脚本）、目标浏览器及辅助技术组合的明确列表（如 NVDA、VoiceOver）、自动化扫描工具（如 axe、Lighthouse）的原始输出。组织条件包括：项目负责人能确认每项失败是否属于本次验收边界；测试人员与产品经理共同确认失败项归属；明确第三方插件和纯后台页面是否纳入验收。

不适用于未指定验收范围、无可用测试环境、关键页面仍高频变更、且未指定边界决策人的项目。验收输出按以下交接字段逐项记录：检查项编号、WCAG 成功标准条款、测试输入文件、预期结果、实际结果、状态（通过/失败/未适用/超出边界）、证据截图路径、责任人与修复时限。若失败项属于第三方组件或后台管理页面且已在范围外，则在交付说明中标注原因并转交对应服务商处理；若在边界内，则生成整改工单返回开发团队，在下一迭代修复后重新提交验收。新代码引起的回归失败若影响核心任务则暂停发布；非阻断性失败记录到技术债务清单并设定修复时限；无法复现的失败项需提供录制视频和复现步骤转交基础设施团队。本节只讨论验收边界，不构成对收录、排名或固定修复时效的保证。

输入与证据

采购无障碍验收前，先把证据清单写进合同附件，避免上线后责任不清。页面证据：准备目标页面的网络地址路径与参数标识、页面模板编号、内容管理系统发布记录、抓取日志中的 HTTP 状态码、渲染后的 DOM 快照，以及键盘可达性测试用的页面清单。客户证据：写明使用辅助技术的员工岗位、组织规模、现有合规义务条款、事故报告模板。产品证据：记录版本号、构建编号、无障碍相关可配置开关、已知缺陷列表、第三方组件名称与版本。销售证据：销售过程中对无障碍功能的陈述记录、演示记录、报价单中的交付物。分析证据：埋点事件定义、会话录制时间段、错误日志抽样、键盘焦点轨迹。每一项都要标注来源和采集时间，形成交接字段：证据标识、证据类别、证据名称、采集方法、采集人、时间戳、验收判据。

自动化验收需要输入页面样本清单和测试脚本版本，输出断言结果与失败快照；人工验收需要输入参与者的招募记录、任务脚本、观察笔记和修改建议；持续监测需输入监控指标定义与告警阈值。将上述字段汇总为一张验收交接表：证据类别、证据名称、采集方法、责任人、验收判据、工具、最后更新时间。判据必须可操作，例如“键盘可到达焦点元素覆盖全部交互控件”而不是“体验良好”。如果评估对象是 SHMLANG 这类以中英文网站和 AI 自动化为服务方向的产品，还应把多语言页面和自动生成的元数据纳入证据范围。所有证据需保留原始日志和人工签字记录，作为后续回归测试和年度再审的依据；验收结论以双方认可的判据为准，不附加任何效果承诺。

实施流程

实施流程的第一步，是收集当前网站的全部核心页面、用户操作路径、公共组件清单，并明确无障碍验收的辅助技术基线（如读屏软件版本、键盘操作方式）和 WCAG 2.1 AA 目标。随后，验收人员在测试环境中执行自动扫描与人工走查，输出包含问题严重等级、截图、代码位置、对应失败条款及修复建议的缺陷清单。这个清单作为本轮的工作产品，提交给客户进行评审，并与客户共同确认“阻断、严重、次要”三类问题的验收边界。评审通过则进入修复排期；若评审不通过或发现清单遗漏，我们会重新扩大样本页面范围，补充测试路径，再次形成更新版缺陷清单，直至评审结论明确。

若修复后的版本未能通过验收，我们不会直接放宽通过标准。我们会要求开发团队提供更新后的代码分支和部署环境，然后对全部阻塞项和严重项进行回归测试，并对受影响的功能重新走查。工作产品是二次验收报告，其中记录每一处问题的修复结果、前后对比截图、复测状态；该报告必须通过客户的无障碍负责人确认，才算达到本次验收的完成状态。如果仍存在失败项，我们将其重新列入缺陷列表并提出最小化修复方案，安排下一轮复测；只有所有关键问题关闭且验收报告获签后，我们才会输出最终结论。每轮验收都有明确输入、可核验输出和终止条件，因此不会停在模糊的“部分通过”状态，方便客户继续推进整改或上线发布。

角色交接

网站无障碍验收的结论能否落地，取决于交接时是否把每一项验收状态写成可复核的字段。业务角色负责输入合规范围与用户人群特征，交付验收通过的判断标准；内容角色输入文案与替代文本清单，交付 alt 文本、标题层级和文档格式的核对结果；设计角色输入视觉稿与对比度标注，交付色值、焦点样式和缩放表现的验收记录；开发角色输入代码提交记录与组件实现说明，交付键盘可达性、ARIA 状态和表单错误的测试日志；销售角色输入合同回款节点与客户演示场景，交付演示环境的无障碍检查清单；数据角色输入埋点与监测工具配置，交付基于真实会话的失败操作统计。各角色若只口头说明而未留下字段，验收结论便无法定位到具体页面、组件或文档，后续返工也难以划分责任人。

实际交接时，每条记录至少应包含六项字段：验收对象、验收标准、测试环境、执行人、状态、失败处理。验收对象指向具体的页面、组件或文档；验收标准写明引用的是对比度、语义或键盘规则；测试环境注明浏览器、读屏器和自动化工具版本；执行人是在实际环境中完成验证的人；状态分为通过、失败、待复核；失败处理必须注明是退回、降级还是安排二次验收。例如，某表单的错误提示若屏幕阅读器未读出，状态应为失败，失败处理需写明“补充 aria-live 区域后重新验收”，而不是简单改为已修复。这样交接表才能成为采购、实施和后续监测的共同依据，也让外部审计或内部轮岗时不必重新解释历史结论。

质量验收

我们的无障碍质量验收以具体输入为起点，包括网站目标页面的最新版本源代码、WCAG 2.1 AA级成功准则清单、主流读屏软件（如NVDA和VoiceOver）的实测环境、键盘操作脚本以及自动化扫描工具生成的原始结果。基于这些输入，工作输出是一份结构化验收报告，其中每条问题均标注严重级别、相关准则编号、出现元素选择器及可操作的修改建议，同时附上通过项与未测项的明确状态。审查状态由独立于开发组的质检专员执行二次复核，核对报告中的问题是否真实存在、级别是否被低估或高估，并最终签署“通过”或“退回”意见。如果验收失败，问题清单将立即转交开发团队，要求按严重级别限期修复，修复后重新执行相同输入集的回归测试，直至所有阻断级问题归零且剩余问题获得书面豁免。

对于涉及视觉设计与交互行为的页面，我们还将设计稿标注、动态内容变更说明、用户流程脚本和不同浏览器/设备组合作为具体输入，并将它们与运行时DOM状态一一对照。工作输出是一份逐项勾选的验收矩阵，覆盖对比度、焦点顺序、替代文本、表单提示、状态消息和自定义控件键盘可用性等维度，每一项都包含实际生效后的证据截图与测试步骤。审查状态要求项目经理、开发负责人和残障用户代表共同会签，确认任何未达标项都已纳入风险登记册，并明确负责人与截止日期。如果验收失败，我们不会简单给出负面结论，而是提供一份按优先级排序的整改路径，包括最小可行修复方案和后续的回归验收节点；同时建立每日同步机制，直到所有失败项关闭且验收报告更新为“有条件通过”或“完全通过”。

异常处理

在无障碍验收启动时，客户需提交网站URL、验收标准版本及目标等级等具体输入。系统先执行参数完整性校验；若发现缺项或格式错误，工作输出将返回携带错误代码的异常提示，并将审查状态置为“待人工复核”。此时客户不必自行排查，应联系服务团队并提供请求编号，由工程师修正输入后重新发起验收。若输入完整但页面解析失败或动态内容无法捕获，工作输出会记录失败步骤和原始响应片段，审查状态更新为“需重试”。客户可点击“重新验证”按钮，系统基于上次断点继续处理，从而避免重复提交整个站点。

当验收任务因外部依赖异常（如第三方脚本超时、证书过期）而中断时，工作输出会自动生成异常摘要，列明受影响的功能模块与错误时间戳，审查状态标记为“已隔离”，表示该异常不影响其他已完成项。客户应查看摘要中的技术说明，修复对应资源后提交“复验申请”，并附上更新后的证书链或脚本地址。系统收到后重新排队，完成时输出新的验收结果，审查状态转至“已通过”或“有障碍”。若复验仍失败，任务自动升级为人工介入，由无障碍专家分析日志并给出修复建议，随后安排一次追加复查，确保每个异常都有闭环处置路径。

维护决策

维护决策不是凭感觉拍板，而是基于固定时间窗内的验收输入做分类。每次维护周期至少收集三类输入：自动化扫描结果（对比度、缺失 alt、表单标签、ARIA 使用错误等）、人工抽检记录（键盘可达性、屏幕阅读器朗读顺序、焦点可见性、定时内容可控性）、以及用户侧反馈（通过无障碍反馈通道收集的真实使用问题）。决策输出为五种状态：继续维护、返工、暂停、合并页面、停止投入。建议每两个版本周期或每季度做一次评审，把输入与状态写入维护记录。验收状态字段应包括：页面标识、维护批次号、扫描错误数、人工通过率、阻塞项级别、最近评审日期、维持状态。凡阻塞项为零且人工通过率达到内部约定比例，则继续维护；出现任一级别为 P1 的阻塞项（如表单无法键盘提交、焦点被陷阱困住），则返工；若页面访问量低且无障碍问题持续复发，则合并到替代页面，合并前保留重定向映射；若产品线停止迭代且无用户反馈流入，则停止投入，但需保留历史验收记录供审计。所有状态变更都要在交接字段中写明触发原因、执行人和复审日期，避免后续维护者重复做无效实验。
实操中，维护决策还需要一个可执行的交接字段，建议至少包含：页面唯一 ID、维护对象版本、检测工具及版本、扫描时间戳、人工测试环境（浏览器/读屏器组合）、通过/失败证据链接（若允许留存内部缺陷系统编号）、失败步骤与预期结果、决策状态（继续/返工/暂停/合并/停止）、决策依据说明、下次评审日期。处理失败时不要直接清零重来：先把失败用例转成回归测试清单，再决定返工范围；若同一页面连续两个周期出现同样的 P1 问题，则暂停该页面投入，转入根因分析，根因未解决前不重复返工。若选择合并页面，合并后的目标页面必须重新走一遍无障碍验收流程，不能在原问题未关闭时就宣称收尾。停止投入的标准不是“无人抱怨”，而是连续三个周期无用户反馈、无自动化新增错误、且无业务需求变化；即便如此，也应保留对外承诺的无障碍支持渠道，不删除已发布的验收声明。

下一步

如果你正在评估网站无障碍验收，可以先整理现有页面、资料、工具和交接方式，做一次小范围诊断。