无障碍树构建失败主因是HTML结构未立住：<nav>等原生语义标签被<div>替代导致Computed Role为generic，<main>重复或嵌套违反唯一顶层约束，使屏幕阅读器无法识别导航与主内容。
无障碍树构建失败，十有八九不是 JS 或 ARIA 写错了，而是 HTML 文档结构本身没立住——<div> 堆出来的“导航”“主内容”“文章”，浏览器和读屏器根本认不出来。
<h3>为什么用 <code><div class="nav"> 会导致无障碍树缺失
<p>屏幕阅读器依赖 DOM 的隐式角色（implicit role）构建可访问性树。<code><div> 默认是 <code>generic 角色，读屏器只会说“组”，不会识别为导航区；而 <nav></nav> 自带 role="navigation"，无需 JS 或 ARIA 补救。一旦你用 <div class="nav"> 替代 <code><nav></nav>，整个导航区块在无障碍树里就成了一片空白区域。
- Chrome DevTools 的 Accessibility 面板里，该节点的
Computed Role显示为generic，而非navigation - NVDA / VoiceOver 在“按区域跳转”时直接跳过该区块，用户无法用
Insert + F7列出导航链接 - SEO 也收不到结构信号：Google 不会把
<div class="nav"> 当作导航上下文，影响页面主题权重分配 <li>IE11 和 Safari 12 以下版本更糟——它们对 ARIA 的支持有限，但对原生语义标签（如 <code><nav></nav>）有基础兼容保障 - 右键任意疑似结构区块（比如顶部栏、侧边栏、正文容器）→
Inspect Accessibility Properties - 重点检查三列：
Computed Role（是否为banner/navigation/main/article）、Name（是否为空）、States（比如aria-expanded是否同步） - 若
Computed Role是generic，且没有手动加role属性，基本就是语义缺失 - 执行
document.querySelectorAll('div[class]').forEach(el => { if (['header', 'nav', 'main', 'article', 'aside', 'footer'].every(tag => !el.matches(tag))) console.log('裸 div:', el) })可批量揪出未升级的容器 - 常见诱因：服务端模板拼接时重复注入
<main></main>；React 组件多次渲染未做条件判断；CMS 输出逻辑未校验上下文 - DevTools 中能看到多个
<main></main>节点，但 Accessibility 面板只对第一个显示main角色，其余均为generic - 错误嵌套如
<header><main>...</main></header>也会导致<main></main>失效：规范明确禁止<main></main>出现在<header></header>、<footer></footer>、<nav></nav>或<section></section>内部 - 修复只需一条规则：
<main></main>必须是的直接子元素，且全文仅出现一次 - 仪表盘卡片、实时数据块、广告位等“非内容单元”，用
<div role="region" aria-labelledby="card-title"> 比生套 <code><article></article>更准确 - 动态组件（如 React 渲染的 Tab 面板）若运行时语义不确定，优先用
<div> + 显式 <code>role+ 状态属性，而不是赌浏览器自动推导真正卡住无障碍树的，往往不是某一行 ARIA，而是最开头那几个没写对的
<header></header>和<nav></nav>—— 它们决定了整棵树的根节点是否成立。
如何用 DevTools 快速定位无语义区块
别靠肉眼扫 class 名，直接看无障碍树的真实构成：
<main></main> 嵌套或重复出现引发的树断裂
<main></main> 是页面唯一主内容锚点，浏览器和 AT（辅助技术）只认第一个，后续所有 <main></main> 节点会被静默忽略——不是报错，而是彻底消失在无障碍树中。
立即学习“前端免费学习笔记（深入）”；
