WCAG 标题检查器，免费

什么是 WCAG 标题检查器？

WCAG 标题检查器验证网页上的标题元素（h1、h2、h3、h4、h5、h6）形成屏幕阅读器和其他辅助技术可以导航的逻辑层次结构。标题是盲人和低视力用户浏览页面的方式：他们使用屏幕阅读器快捷键在标题之间跳转，在几秒钟内构建心理目录。如果标题缺失、顺序错乱或用作装饰，该导航就会崩溃。WCAG 2.2 成功标准 1.3.1（信息与关系）和 2.4.6（标题和标签）要求标题正确传达结构。

规则简单易述也容易违反。每页应有恰好一个 h1（页面标题）。每个后续标题应最多比其父级深一层（h2 后面可以跟另一个 h2 或 h3，但不能直接跟 h4）。标题不应为空。标题级别应描述文档结构，而不是视觉大小（不要仅因为想要更小的文本就使用 h4）。大多数无障碍审计将标题层次问题标记为首先要修复的问题，因为它们常见、易于验证，并对屏幕阅读器用户影响很大。

此工具解析您粘贴的 HTML（无上传，无服务器往返），按文档顺序遍历标题元素，并报告问题：缺失 h1、多个 h1、跳过的级别、空标题以及页面结构的大纲。输出是描述每个问题的纯文本。在开发期间、发布之前或作为定期无障碍审计周期的一部分在任何页面上运行它。输出是简明语言，而不是数字分数；目标是给您具体的问题来修复，而不是要追逐的及格分数。

工具内部有什么

页面顶部是一个文本区域，您可以粘贴 HTML。您可以粘贴完整文档（DOCTYPE、html、head、body）或片段（仅 body 内容）。工具使用标准浏览器 DOMParser 按文档顺序提取所有 h1 到 h6 元素，因此解析与真实浏览器所做的相匹配。文本区域处理任何大小的输入；非常大的文档（数万行）有效，但解析时间稍长。

单击检查标题，结果出现在下方。第一部分是标题大纲：每个标题按顺序，按级别缩进，因此您可以将结构作为目录阅读。第二部分是问题列表：每个问题的具体位置、出了什么问题以及为什么重要的简要解释。问题按严重程度分类：错误（必须修复以符合 WCAG）和警告（最佳实践但非严格失败）。

输出留在浏览器中；没有上传任何内容。您可以多次粘贴相同的 HTML 并在两者之间进行编辑以迭代修复。该工具有意不检查标题结构之外的任何内容（它不验证 alt 文本、对比度、焦点顺序、ARIA 或任何其他 WCAG 标准）。对于那些，请将此工具与综合审计工具（如 axe DevTools、Lighthouse 或 WAVE）一起使用。

历史与背景

自始以来的 HTML 标题（1991）

Tim Berners-Lee 在 1991 年引入 HTML，h1 到 h6 元素作为原始 18 个标签的一部分。最初的语义意图始终是文档结构，而不是视觉样式。Web 的标题层次结构来自更古老的传统：印刷文档（书籍、论文、政府报告）几个世纪以来一直使用编号的章节级别来传达结构。HTML 直接继承了该模型。尽管有 35 年稳定的语义，标题误用仍是现代 Web 上最常见的无障碍错误之一，因为设计师经常首先按视觉大小设计样式，然后再检查结构。

屏幕阅读器学会按标题导航（1996 年起）

JAWS（Job Access With Speech）由 Henter-Joyce 于 1989 年发布，并随着 Web 在 1990 年代后期变得流行而添加了网页标题导航。在 JAWS 中按 H 键跳转到下一个标题；编号键 1 到 6 跳转到特定标题级别。从那以后的每个主要屏幕阅读器（2006 年的 NVDA、2005 年的 VoiceOver、Android 上的 TalkBack）都复制了此快捷方式。WebAIM 的年度屏幕阅读器用户调查一致发现 67% 到 70% 的屏幕阅读器用户使用标题作为理解页面的主要方法导航。因此，破碎的标题层次结构不是装饰性问题。

WCAG 1.0 和无障碍标准的兴起（1999）

Web 内容无障碍指南 1.0 由 W3C 于 1999 年 5 月发布，是 Web 无障碍的第一个国际标准。WCAG 1.0 明确要求标题用于文档结构（检查点 3.5）。WCAG 2.0（2008）将其细化为成功标准 1.3.1（信息与关系，A 级）和 2.4.6（标题和标签，AA 级）。WCAG 2.1（2018）和 2.2（2023）保持这些标准不变，因为底层要求是合理的。世界各地的大多数无障碍法律（美国的 ADA、欧洲的 EAA、安大略省的 AODA）现在都将 WCAG 2.1 AA 引为法律基线。

HTML5 分区和文档大纲（2014）

HTML5（W3C 推荐标准 2014）引入了分区元素（article、section、nav、aside）和一个本应从嵌套深度派生标题层次结构的大纲算法。该算法从未在任何浏览器或屏幕阅读器中实现，并于 2022 年正式弃用。实用指导是：使用显式标题级别（h1 到 h6），并将分区元素视为语义分组，而不是替代标题深度。HTML Living Standard 现在明确说明必须显式设置标题级别。

ARIA 角色和 aria-level（2014 年起）

WAI-ARIA 1.1（W3C 推荐标准 2017）提供 role="heading" 与 aria-level="N" 作为标记标题的替代方法，当您不能使用本机 h1-h6 元素时（例如，在需要在不同上下文中渲染不同标题级别的框架组件中）很有用。屏幕阅读器对待 role="heading" 与本机元素相同。最佳实践是尽可能使用本机元素；仅在本机语义不可用时使用 ARIA。此工具检查本机标题元素和带有 role="heading" 的元素。

无障碍诉讼和商业案例（2017 年起）

Domino's Pizza 诉 Robles（美国最高法院 2019）确立了《美国残疾人法案》（ADA，1990）适用于商业网站。每年都有数百起类似诉讼随之而来（仅 2024 年就提起了 4,000 多起 ADA 网络诉讼）。《欧洲无障碍法案》（EAA，2025 年 6 月生效）使等同于 WCAG 的无障碍成为整个欧盟大多数面向消费者网站的法律要求。失败的标题结构是原告最容易识别和记录的问题之一，这使得基本的标题检查成为高杠杆的合规步骤。

实用工作流程

新页面和模板的预发布检查

在任何新页面或模板发布之前，通过此检查器运行 HTML。标题结构问题是最容易引入的无障碍错误（特别是在 CMS 驱动的内容中，编辑根据视觉大小选择标题级别）也最容易修复。在发布前发现它们比之后便宜得多，那时修复需要与内容所有者协调。对于代理机构，将此检查纳入 QA 清单；对于内部团队，将其作为代码审查或合并到 main 之前的一部分运行。

审计现有站点的无障碍合规性

对于无障碍审计（诉讼前、EAA 合规、合同要求），逐步浏览流量最大的页面并通过此检查器运行每个页面的 HTML。记录发现：哪些页面有标题问题、什么类型、如何修复。结合 axe DevTools 或 Lighthouse 进行其他 WCAG 标准。标题结构发现通常最容易补救，并形成审计报告的稳健快速胜利部分。

CMS 编辑培训和模板

CMS 驱动的内容（WordPress、Drupal、Contentful、Sanity）通常为编辑提供带有 H1 到 H6 选项的标题下拉菜单。不知道规则的编辑按视觉大小选择级别。向编辑展示此检查器，以便他们可以看到他们的标题选择产生什么。对于模板，在每次设计更改后通过检查器运行渲染输出，以确认编辑的标题选择仍然产生有效的层次结构。存在许多 CMS 插件在编写时警告编辑；此工具用于验证步骤。

验证电子邮件模板和 HTML 通讯

屏幕阅读器读取的 HTML 电子邮件应遵循与网页相同的标题层次结构。在发送到大列表之前，通过此检查器运行您的电子邮件模板的 HTML。常见的电子邮件模板问题：多个 h1（当每个部分都有自己的标题时）、缺失 h1（当布局直接从 h2 开始时）和纯粹用于小标题的装饰性 h4。在发送前修复这些；您列表上的辅助技术用户会注意到。

验证 PDF 到 HTML 的转换

当您将 PDF 转换为 HTML 以提高无障碍性（这样屏幕阅读器可以使用标题导航读取它们）时，转换器必须将 PDF 结构标签映射到 HTML 标题级别。结果通常被破坏：没有适当标记的 PDF 产生没有任何标题的平面 HTML，甚至标记的 PDF 有时也产生全 h1 或全 h2 输出。在发布转换的页面之前，通过此检查器运行转换的 HTML 以发现问题。

新开发人员和设计师的入职

初级前端开发人员和设计师从看到破碎的标题层次结构和由此产生的屏幕阅读器体验的具体示例中受益。将此工具与屏幕阅读器演示配对（Windows 上的 NVDA 是免费的，Mac 上的 VoiceOver 是内置的）以展示标题如何驱动屏幕阅读器导航。抽象标题规则与具体用户体验之间的联系通常是让课程牢记的原因。

常见陷阱

按视觉大小选择标题级别

最常见的错误：因为想要较小的文本而使用 h4，或者因为设计中没有正确尺寸的 h3 而从 h2 跳到 h4。标题级别是结构性的，不是视觉的；使用 CSS 控制大小并使用与文档层次结构匹配的级别。如果您的设计系统没有每个所需级别的视觉样式，请添加一个（或使用类名覆盖），而不是选择错误的级别。

每页多个 h1

页面应有恰好一个 h1 代表页面标题。常见错误：包裹在 h1 中的站点 logo 加上也在 h1 中的文章标题（两个 h1），每个英雄部分使用 h1 的主页（多个 h1），或者根本没有 h1 因为布局从 h2 开始。修复是结构性的：选择页面上最重要的内容作为单个 h1，并将其他所有内容降级为 h2 或更低。axe 和 Lighthouse 等工具因此对多个 h1 发出警告。

跳过标题级别

从 h2 直接到 h4 破坏了文档大纲。在标题之间移动的屏幕阅读器用户期望每个 h4 嵌套在 h3 下，而缺失的 h3 会混淆结构。修复是插入缺失的中间级别或将 h4 降级为 h3。最常见的原因是从模型复制设计，其中视觉层次结构使用三种大小，但设计系统使用四个标题级别；每次组件更新后重新检查。

空标题

没有文本内容的 h2（通常是因为 JavaScript 小部件删除了文本但保留了元素）在屏幕阅读器的标题列表中显示为未标记的标题，这令人困惑且无用。要么用文本填充标题，要么完全删除标题元素。这在单页应用中很常见，其中在数据加载之前渲染占位符元素；仅在有内容要放入时才渲染标题。

非语义包装中的标题

包裹在 div 中带有 role="presentation" 或 aria-hidden="true" 的标题从无障碍树中删除，这可能会从屏幕阅读器隐藏一个原本正确的标题。审计每个标题的父元素，以确保它们不会从无障碍树中剥离标题。CSS display:none 和 visibility:hidden 也删除标题；仅在有意时使用，绝不在应该屏幕阅读器可见的内容上使用。

当本机 HTML 就足够时使用 ARIA

将 role="heading" aria-level="2" 添加到 div 而不是使用 h2 元素对无障碍性有效但是不必要的复杂性。本机 h1-h6 元素免费获得标题语义，在默认浏览器样式中正确呈现，并且比 ARIA 覆盖更好地承受屏幕阅读器错误。ARIA 的第一条规则（根据 WAI-ARIA 编写实践）是：当本机 HTML 提供相同语义时，不要使用 ARIA。除非框架约束真正强制 ARIA，否则使用本机标题元素。

隐私和数据处理

您粘贴的 HTML 在整个检查过程中留在您的浏览器中。提取标题的 DOMParser 在您机器上的 JavaScript 中运行；结果在文本区域下方的页面中呈现。没有上传步骤、没有远程处理，也没有关于您粘贴了什么 HTML 的遥测数据。这很重要，因为您最想检查的 HTML（预发布模板、NDA 下的客户站点、内部管理页面）正是您不应粘贴到第三方 SaaS 验证器中的内容。

页面加载后，该工具离线工作。您可以断开互联网连接，粘贴 HTML，运行检查，并查看结果，而您的标记从未触及另一台机器。大多数云无障碍检查器（PowerMapper、Tenon、Site Improve）需要上传页面 URL 或 HTML；对于机密页面，这正是要避免的故障模式。

何时不应使用此工具

对于完整的 WCAG 审计（使用综合工具）

标题结构是数十个 WCAG 标准之一。对于完整审计，使用 axe DevTools（来自 Deque 的免费 Chrome/Firefox 扩展）、Lighthouse（内置于 Chrome）、WAVE（WebAIM 的免费工具），或付费解决方案如 Tenon 或 PowerMapper。这些检查颜色对比度、alt 文本、ARIA 使用、表单标签、焦点顺序等。与综合工具一起运行此工具，而不是替代。

对于动态内容（测试呈现的 DOM）

如果您的标题由 JavaScript 生成（React、Vue、Svelte、Angular），则静态 HTML 源不包含最终标题。您需要在 JavaScript 运行后粘贴呈现的 DOM。使用浏览器 DevTools：打开页面，打开 DevTools，元素选项卡，右键单击 body 或 main，复制 outerHTML，然后将其粘贴到此检查器。或使用直接遍历实时 DOM 的浏览器扩展。

对于自动化 CI/CD 管道（使用 Node 库）

如果您希望标题检查在每次提交或拉取请求时自动运行，请将 axe-core、Pa11y 或 jest-axe 集成到您的测试套件中。它们在 CI 中无头运行标题检查（以及许多其他 WCAG 检查）。此浏览器工具用于开发和审查期间的交互式使用，而不是自动化。两者都有其用途；将浏览器工具用于一次性审计，将 CI 库用于持续验证。

对于 PDF 或 Word 文档无障碍性

PDF 和 Word 文档有它们自己的无障碍标记系统（PDF/UA、Word 标题样式）。它们不使用 HTML 标题，所以此工具不适用。对于 PDF 无障碍性，使用 Adobe Acrobat Pro 的无障碍检查器或 PAC 2024（免费，专注于 PDF/UA）。对于 Word，使用内置的无障碍检查器（审阅选项卡）。如果您想使用此工具，请先转换为 HTML，但转换本身可能会引入标题问题。

更多问题

跳过标题级别是否曾经可以？

在直接文档内容中不行。WCAG 2.2 SC 1.3.1 暗示标题应形成层次序列。它看起来像跳过的一个常见情况是页面大纲从 h1 开始，然后在主要内容区域内是 h2，而侧边栏或导航也有 h2；这没关系，因为两者都是页面 h1 下的兄弟姐妹。实际规则是：不要在连续内容流中跳过级别。检查器只标记真正的跳过。

如果我的框架只支持一个标题级别怎么办？

一些组件库以固定级别呈现标题（始终是 h2，不管嵌套）。修复是在标题组件上公开级别 prop（h2、h3 等），并让父级传递适当的值。像 React 这样的框架通常这样做；如果您的框架不这样做，请在组件上添加 aria-level，并使用 role="heading" 作为临时解决方法，直到您可以重构。从长远来看，每个可重用的标题组件都应接受级别 prop。

该工具检查像 role="heading" 这样的 ARIA 角色吗？

是的。任何带有 role="heading" 和有效 aria-level 属性（1 到 6）的元素都被视为指定级别的标题。本机 h1-h6 元素始终是首选，但 ARIA 标记的标题对屏幕阅读器同样有效，并与本机一起被检查。

与其他 WCAG 标准相比，标题层次结构有多重要？

非常重要。WebAIM 的年度屏幕阅读器用户调查一致发现 67-70% 的屏幕阅读器用户使用标题作为理解页面的主要方式导航。糟糕的标题有效地阻止了主要无障碍导航方法之一。在 WebAIM 的 WebAIM Million 年度分析中，标题问题是 Web 上最常见的五个无障碍失败之一。高用户影响和易于检测的结合使它们成为首要任务。

每页都应该有一个 h1 吗？

是的，除少数例外。每个完整的 HTML 文档都应有恰好一个 h1 代表页面标题。例外是明确插入到更大页面中的片段（电子邮件签名、嵌入到另一页面的小部件）；主机页面提供 h1，片段从 h2 或更低开始。对于独立页面，缺失 h1 是明显的无障碍失败。

我可以信任此工具进行法律合规审计吗？

对于标题结构具体来说，是的：规则精确，工具准确实现它们。对于整体 WCAG 合规性，没有单一的自动化工具是足够的；使用辅助技术的手动测试、专家审查和与残疾用户的用户测试是法律级审计所必需的。将此工具用作审计的几个输入之一，而不是作为合规性的唯一真理来源。