企业网站无障碍验收：标准、任务与证据

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

直接判断

判断是否值得做。企业网站无障碍不是“加分项”而是采购与上线门禁的一部分。值得做的判断依据是：采购方是否要面向公共服务、是否接受政府或行业合规检查、是否有真实用户（视力障碍、行动障碍）申诉渠道。在这些条件下，它解决的是“可访问性验收不清楚导致返工和诉讼风险”的业务问题。判断时至少检查三个输入：目标合规标准（如 WCAG 2.1 AA）、实际页面范围和使用的辅助技术组合（读屏、键盘、放大软件）。交付物是“无障碍验收记录单”，其中包含检查字段、测试结果、环境版本和复查日期。验收状态分为通过与未通过，未通过时必须提交修复工单并附缺陷截图、修复前后差异描述和复验人签名。失败处理：如果修复超过两次仍失败，则停止该页面上线，转交开发负责人重新评估实现方案，而不是继续打补丁。

哪些承诺不能给。作为交付方，不能承诺“一次通过某认证机构审计”，因为认证流程由第三方控制；不能承诺“无障碍修复后搜索排名必然上升”，这既没有官方依据，也与生成式引擎优化（GEO）无直接关系。也不能承诺“用某插件即可全站自动达标”，因为动态交互、焦点管理、表单错误提示仍需人工检查。可以承诺的是：每轮测试前提供具体输入（页面 URL、浏览器版本、读屏软件和版本、键盘操作路径）；测试后交付可复现的缺陷列表和 JIRA 工单编号；修复后提供复验记录。交接字段至少包括：检查项编号、测试日期、测试人员、环境标识、通过/失败、失败原因、修复工单号、复验日期、复验结果。这些字段必须跟随上线 checklist 一起签字，否则不进入发布流程。这个判断适用于 SHMLANG 双语网站开发服务中的网站交付语境，不构成对任何第三方审计结果的预测。

适用边界

企业网站无障碍改造是否适用，取决于产品是否面向政务、金融、医疗等受监管行业，或是否以规模化内容触达包括视障、听障、认知障碍用户在内的广泛受众。适合企业通常具备三个条件：一是有明确的合规或社会责任目标，而非把无障碍当作营销卖点；二是内容生产流程已文档化，发布渠道可追踪变更；三是已有至少一个负责体验或质量的角色能跟进缺陷修复。不适合企业则表现为：产品以临时活动页为主、生命周期短且无维护预算；站点用集中式页面构建器批量生成，缺乏对焦点顺序和语义结构的控制；或者团队无法在发布前完成键盘与读屏验证。需要强调，无障碍不是一次性改造，而是发布流程中的持续门禁。

开始前必须具备的资料包括：站点地图与页面模板清单、表单与交互组件清单、媒体资源来源列表、现有色彩与字体规范，以及发布权限链。组织条件上，需要确定一个负责人（例如前端开发或产品经理）对缺陷修复有最终裁定权，并设定“不通过不上线”的发布闸门。可执行的交接字段应至少包含：页面URL、模板类型、键盘操作路径（从进入页面到完成主要任务的Tab顺序）、焦点可见性证据（截图或录屏）、表单标签与错误提示说明、非文本内容替代文本、对比度测试值（前景与背景色号及比例）、辅助技术测试设备与版本、缺陷清单及修复优先级、复核人签名与日期。这些字段应进入每次发布的验收清单，与需求单、测试记录一起归档，形成可追溯的证据链。需要说明，复验合格只证明该次发布状态，不构成对未来改版的持续保证。若团队无力维护该门禁，则说明该企业暂不适合引入本方案，可先缩减范围再推进。

输入与证据

我们的无障碍审查流程以三类明确输入为起点：您提供的网站访问地址、您指定的目标用户场景（如键盘操作、屏幕阅读器、低视力模式），以及您企业内部适用的无障碍标准版本（如WCAG 2.1 AA或中国国标GB/T 37668）。在收到这些输入后的两个工作日内，我们输出一份可执行的无障碍审计清单，其中每一处问题都标注了对应的WCAG成功标准、失败示例截图、受影响的前端代码片段，以及修复优先级。审查状态通过共享任务面板实时呈现，分为“待验证输入”“扫描中”“人工复核中”“证据已生成”四个阶段。若输入信息不完整或无法访问，我们会立即在面板中标注缺失项，并通过预留的联系方式通知您补充资料；若超过五个工作日未补充，本次审查将自动暂停，已生成的部分证据仍会保留供您下载。

在证据生成阶段，我们不仅输出问题清单，还会为每条结论附上完整的复现路径：使用的设备型号、浏览器版本、辅助技术类型（例如NVDA或VoiceOver）、操作步骤和实际表现与预期表现的对比。每一条证据都经过至少两位无障碍专家的独立复核，并在报告中明确标记“通过”“需人工确认”或“不通过”。如果您的团队对某条证据存在异议，您可以在证据库中直接发起申诉，我们会在三个工作日内重新执行该场景的测试，并更新审查状态至“已复议”。若最终因您的网站本身处于维护状态或页面被登录墙拦截导致无法提供完整证据，我们会输出一份“证据缺口报告”，列出未能验证的页面URL和原因，同时提供可用的临时访问配置建议，以便您调整后重新启动验证。

实施流程

实施从现状审计开始。具体输入包括：企业现有网站的完整页面清单、关键用户任务流（如注册、咨询、购买）、前端代码库（HTML/CSS/JavaScript），以及使用自动化工具（如axe、Lighthouse）生成的初步扫描结果。工作输出是一份无障碍差距报告，其中逐条列出与WCAG 2.1 AA标准不符的问题，并给出按业务影响排序的改造优先级。审查状态为：该报告须经企业方代表与无障碍顾问共同评审，确认所有问题已被识别、优先级合理。若评审失败（例如发现核心流程未覆盖或问题描述不清晰），则需返回审计阶段补充缺失页面或细化用户路径，重新生成报告后再审，直至双方签署确认。

随后进入改造与验证阶段。具体输入包括：已确认的差距报告、批准的技术方案、前端开发团队提交的修复代码，以及用于测试的辅助技术环境（包括屏幕阅读器、键盘导航和屏幕放大器）。工作输出是已完成改造的网站版本，附带完整的测试记录和一份WCAG合规声明，说明每项成功标准的验证方式。审查状态为：由独立测试人员（包括使用辅助技术的用户）执行验收测试，覆盖所有高优先级流程。若验收失败（如发现键盘焦点丢失或表单标签缺失），则开发团队须在限定工作日内修复，并再次提交测试，重复此循环直到所有阻断性问题清零。只有通过验收的版本才会被部署到生产环境，同时保留回滚方案以应对上线后的突发问题。

角色交接

在无障碍采购与上线门禁中，角色交接必须落到具体输入与交付物，而不是口头说明。业务负责人先提交站点目标、核心任务清单和允许的无障碍合规基线，作为其他角色的交接前提；内容编辑随后交付带替代文本字段的文案模板，并标注哪些文本用于按钮与提示；设计师提交焦点顺序图、对比度检查值和表单错误状态设计稿；开发工程师依据这些输入完成语义化标记、键盘操作和ARIA状态实现；销售或客户成功人员提供第三方插件清单及真实用户路径，确认插件不阻断键盘；数据人员则定义事件埋点、匿名化规则与报告口径。每个角色都必须在交接单上填写“输入已就绪”或“输入缺失”，缺失即阻止下一环节开始。

交接单至少包含角色、输入、交付物、验收状态、责任人、截止时间六个字段。验收状态只能取“通过”“带条件通过”“不通过”三值；带条件通过必须附带解除条件与复验日期，不通过则触发补救工单并回到上一角色。交付物如设计稿缺少键盘焦点顺序，开发角色不得开始编码；开发产物中没有语义化landmark或焦点可见性实现，销售角色不能向上线评审提交页面；数据角色未提供匿名化规则，则运营角色不能使用分析事件做上线判断。每次交接都附缺陷清单、修复记录和复验截图，由业务角色做最终签字确认。若无签字，门禁不关闭。

质量验收

质量验收要盯住可观察状态，而不是截图或主观印象。键盘操作方面，检查焦点是否能按预期顺序移动、是否能看到明显焦点框、是否出现焦点陷阱；语义方面，检查标题层级、列表、Landmark和按钮是否被辅助技术正确读出；对比度方面，检查正文和表单提示在正常与放大下的文本是否清晰；表单要有明确label、错误提示和焦点回馈；媒体要提供替代文本或字幕，且能被键盘控制。每一项都对应一个可复现的操作步骤和预期结果，验收时逐条记录“通过/未通过”，并把未通过项按严重程度登记，附上浏览器、操作系统和辅助技术组合。

上线前完成修复不代表验收结束。需要把缺陷、修复和复验证据作为交接字段写入项目归档：例如缺陷编号、对应WCAG成功标准、发现日期、复验日期、验证人、所使用的辅助技术组合、操作路径以及最终结论。上线后应设置一段观察期，用与验收时相同的检查脚本抽查关键流程，例如下单、注册和登录，确认发布环境没有引入回归。如果后续内容频繁更新，应定期重跑同一套验收记录，而不是每次重新评审。质量验收的价值在于留下可追溯的状态记录：哪些问题已验证、由谁验证、用什么方法验证，这样采购方和开发方都能依据同一份证据做决策，而不是依赖口头承诺。

异常处理

针对企业网站无障碍异常处理，我们以无障碍检测报告中的错误列表、WCAG 2.1 AA 合规等级、目标页面 URL、浏览器与读屏软件组合、用户操作路径作为输入，生成包含异常类型、触发元素、问题代码片段和影响范围的异常处理工单。工单输出包括可执行的问题定位说明、修复补丁建议及对应的回归测试清单。每张工单进入评审状态后，由无障碍测试人员标记为“待验收”“已修复”或“回归未通过”。如果状态为“回归未通过”，团队应回滚本次修复变更，保留原异常记录与测试证据，并在 48 小时内重新提交修复方案；修复完成后需再次进入验收评审，直到状态变为“已修复”方可关闭。

对于来自客户提交的反馈和内部巡检发现的异常，我们要求输入包含复现步骤、期望行为与实际行为、浏览器版本和辅助工具版本、业务影响描述。处理时输出异常根因分析报告、针对性修复措施和用户验证说明，并统一录入异常处理台账。台账中的每条记录都必须有明确评审状态：待处理、处理中、已解决、终验通过；如果终验不通过，责任人需重新分析输入信息，补充必要的设备或测试样例，并在下一次评审前提供更新后的修复方案。所有异常记录在关闭前必须保留完整的操作日志和状态流转记录，以确保企业网站的无障碍合规工作可审计、可追溯。

维护决策

维护决策不应在每次巡检后临时拍板，而应设置固定的复查门禁，以“修复状态”“回归结果”“残留风险”三个字段作为继续投入的依据。若缺陷列表已按严重度登记，关键路径的键盘操作与焦点顺序通过验收，表单控件具有可见焦点和可读标签，对比度不足的项目已列入修复队列，且媒体无自动播放或已提供替代文本，便具备继续维护的条件。反之，若同类无障碍缺陷在相邻两个复查周期反复出现，说明根因未处理，本次决策应为“返工”：回到开发阶段，重检组件库与模板语义，而不是在原页面上继续叠加补丁。

当出现“无固定负责人”“缺少可复用的测试基线”“缺陷单超过单次修复容量”或“频道页与旧版页面并存”时，应选择暂停投入，先完成页面盘点与合并。对长期无访问价值且承担无障碍风险的页面，可停止维护并归档；但归档前必须把重定向与替代入口写入交接字段。交接字段应至少包括：页面URL标识、产权所属、最后测试日期、已关闭缺陷数、未关闭缺陷及严重度、回归测试脚本、负责人。只有这些字段在采购与上线门禁中齐备，暂停或合并决策才会留下可审计记录。此处不把某个平台当作唯一方案；任何企业网站都应在供应商合同中写明这些字段。

下一步

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