根本原因是<nav>被嵌套在语义断层容器（如<table><ul>或role="group"的<div>）中导致地标传播中断，且内部缺乏可聚焦元素；<main>必须唯一且为<body>直系子元素，否则屏幕阅读器无法定位核心内容。
为什么写了 <nav> 屏幕阅读器还是跳不过去
根本原因不是样式隐藏或 JS 干扰，而是 <nav> 被写在了语义“断层”位置：比如包在 <table>、<ul> 或带 role="group" 的 <div> 里——这些父容器会中断地标传播，浏览器可能直接丢弃该节点。更常见的是 <nav> 里只放纯文本或没加 tabindex="0" 的容器，导致内部无可聚焦元素，读屏器判定为“不可交互”，跳过不读。
必须确保：
-
<nav>是<body>的直接子元素，或至少不被语义受限标签（如<table>、<ol>）包裹 - 内部至少有一个可聚焦元素：
<a href>、<button>，或带tabindex="0"的容器 - 多个
<nav>必须配aria-label，且值要具体，如aria-label="主导航"，不能是泛泛的"Navigation"
<main> 唯一性不是建议，是硬性约束
<main> 是屏幕阅读器定位“核心内容”的唯一锚点，Lighthouse 报 "Multiple main landmarks" 不是警告，是直接判为无障碍失败。一旦嵌套在 <header>、<section> 或 React 的 <Layout> 组件壳里，就等于把 GPS 定位点塞进了抽屉——辅助技术找不到它。
正确结构只能是：
立即学习“前端免费学习笔记（深入）”；
-
<body>直接包含<header>、<main>、<footer>（并列） -
<main>内部不需要再套一层<section>——除非该<section>有独立标题且需参与大纲生成；否则<main><h1>...更干净 - 如果框架强制输出嵌套 DOM（如 Next.js 的
<main>包在<div>里），必须用 CSS 或 JS 在运行时修正，确保最终渲染的<main>是<body>的直系子节点
导航项必须用 <ul> 或 <ol>，别用 <div> 堆砌
导航的本质是一组可顺序访问的跳转目标。<ul> 或 <ol> 不仅传达“列表”语义，还自带隐式可计数、可遍历能力。用 <div> 套链接，哪怕加了 role="list"，也会丢失键盘方向键导航、读屏器报数（“第1项，第2项”）等原生行为。
选 <ul> 还是 <ol>？
- 主导航、页脚链接等无强顺序关系 → 用
<ul> - 面包屑、步骤条、章节锚点等有明确层级或顺序 → 用
<ol>，读屏器会播报序号 - 当前页链接必须保留
href（哪怕指向当前 URL），并加aria-current="page"；禁用项用disabled或aria-disabled="true"+tabindex="-1"，不能删href
验证路标是否真实生效，别只看标签名
DevTools 里看到 <nav> 和 <main> 标签，不代表它们被辅助技术识别为地标。真正起作用的是浏览器暴露给读屏器的 ARIA role、name 和 level。
实操验证方式：
- Chrome DevTools → Accessibility 面板 → 展开 “Landmarks” 节点，看实际识别出的地标结构
- NVDA 用户按
Insert+Tab切换地标，确认“主导航”“主内容”是否出现且名称准确 - 用 axe 浏览器插件扫描，重点关注
"landmark-unique"和"landmark-no-duplicate-label"规则 - 特别注意：如果
<nav>没配aria-label，axe 会报"nav-has-label"，但 NVDA 可能静默跳过——这不是 bug，是规范要求
最常被忽略的点：语义路标依赖的是最终渲染的 DOM 结构，不是 JSX 或模板语法。框架层的抽象、SSR/CSR 差异、服务端注入的 wrapper div，都可能悄悄破坏 <main> 的顶层位置或 <nav> 的可聚焦性。验证必须在真实渲染后的页面上做。
