如何借助HTML大纲算法改善长网页的可访问性导航

浏览器根据<h1>到<h6>的嵌套位置和顺序自动推导文档大纲，<section>等sectioning root可重置内部标题层级，跳级写heading（如<h2>后直接<h4>）会导致语义断裂；需用Chrome DevTools Accessibility面板验证。

浏览器怎么生成文档大纲

浏览器不靠人工编号或目录生成大纲，而是严格按 <h1> 到 <h6> 的嵌套位置和顺序自动推导层级。这个大纲直接决定屏幕阅读器的“M 键跳转”路径、Safari 的页面缩略图导航，甚至 Google 对内容权重的判断。

关键规则有两条：<section>、<article>、<nav>、<aside> 是 sectioning root，它们内部的 <h1> 会被重置为该区块顶层标题；而跳级写 heading（比如 <h2> 后直接 <h4>）不会报错，但会让大纲断裂——浏览器仍按数字顺序硬推层级，语义却完全脱节。

• 常见错误：主内容区用 <h2> 开头，但页头塞了三个 <h1>，导致大纲根节点漂移
• 验证方式：用 Chrome DevTools 的 “Accessibility > Document Outline” 或 Firefox 的 “Inspector > Accessibility > Outline” 实时查看，别信肉眼数标签
• 性能影响：大纲断裂本身不拖慢加载，但会让屏幕阅读器反复回溯 DOM 寻找逻辑起点，语音响应延迟明显

为什么必须用 sectioning root 包裹逻辑区块

仅靠 heading 标签无法表达“同级并列内容块”。比如产品页里“参数详情”和“用户评价”两个 <h2>，若都放在 <main> 下，大纲里只是两个兄弟节点；但各自用 <section> 包裹后，每个区块获得独立上下文，其内部 <h3> 自动重算为子级，且能被辅助技术识别为可跳转单元。

• 滥用 <section> 的典型场景：<section><p>欢迎关注我们</p></section> —— 没标题、不可分发、无结构意义
• 判断标准：这块内容是否自带 <h2>–<h6>？能否被 RSS 抓取？是否属于已有语义范畴（如页脚用 <footer>）？
• SEO 影响：Google 参考大纲评估内容权重，节点泛滥或层级断裂会弱化主内容识别，尤其对长网页的段落权重分配影响显著

如何修复长网页常见的大纲断裂问题

长网页最容易在滚动区域、Tab 切换面板、动态加载区块出现大纲断裂。核心是避免“视觉优先”的 heading 写法，坚持“结构先行”。

立即学习“前端免费学习笔记（深入）”；

• 禁止从 <h2> 开始：全页第一个 heading 必须是 <h1>，且唯一；后续所有 heading 必须严格递进或由 sectioning root 重置
• Tab 面板处理：每个 <section> 用 <h2> 做标题，内部用 <h3>；不要把所有 Tab 内容堆在同一个 <div> 里再统一用 <h3>
• 动态内容注入：用 DocumentFragment 插入新区块时，确保包裹 <section> 并带合法 heading，别直接 appendChild 一堆 <p> 和 <h4>
• 工具链检查：在 CI 中加入 axe-core 或 pa11y，配置 rule heading-order 和 region，自动拦截大纲异常

容易被忽略的细节：无标题 section 和 main 的陷阱

<section> 没 heading 仍会出现在大纲中，显示为“无标题”，对屏幕阅读器用户是纯噪音；<main> 若包裹非核心内容（如广告、侧边栏），会导致辅助技术跳过真正正文。

• 常见坑：<main> 里塞了顶部 banner + 左侧菜单 + 内容区；Next.js 布局组件写一个 <main>，子页面又渲染一个
• 正确做法：全 DOM 中仅一个 <main>，且只包含用户真正要操作/阅读的部分（如商品列表、表单主体、文章正文）
• 最隐蔽的问题：小节用了 <h3>，但主内容还没出现 <h2> —— 这会让大纲根节点悬空，长网页滚动到中段时，屏幕阅读器彻底失去上下文锚点