语音合成上线前，先过十五项无障碍验收

一段自然流畅的 AI 语音，可能把产品名念错，把 15 念成 50，也可能漏掉一句「不要」。对依靠听觉使用产品帮助的人来说，声音悦耳只是起点，信息正确、操作可控才决定功能能不能用。

作者提出了一套 15 项验收方案，把选型对象从「哪个声音更像真人」改成「哪条收听路径能帮助用户完成任务」。它适合给产品朗读功能做第一轮验收，但原文没有实际生成音频、招募参与者或测出供应商排名。

你要买的是声音，还是一条能用的收听路径

作者建议先确定任务。静态帮助文章可以提供关联音频文件；内容频繁更新，或用户需要选择段落朗读时，再考虑服务端或浏览器按需生成。W3C 的 G79 技术说明提到了这些方式，但它是参考性技术，不是强制方案，也不能给某个 TTS 产品颁发认证。

完整路径包含发现入口、主动播放、听懂内容、暂停续播、返回文字，以及生成失败后继续获取信息。只比较声音样片，会漏掉其中大半。

音频应该是可选的信息交付方式，文字页面仍要独立可用。

语义化标题、图片替代文本、键盘操作和清晰的页面结构都要保留。MP3 修不好没有名称的按钮，也补不了只存在于图片里的说明。

播放器还要与用户已有的屏幕阅读器共存。WCAG 2.1 成功准则 1.4.2 针对自动播放超过 3 秒的音频，要求提供暂停、停止，或独立调节音量的方式；它检查的是音频控制，不证明内容准确或容易听懂。作者因此建议避免自动播放，并清楚呈现播放、暂停、加载和失败状态。

15 项验收，分别在拦什么错误

这套方案包含 12 项内容与使用场景检查，以及 3 项播放器检查。15 是用例数量，不是参与人数、供应商数量或调用次数。

前 12 项可以按风险理解：

• 指令意义：普通条件句、包含「不要」「除非」「仅当」的否定句，以及带从句的长句，检查动作、条件和停顿是否保留。
• 名称与数值：两个内部产品名、一个姓氏，以及日期、参考编号、15 和 50 等相近数字，还有价格、小数、百分比和单位，检查用户能否准确复述。
• 语言与结构：真实缩写、受地区影响的词语、混合语言段落、表格或列表，检查读法是否符合预期，以及标签与数值能否对应。
• 内容与位置：修改一句话后检查音频是否同步；播放中暂停，离开再返回，检查续播位置是否正确。

另外 3 项直接测试界面：全程只用键盘完成播放操作，开启屏幕阅读器时不发生语音争抢，以及模拟超时或请求被拦截后，页面仍可阅读、错误能被理解、用户能够重试。

数字测试有个很实用的细节：先让听众写下听到的值，再展示原文。提前给出答案，容易把「是否听懂」变成「是否觉得听起来差不多」。

作者还要求用真实产品内容替换示例，但测试数据应当是合成数据或经过批准的数据，不能为了试读账户号码就上传客户记录。涉及自定义或可识别声音时，也应说明其合成属性和使用来源。

这只是起步集合。语音对话、实时通话延迟、噪声环境、各浏览器下的屏幕阅读器导航、临床或紧急指令，以及声音克隆和相关权利问题，都没有被这 15 项覆盖。

为什么榜单不能直接变成上线结论

自然度、可理解性和响应速度是不同指标。

原文引用的 TTS Arena 是匿名声音偏好比较，介绍中的提示词仅限英文，长度上限为 1,000 字符。它可以帮助缩小候选范围，却不检查你的产品名、混合语言、键盘操作，也不验证用户有没有听懂具体指令。

2025 年 Interspeech 的一项研究比较了五个 TTS 系统对数学表达式的朗读。不同系统、表达式类别的可理解性存在差异，多数类别显著弱于专家朗读。这能支持「普通文章表现好，不保证结构化内容也好」，不能推出所有当前商业产品都存在同样差距。另一项 2025 年开源 TTS 响应性研究也把延迟和可理解性分开处理。

测试时应冻结文本、语言地区、声音配置、模型版本、输出格式、设备、浏览器、可配置的采样率和网络条件。同一套内容交给每个候选，条件允许时每段生成两次，再用随机编号隐藏供应商。

评价分两步：先记录金额、下一步动作等任务答案，再询问清晰度和收听负担。重播次数也要记录。参与者应包含符合目标用户特征、实际使用辅助技术的人，但小规模内部测试不能据此宣称具有统计代表性。

上线判断先检查关键错误，再看偏好。作者给出的条件是：关键用例全部通过、任务成功达到预设要求、控制通过、降级方案可用。内部排序可以采用关键意义 3 分、理解与发音 2 分、偏好与工作流 1 分，但这些权重只是排查优先级，不是研究结论。

下面这段代码用于汇总用例，并在门禁不通过时抛出错误：

function releaseDecision(cases) {
  const criticalFailures = cases.filter(
    item => item.severity === "critical" && item.status !== "pass"
  );
  const controlFailures = cases.filter(
    item => item.kind === "control" && item.status !== "pass"
  );
  const completed = cases.filter(item => item.status === "pass").length;
  const unresolved = cases.filter(item => item.status === "needs-review").length;

  return {
    ready: cases.length === 15 && criticalFailures.length === 0 &&
      controlFailures.length === 0 && unresolved === 0,
    completed,
    criticalFailureIds: criticalFailures.map(item => item.id),
    controlFailureIds: controlFailures.map(item => item.id),
    unresolvedIds: cases.filter(item => item.status === "needs-review").map(item => item.id)
  };
}

const result = releaseDecision(testResults);
if (!result.ready) throw new Error(JSON.stringify(result, null, 2));

要看清 ready 这一行：它要求有 15 条记录，关键失败、控制失败和待复核项均为零，却没有要求 completed === 15。普通非关键项失败仍可能返回通过，代码也没有实现团队自己的任务成功阈值。接入项目时，需要补上这部分政策。

我的判断

作者最有价值的取舍，是把「听起来如何」和「用户理解得对不对」拆开。这对金额、否定条件、步骤顺序尤其重要。语音识别转写可以辅助找遗漏，但转写正确不代表人听得清楚；真人觉得自然，也不代表金额正确，两种检查应当互补。

不过，这是一份验收设计，不能被引用成某家模型已经通过验证的证据。 原文没有供应商对照数据，也没有证明 15 项足以覆盖某类用户。社区里关于语速、夹带语句和语言切换的反馈，同样只能提供测试线索，不能估算故障发生率。

外围材料也要守住范围。美国人口普查的 9.3% 指的是 2020–2024 年美国 65 岁以下人群的残障统计，不能推算国内 TTS 需求；Ofcom 的英国媒体研究、Forrester 2024 年关于残障用户反馈的文章，以及 Bain 2019 年服务中心分析，都不能替代产品实测。

采购比较还应包含现有屏幕阅读器、人工录音、浏览器朗读或当前供应商。只拿新功能和「没有音频」比较，很难知道它是否改善了现有体验。成本也要算上词典维护、人工审核、内容更新后重生成、存储分发和故障支持，原文没有数据证明哪种方案更便宜。

能拿来做什么

• 给前端朗读入口建立固定验收页，覆盖键盘焦点、状态名称、主动播放、屏幕阅读器共存和请求失败，让播放按钮之外的路径也进入检查范围。
• 给 Node 音频生成流程关联内容修订号、模型和声音标识、语言及生成配置。文章更新后使旧音频失效或重新生成，避免用户听到过期说明。
• 维护一份来自真实帮助内容的固定用例，保存原文与 TTS 预处理文本的差异。标点、发音词典或语言标记调整后，复核每条指令、数字和限定条件。
• 在试点前确定基线和通过阈值；供应商更新模型、声音、语言包或音频归一化设置后，重新验收。若无法获知版本变化，就保留固定输入输出样本，按团队能承担的频率复测。