标签仅用于页面主要导航区块，必须包裹全局跳转链接，需配aria-label或aria-labelledby，内部宜用结构，禁用非导航内容、伪链接及冗余role属性。
nav 标签不是“写出来就能当导航用”的容器，它只负责告诉浏览器和辅助技术“这里是一组页面级跳转链接”，写错位置、包错内容、漏掉 ARIA 标识，等于没写。
nav 里该放什么，不该放什么
它只收「能跳到其他页面或锚点的 <a></a> 链接」，且必须是用户主动选择的全局导航路径。常见误包内容会直接破坏键盘导航和读屏体验。
- ✅ 正确：主导航菜单（
<ul><li><a href="/products">产品</a></li></ul>）、页脚快捷入口、文章目录锚点列表 - ❌ 错误：
<form></form>搜索框、<button></button>登录、语言切换开关、纯图标无文字链接、单个「返回首页」链接 - ⚠️ 特别注意：面包屑（
<ol class="breadcrumb"></ol>）和分页控件（<nav aria-label="分页"></nav>）虽属导航类，但 W3C 明确建议不用nav包裹面包屑；分页可用，但必须加aria-label
多个 nav 共存时为什么必须加 aria-label
屏幕阅读器靠这个字符串识别每个 nav 的用途。不加就只剩“导航”两个字，用户根本分不清哪个是主菜单、哪个是页脚链接、哪个是侧边相关文章。
- 正确写法：
<nav aria-label="主导航">...</nav>、<nav aria-label="页脚导航">...</nav> - 如果已有可见标题（如
<h2 id="nav-title">网站导航</h2>），可用aria-labelledby="nav-title"关联 - 绝对不要写
aria-label=""或依赖 CSS 隐藏文本作唯一标识——部分读屏器会跳过整个区域 - 重复声明
role="navigation"是冗余的，nav在 HTML5 中已自带该 role，多写反而可能覆盖默认行为
nav 内部结构怎么组织才靠谱
语义和可访问性都依赖合理的嵌套。光用 <nav><a>首页</a><a>关于</a></nav> 虽然合法，但读屏器无法告知用户“共 4 项”，也无法用方向键高效遍历。
立即学习“前端免费学习笔记（深入）”；
- 首选
<ul></ul>+<li>结构：<nav aria-label="主导航"><ul> <li><a href="/">首页</a></li> <li><a href="/about">关于</a></li> </ul></nav> - 下拉菜单必须用嵌套
<ul></ul>，父级<a></a>加aria-haspopup="true"和aria-expanded="false" - 避免
<nav><div><div><a>...</a></div></div></nav>这类纯布局嵌套——既无语义，又干扰焦点流 - 所有
<a></a>必须有真实href，href="#"或javascript:void(0)会让键盘用户卡住，也破坏 SEO
nav 不生效的典型表现和排查点
写了 nav 却没被读屏器识别、Lighthouse 报 Navigation landmark not present、Tab 键跳过整块区域——问题往往不在标签本身，而在上下文。
- 检查是否用了 IE8 或更老内核（现代项目基本不考虑，但遗留系统要注意）；若需兼容，得手动
document.createElement("nav") - 确认没把
nav套在<header></header>里还塞了 logo 和搜索框——视觉上挨着 ≠ 语义上属于 - 动态渲染的导航（如 React/Vue 中从 API 拉取菜单）容易漏掉
aria-label或初始aria-expanded状态，JS 插入后要补全 ARIA 属性 - 移动端用汉堡菜单时，别只靠
display: none隐藏nav，记得同步设aria-hidden="true"并管理焦点顺序，否则键盘用户会陷入不可见区域
最常被忽略的一点：nav 的语义契约是双向的——你标了它，就得真给它装导航链接；你没标，辅助技术就当它是普通内容。它不控制样式、不触发跳转、不自动高亮当前页，这些全是 JS/CSS 的事。语义化不是加分项，是基础契约。
