文字转语音与屏幕阅读器：有什么区别？

您的内容拥有声音

文字转语音（ TTS ）技术将书面信息转换为音频。它帮助失明、视力障碍、阅读障碍和 ADHD 人群以适合自己的方式获取内容。 TTS 还广泛用于学校、被语言学习者以及那些靠听而非靠看来校对的专业人士所使用。

由于 TTS 和屏幕阅读器都会发出合成语音，人们常常以为它们是同一回事——或者以为在网站上加一个「朗读」按钮就能让盲人用户无障碍访问。这种假设是错误的，照此行事会让您得到一个听起来无障碍、但许多人实际上根本无法使用的网站。本文将解释每种技术如何工作、谁依赖它、二者之间的界线究竟在哪里，以及要正确地为屏幕阅读器进行开发需要什么。如果您只记住一件事，请记住这一点：朗读小部件是一项便利功能，而非无障碍功能。

TTS 如何工作？

TTS 大致分三个阶段处理文本：

• 文本分析——判断语气、语法和结构，展开数字和符号（「 5 美元」变成「五美元」），并对句子进行切分。
• 语言处理——计算发音、重音和强调，通常使用发音词典外加针对生僻词的规则。
• 音频合成——根据数学语音模型生成语音，越来越多地使用神经网络，其听感远比旧式拼接引擎自然。

现代系统提供语音定制，例如语速、音调、语音人设和语言选择。关键在于 TTS 接收什么作为输入：一段有人已经选中、粘贴或指向它的文本。 TTS 从根本上说是一种内容输出技术。它念出给它的内容。它不会探索界面，也没有按钮、表单字段或页面结构的概念。

TTS 技术有哪些局限？

TTS 确实有用，但并不完美，而它的局限对接下来的对比很重要：

• 发音欠缺——它可能会把不常见的词、专有名词、医学或法律术语以及缩写念错。
• 语言支持不均衡——许多工具能很好地处理主流语言，却在较冷门的语言和地区方言上吃力。
• 语气和细微差别——TTS 难以处理讽刺、幽默和习语表达，因此内容可能以错误的语气被传达出来。
• 没有交互模型——这一点最关键： TTS 只是朗读；它不让您做任何事。仅靠 TTS，您无法填写结账表单、关闭模态框，也无法在菜单项之间移动。

正是这最后一个局限，引出了与屏幕阅读器混淆的开端。

文字转语音与屏幕阅读器技术有什么区别？

这正是常见误解产生的地方。文字转语音把文本念出来——这是它的主要功能。屏幕阅读器做的远不止于此：它让用户能够通过听觉和键盘（或触摸手势）来导航和操作整台电脑或移动设备。

屏幕阅读器会播报界面标签、表单字段、按钮和链接；它会读出图像的替代文本，让用户理解视觉内容；并且它会公开组件的状态——复选框是否被勾选、菜单是否展开、标签页是否被选中，或者是否出现了错误。它们把视觉的、靠鼠标驱动的界面，变成线性的、可听见的、可操作的界面。

快速体会这种区别的方法： TTS 回答的是*「这段话说了什么？」这个问题。屏幕阅读器回答的是「我在哪里、我在这里能做什么、刚才发生了什么？」*前者关乎获取内容。后者关乎控制软件。

屏幕阅读器用户实际上如何浏览页面

视力正常的用户能在几秒内扫视一个页面。屏幕阅读器用户则按顺序构建心智模型，并依靠结构来高效移动。实际操作中，他们会：

• 在标题之间跳转以理解页面大纲（这正是正确的标题层级如此重要的原因）。
• 调出所有链接或所有表单字段的列表，按地标导航而非自上而下地阅读。
• 使用地标区域（横幅、导航、主内容、页脚）直接跳到他们想要的内容。
• 用 Tab 键在交互元素之间移动，并期望焦点落在可见且合乎逻辑的位置。
• 在某些内容无需整页重新加载就发生变化时，留意实时播报。

除非底层标记如实地描述页面，否则这些都无法实现。「朗读」功能不提供任何这些导航便利——它只是按视觉顺序念出屏幕上的任何文本，无法操作控件。

谁使用哪种技术，以及为何这很重要

TTS 被广泛的人群使用，往往因情境而异：阅读障碍、 ADHD 或低视力人群；一心多用的人；语言学习者；以及任何单纯偏好听的人。这些用户大多仍能看见屏幕并使用鼠标。

屏幕阅读器用户包括失明者或有严重视力障碍的人，以及一些有认知或运动障碍的人，他们依赖这项技术才能使用设备。对他们来说，它不是叠加在可用界面之上的偏好层——它就是界面。最常见的工具是 Windows 上的 NVDA 和 JAWS、 Apple 设备上的 VoiceOver，以及 Android 上的 TalkBack。每一款对同一个网页的解读都略有不同，这也是跨工具测试很重要的一个原因。

为什么朗读小部件无法替代无障碍

越来越多的网站加装了「收听本页」按钮或第三方小部件，用来高亮并朗读文本。这些工具能帮到一部分读者，作为一项便利提供它们也无可厚非。问题在于把它当作真正屏幕阅读器支持的替代品。出于几个具体原因，它并不是。

• **它们只朗读，不操作。**朗读小部件会念出您的价格表，但无法让盲人用户选择套餐、打开购物车、输入支付信息并完成购买。真正的任务需要可操作的控件，而不是朗读。
• **它们无法公开状态或角色。**按钮是否被按下、字段是否必填、区块是否折叠，或是否刚刚出现了错误消息——这些都无法通过朗读可见文本来传达。屏幕阅读器依靠标记中的角色、名称和状态来播报它。
• **屏幕阅读器用户已经有了工具。**盲人用户自带屏幕阅读器，已经针对自己的偏好和肌肉记忆精细调校过。页面级小部件会与之竞争，有时还会干扰它，而且对它们的屏幕阅读器卡住的损坏标记毫无修复作用。
• **它们掩盖问题，而非修复问题。**如果某个表单字段没有标签，小部件会像屏幕阅读器那样直接跳过它——但现在缺失的标签被藏在了一个看起来有帮助的功能后面。底层缺陷依然存在。

同样的逻辑甚至更强烈地适用于所谓的无障碍叠加层（ overlays ）——这些脚本承诺通过在现有网站上叠加自动化修复和一个工具栏来实现即时合规。它们不修复底层代码，经常与用户自己的辅助技术冲突，也无法实现真正的合规。可靠的途径是修复源头。关于为何表面修复力有不逮的更完整解释，请参阅我们关于真正的数字无障碍的指南。

一个具体例子：会「说话」的结账流程

设想一家网店加了一个朗读小部件，并自信地认为网站现在已经无障碍了。一位盲人顾客带着自己正在运行的屏幕阅读器到来。商品描述读起来没问题——那部分只是文本。但「加入购物车」控件是一个带有点击处理程序、经过样式化的 div，而不是真正的按钮，所以屏幕阅读器从不把它播报为按钮，键盘也无法到达它。数量选择器在没有实时区域的情况下更新总价，因此这一变化是无声的。促销码字段有占位符文本但没有关联标签，所以只被播报为「编辑文本」。配送表单在视觉上显示一处红色错误，但该错误没有与字段关联，根本不会被播报。朗读小部件欢快地念出可见的文本，对这一切毫无改变。顾客能听到营销文案，却无法完成购买。这一鸿沟——在听到内容与操作产品之间——正是便利功能与无障碍之间的全部区别。

为屏幕阅读器进行开发究竟需要什么

支持屏幕阅读器不在于添加一项功能——而在于构建您的页面，使含义、结构和行为对软件可用，而不仅仅对人眼可见。核心要素：

语义化、结构化的 HTML

按逻辑顺序使用真正的标题（ h1–h6 ）、为正确目的使用原生按钮和链接、用列表表示列表、用地标元素表示页面区域。语义化 HTML 免费携带无障碍信息；一堵由通用容器堆成的墙则什么都不携带。

非文本内容的文本替代

每一张有意义的图像都需要准确的替代文本，而装饰性图像应被标记为可跳过。充当按钮的图标需要可访问的名称。图表和信息图需要传达相同信息的文本等价物。

可访问的名称、角色和状态

表单字段需要以编程方式关联的标签。自定义组件——标签页、手风琴、组合框、模态框——需要正确的角色和状态，以便屏幕阅读器播报它们是什么以及如何运作。在原生 HTML 不够用的地方，ARIA 可填补空缺，但必须精确使用；错误的 ARIA 比没有 ARIA 更糟。

键盘可操作性与焦点管理

凡是能用鼠标完成的，都必须能用键盘完成，焦点顺序必须合乎逻辑，焦点指示器必须可见，而动态变化（打开对话框、显示错误）必须恰当地移动或播报焦点。键盘支持与屏幕阅读器支持深深交织在一起。

播报动态变化

当内容无需重新加载页面就更新时——表单验证消息、购物车计数器、加载状态——请使用实时区域，让屏幕阅读器告诉用户发生了某事。无声的更新对看不见屏幕的人来说是不可见的。

所有这些要求都被编入了 WCAG 2.2 的成功标准，而这些标准构成了 European Accessibility Act 以及应用于网络的 ADA 的技术骨干。如果您想要实操细节，我们的屏幕阅读器测试指南会逐步带您了解如何用真实工具验证这些行为中的每一项。

为什么「我这边读得挺好」具有误导性

视力正常的开发者可以打开朗读功能，听到干净的句子，进而断定页面是无障碍的。陷阱在于，朗读再现的是可见的阅读顺序和可见的文本，而这两者对看着屏幕的人来说本就讲得通。它丝毫不能说明：自定义下拉菜单是否播报它的选项、焦点是否被困在打开的对话框内、纯图标按钮是否有名称，或者 Tab 顺序是否与视觉布局一致。这些恰恰是对屏幕阅读器用户失效的东西，也恰恰是朗读演示无法揭示的东西。要知道答案，唯一的办法是像真实用户那样测试。

如何对二者进行测试——以及为什么仅靠自动化还不够

您无法通过听一个朗读按钮来确认某个页面对屏幕阅读器用户可用。您需要通过检查结构、名称、角色、状态、键盘操作，以及跨多种工具和平台的实际屏幕阅读器体验来确认它。

一套稳健的流程结合三个层次：

• 自动化扫描，用以捕捉数量庞大、可被机器检测的问题——缺失的替代文本、空标签、损坏的 ARIA 引用、对比度不达标。我们的无障碍扫描软件和免费无障碍扫描是快速摸清现状的途径。
• 专家人工测试，用以评估自动化无法判断的一切：某个名称是否有意义、焦点顺序是否合理、自定义小部件是否真正可操作。这一层背后的道理在我们的人工无障碍审计指南中有所阐述。
• **使用真实辅助技术和真实用户进行测试。**没有什么能替代用 NVDA、 JAWS、 VoiceOver 和 TalkBack 实际驱动页面——并且最好观察那些每天使用这些工具的人。我们的由残障人士进行的审计带来的正是这种亲身经验。

自动化工具通常只能检测 WCAG 2.2 成功标准中的一部分；其余部分需要人的判断。把通过的自动化扫描当作无障碍的证明，与把朗读小部件当作屏幕阅读器支持，属于同一类错误。

QualiBooth 的定位

QualiBooth 同时针对 TTS 和屏幕阅读器的使用场景测试您的网站，让依赖其中任一技术的用户都能无障碍获取您的内容——并让那些依赖屏幕阅读器的人不仅能听到您的内容，还能真正操作您的产品。我们的无障碍工具包和 Agora 平台将扫描与结构化的人工审查相结合，我们的无障碍咨询团队会帮助您修复测试所揭示的问题，并满足 WCAG 2.2、 EAA 和 ADA 的要求。

结论很简单。为您的内容增添声音是一个不错的点缀。让您的内容可导航、可操作、并被正确地播报给屏幕阅读器，才是无障碍——而其中只有一项能同时满足法律以及它所保护的人。