DOM结构本身是可访问性第一道门槛，语义错位、嵌套过深、标题跳级三类问题会使VoiceOver/TalkBack放弃结构导航而退化为逐字扫屏；main必须是body直接子元素且全页唯一，否则失效；section须配h2+标题，article需可独立分发；嵌套超4层拖慢touchstart冒泡，≥6层实测延迟达42ms；标题跳级（如h2后直连h4）致读屏器弃整段结构解析。
直接说结论：DOM结构本身是可访问性（a11y）的第一道门槛，不是加几个aria-label就能补救的；语义错位、嵌套过深、标题跳级这三类问题，会让VoiceOver/TalkBack在读取时直接放弃结构导航，退化成“逐字扫屏”。
为什么<main></main>放错位置会导致整页可访问性失效
浏览器和屏幕阅读器把<main></main>当作唯一可信的“内容锚点”，它必须紧贴之后、且不能被任何非语义容器包裹。一旦前面插了广告<div class="ad-banner">、埋点脚本或CMS生成的<code><div class="wrapper">，<code><main></main>就失去主体标识作用。
-
<main></main>必须是的直接子元素，且全页仅出现一次 - 常见错误：
<body><div class="page"><main>...</main></div></body>——这个<div class="page">直接让<code><main></main>失效 - 修复方式：删掉冗余
<div>，或用<code>display: contents（注意 Safari 15.4+ 才支持，旧版需降级为<div role="main">）<section></section>和<article></article>混用时，屏幕阅读器怎么“理解”错的<section></section>表示主题分组（如“用户评论区”），<article></article>表示可独立分发的内容单元（如某条评论本身）。两者语义层级不同，强行嵌套或互换，会让辅助技术误判内容权重和导航路径。-
<section></section>必须带标题（<h2>用户评论</h2>），否则屏幕阅读器不识别为独立区块 -
<article></article>内若没<h3>张三的评论</h3>，会被当作文本流的一部分，无法通过“跳到下一个文章”快捷键定位 - 侧边栏广告、推荐位别硬套
<section></section>——应改用<div role="complementary">，否则VoiceOver会把它和主内容并列导航
嵌套超4层后，touchstart事件冒泡延迟怎么影响语音控制
移动端语音指令（如“点击第二个按钮”）依赖事件冒泡路径精准定位目标。DOM深度每+1层，touchstart从目标元素向上冒泡就多一次捕获开销。实测6层嵌套平均延迟42ms，而原生
<button></button>在2层内稳定在8–12ms。立即学习“前端免费学习笔记（深入）”；
- 用Chrome DevTools右键任意元素 → Show DOM properties → 查
nodeDepth值，≥6必须重构 - 常见陷阱：JS框架默认注入的根容器（如React的
<div id="root">）、Vue的<div class="app">都算一层，再套两层<div class="container">就超限 <li>真机测试要点：开启iOS VoiceOver，用双指滑动切换焦点，观察是否跳过按钮、卡在空白区域</li> <h3>标题层级跳级为何比CSS失效更致命</h3> <p>读屏软件靠<code><h1>→<h2>→<h3>的严格嵌套构建内容图谱。一旦出现<h2>后直接<h4>，或同一页面多个<h1>，NVDA、TalkBack会直接放弃整段结构解析，退化为纯文本线性扫描。- 检查方法：用axe DevTools插件跑一次，重点关注“Heading order”报错项
- 动态内容（如SPA路由切换）必须同步更新
<h1>，不能只靠CSS隐藏旧标题 - 图标按钮旁的文本若用
<span>模拟标题，必须配aria-labelledby指向真实<h2>，否则不参与导航树
最常被忽略的是：DOM结构优化不是“写完HTML再补语义”，而是在写第一行标签时就决定可访问性下限——
<main></main>的位置、<h1>的唯一性、<button>是否原生，这些一旦定型，后期加ARIA属性几乎无效。
-
