屏幕阅读器预览,免费
粘贴 HTML 以查看屏幕阅读器如何线性化并朗读它。检查您的 alt 文本、标题和 ARIA 属性。
屏幕阅读器输出
📚 学术基础与来源
此工具适用的人群
屏幕阅读器是盲人或严重视力障碍人士必不可少的辅助技术。根据世界卫生组织《世界视力报告》(2019),全球至少 22 亿人存在视力障碍,其中约 4300 万人为盲人。WebAIM 屏幕阅读器调查(2024)一贯发现绝大多数屏幕阅读器用户为残障人士,其中失明是最常见原因。开发者、设计师和内容创作者使用此工具预览辅助技术如何理解他们的 HTML · 帮助在终端用户遇到之前发现缺失的替代文本、错误的标题结构、无可访问名称的按钮和字段,以及 ARIA 使用错误。
此工具如何工作
此工具通过浏览器原生的 DOMParser 分析您的 HTML(没有数据离开您的设备),然后遍历无障碍树以构建线性化的阅读顺序。它检查图片是否有替代文本、标题层级是否一致、链接和按钮是否有可访问名称、ARIA 角色和标签,以及没有关联 label 的表单字段。
学术参考
- WebAIM (2024).「Screen Reader User Survey #10 Results.」webaim.org · 关于屏幕阅读器使用方式、浏览器组合和无障碍障碍的最大规模持续调查。一贯发现标题和地标(landmark)是用户首选的导航策略。
- 世界卫生组织(2019).World Report on Vision. · 报告全球至少 22 亿人存在近视或远视的视力障碍,其中约 4300 万人为盲人。
- Power, C., Freire, A., Petrie, H. & Swallow, D. (2012).「Guidelines are only half of the story: Accessibility problems encountered by blind users on the web.」Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '12)。· 研究发现盲人用户遇到的大部分无障碍问题并未被 WCAG 涵盖,强调了人工审核和屏幕阅读器测试的必要性。
- Lazar, J., Allen, A., Kleinman, J. & Malarkey, C. (2007).「What frustrates screen reader users on the web: A study of 100 blind users.」International Journal of Human-Computer Interaction, 22(3), 247–269。· 识别出盲人用户最主要的挫折点:缺失的替代文本、未标记的表单字段和误导性的链接标签。
- W3C WAI (2023).「WAI-ARIA Authoring Practices 1.2.」· 定义了如何使用角色、状态和属性,使动态内容对辅助技术可访问。
免责声明
此工具基于 HTML 无障碍树提供简化的屏幕阅读器输出近似。真实的屏幕阅读器(NVDA、JAWS、VoiceOver、TalkBack)在朗读内容、处理 ARIA 属性和与动态小部件交互方面各不相同。此预览不能替代用真实屏幕阅读器和真实用户进行的测试。它旨在帮助在写作过程早期发现常见问题。
Web 无障碍标准简史
网络上的无障碍由 W3C 网络无障碍倡议(WAI)的一小堆标准以及引用它们的国家法律管辖。WCAG 1.0 于 1999 年 5 月发布,是关于使网页内容无障碍的第一个正式指南。它主要以 HTML 为中心,很快就过时了。WCAG 2.0(2008 年 12 月)是围绕四个原则(可感知、可操作、可理解、健壮)和三个合规级别(A、AA、AAA)组织的重大重写。它于 2012 年成为 ISO 标准(ISO/IEC 40500),是大多数法律仍然引用的合规目标。WCAG 2.1(2018 年 6 月)增加了 17 项新成功标准,涵盖移动、低视力和认知障碍。WCAG 2.2(2023 年 10 月)又增加了 9 项,特别是 2.4.11 焦点不被遮挡 和 3.3.8 无障碍认证。WAI-ARIA 1.0 于 2014 年 3 月最终确定;1.2 于 2023 年 6 月是当前的建议。在法律方面,美国第 508 条更新(2018 年 1 月)将 WCAG 2.0 AA 纳入美国联邦采购。欧洲无障碍法案(指令 2019/882)于 2025 年 6 月 28 日生效,要求欧盟大多数面向消费者的数字产品符合无障碍标准。大多数国家都引用 WCAG,因此构建到 WCAG 2.2 AA 是当今任何全球产品的实际目标。
今日屏幕阅读器格局
WebAIM 屏幕阅读器用户调查 #10(2024)是关于人们实际使用哪些屏幕阅读器的权威来源。五种产品主导桌面、移动和 ChromeOS。
- JAWS(Freedom Scientific,1989 年首次发布)是 Windows 上长期商业领导者。成本约 1000+ 美元。WebAIM 2024 发现它是约 40% 调查受访者的主要屏幕阅读器,略低于 NVDA。
- NVDA(NV Access,2006 年首次发布,用 Python 编写)是 Windows 的开源替代品。免费。WebAIM 2024 报告它是最常用的主要屏幕阅读器,约 47% 的受访者。NVDA 在 15 年内从一个小众工具发展为市场领导者,是辅助技术中最伟大的开源成功故事之一。
- VoiceOver(Apple,2005 年在 macOS 上,2009 年在 iOS 上)内置于每个 Mac、iPhone、iPad、Apple Watch、Apple TV。它是最常用的移动屏幕阅读器。与 Safari 和 iOS 旋转器紧密集成进行导航。
- TalkBack(Google,2009 年在 Android 上)是 Android 对应物。自 Android 4 起开源。使用手势和导航菜单。
- ChromeVox(Google,2012)和 Narrator(Microsoft,2000,在 Windows 10 中现代化)完善了格局。每个都有一个小但忠诚的用户群。
单个页面可能被每个产品以不同方式宣布。健壮的页面至少在两个产品中干净地测试:通常是 NVDA + Firefox 或 Chrome,以及 VoiceOver + Safari。
何时使用此工具
- 发布前审计。粘贴一个关键页面(主页、注册表单、结账)并大声朗读线性化的输出。如果它对你没有意义,对屏幕阅读器用户也不会有意义。
- 代码审查。在合并具有重大标记更改的 PR 之前,粘贴渲染的 HTML 并确认标题、地标和替代文本完好无损。
- 设计交接验证。设计师可以粘贴他们的最终 HTML 来确认视觉层次与语义层次匹配。看起来像标题的页面在 DOM 中也应该是标题。
- 教授无障碍性。向一个班级或团队展示屏幕阅读器实际接收的内容。视觉布局和线性化输出之间的差距往往是非残障开发者第一次理解为什么语义 HTML 重要。
- WCAG 合规性检查。对四个最常被违反的标准进行快速抽查:1.1.1 非文本内容(替代文本)、1.3.1 信息和关系(语义结构)、2.4.4 链接目的、4.1.2 名称、角色、值。
- CMS / 无代码站点检查。视觉编辑器常常生成 div 而不是标题或没有文本的链接。粘贴已发布的 HTML,看看什么溜过去了。
- 电子邮件模板无障碍性。HTML 电子邮件出了名地难以让其无障碍。使用预览来验证每张图片上的替代文本、正确的标题顺序和可读的阅读流。
屏幕阅读器暴露的常见错误
- 缺失或无用的替代文本。
alt="image"、alt="photo"、alt="logo"几乎只比什么都没有好一点。Lazar 等(2007)将缺失的替代文本确定为盲人网络用户的首要挫败感。编写传达图像在周围上下文中目的的替代文本,或为纯装饰图像使用alt=""以便屏幕阅读器跳过它们。 - 跳过或重新开始的标题级别。从
h1跳到h3跳过h2会混淆导航。在同一页面上使用多个h1元素(组件驱动设计中相当常见的模式)会破坏屏幕阅读器用户依以导航的文档大纲。WebAIM 2024 发现标题是屏幕阅读器用户最常见的导航策略。 - Divitis。用
<div>和点击处理程序包装可点击文本而不使用<button>或<a>意味着没有键盘支持、没有焦点环、没有角色宣布。始终从语义 HTML 开始,仅当没有原生元素适合时才添加 ARIA。 - 在 HTML 可行时使用 ARIA。ARIA 的第一条规则(根据 W3C WAI-ARIA 编写实践):「如果你可以使用原生 HTML 元素... 就这么做」。
<button role="button">是冗余的;<div role="button">是你应该改用真正按钮的标志。 - ARIA 使用不正确。在可聚焦元素上使用
aria-hidden="true"使其对屏幕阅读器不可见但仍然可键盘聚焦,这是导致迷失方向的 tab 顺序的配方。没有tabindex="0"和键盘处理程序的role="button"什么也不做。 - 没有标签的表单输入。没有关联的
<label>、aria-label或aria-labelledby的<input>被宣布为「edit, blank」,没有上下文。占位符文本不是替代品,它在聚焦时消失,经常对比度不足。 - 「点击这里」和「阅读更多」链接。屏幕阅读器用户常常通过调出页面上所有链接的列表进行导航。「点击这里」本身没有告诉他们任何事情。让链接文本描述目的地:「阅读 2024 WebAIM 调查」胜过「在此阅读更多」。
- 移除焦点样式。没有替代焦点指示器的
outline: none是最常被违反的 WCAG 标准之一(2.4.7 焦点可见)。键盘用户,包括许多屏幕阅读器用户,需要看到焦点在哪里。
ARIA 一览:每种角色类型做什么
- 地标角色(
banner、navigation、main、complementary、contentinfo、search)将页面划分为屏幕阅读器用户可以跳转的区域。大多数都有原生 HTML 等效项(<header>、<nav>、<main>、<aside>、<footer>)。首先使用原生元素。 - 小部件角色(
button、checkbox、combobox、menu、tabpanel等)描述交互式控件。小部件角色暗示了 W3C ARIA 编写实践指南(APG)详细记录的键盘交互模式。如果你无法准确匹配 APG 规范,请优先选择原生 HTML。 - 文档结构角色(
article、list、listitem、row、cell等)描述非交互式内容。大多数也有原生 HTML 等效项。仅在原生元素不可用时使用它们(例如,构建<table>不适合的自定义数据网格)。 - 实时区域(
aria-live="polite"、aria-live="assertive"、role="status"、role="alert")告诉屏幕阅读器在不移动焦点的情况下宣布动态更新。用于聊天消息、表单错误、加载状态。过度使用会导致通知疲劳;为真正紧急情况(如错误状态)保留assertive。
更多常见问题
此预览是否与 NVDA / JAWS / VoiceOver 实际会说的相匹配?
它近似。此工具读取浏览器的无障碍树(屏幕阅读器使用的相同结构)并生成将被宣布的线性化版本。真正的屏幕阅读器添加产品特定行为:焦点变化的宣布、表格导航、表头、列表项计数、ARIA-live 礼貌处理、自定义详细程度设置。将预览视为初步合理性检查;对于生产发布,在你的受众使用的操作系统上至少使用一个真正的屏幕阅读器进行测试。
WCAG 和 ARIA 有什么区别?
WCAG(Web 内容无障碍指南)是一份要求清单:「每个非文本内容都必须有文本替代」。它告诉你什么要实现但并不总是如何。ARIA(可访问的丰富互联网应用程序)是满足 WCAG 的工具之一:一组 HTML 属性(角色、状态、属性),当原生 HTML 不足时,这些属性将语义暴露给辅助技术。如果你的 HTML 语义足够,你可以在没有任何 ARIA 的情况下满足 WCAG。ARIA 是为它不足的情况而设计的。
如何编写好的替代文本?
来自 W3C 的alt 决策树的三条规则:(1)如果图像纯粹是装饰性的,使用 alt="" 以便屏幕阅读器完全跳过它。(2)如果图像传达了周围文本中尚未提供的信息,请简洁地描述该信息(通常少于 125 个字符)。(3)如果图像是功能性的(例如,链接到主页的徽标或图标按钮),请描述操作而不是外观。「搜索」胜过「放大镜图标」。避免「图像」、「照片」,屏幕阅读器已经宣布元素是图像。
我的网站到处都是 div。我从哪里开始?
首先添加五个地标元素:<header>、<nav>、<main>、<aside>、<footer>。然后将可点击的 div 替换为 <button>(用于操作)或 <a>(用于导航)。然后审计标题:每个页面都应该有一个 <h1>,其余按嵌套顺序排列。这三个步骤可以修复典型 div 密集站点上约 70% 的无障碍问题。ARIA 和 JavaScript 焦点管理在语义基础到位后再来。
我在这里粘贴的 HTML 会被发送到任何地方吗?
不会。解析使用浏览器的内置 DOMParser,分析完全在客户端运行。在 DevTools 中打开网络选项卡并点击分析,你将在线性化期间看到零出站请求。对内部模板、未发布的页面或包含客户数据的 HTML 安全。