标签仅用于页面主要导航区块，必须包裹全局跳转链接，需配aria-label或aria-labelledby，内部宜用结构，禁用非导航内容、伪链接及冗余role属性。

nav 标签不是“写出来就能当导航用”的容器，它只负责告诉浏览器和辅助技术“这里是一组页面级跳转链接”，写错位置、包错内容、漏掉 ARIA 标识，等于没写。

nav 里该放什么，不该放什么

它只收「能跳到其他页面或锚点的 @#@#@#@#@#@#@#@#@#@0）、页脚快捷入口、文章目录锚点列表

❌ 错误：

搜索框、 登录、语言切换开关、纯图标无文字链接、单个「返回首页」链接

⚠️ 特别注意：面包屑（

）和分页控件（

）虽属导航类，但 W3C 明确建议不用 nav 包裹面包屑；分页可用，但必须加 aria-label

多个 nav 共存时为什么必须加 aria-label

屏幕阅读器靠这个字符串识别每个 nav 的用途。不加就只剩“导航”两个字，用户根本分不清哪个是主菜单、哪个是页脚链接、哪个是侧边相关文章。

• 正确写法：
  ...
  、
  ...
• 如果已有可见标题（如

  网站导航

  ），可用 aria-labelledby="nav-title" 关联
• 绝对不要写 aria-label="" 或依赖 CSS 隐藏文本作唯一标识——部分读屏器会跳过整个区域
• 重复声明 role="navigation" 是冗余的，nav 在 HTML5 中已自带该 role，多写反而可能覆盖默认行为

nav 内部结构怎么组织才靠谱

语义和可访问性都依赖合理的嵌套。光用

@#@#@#@#@#@#@#@#@#@1

@#@#@#@#@#@#@#@#@#@2

下拉菜单必须用嵌套

，父级 加 aria-haspopup="true" 和 aria-expanded="false"

避免

...

这类纯布局嵌套——既无语义，又干扰焦点流

所有 必须有真实 href，href="#" 或 javascript:void(0) 会让键盘用户卡住，也破坏 SEO

nav 不生效的典型表现和排查点

写了 nav 却没被读屏器识别、Lighthouse 报 Navigation landmark not present、Tab 键跳过整块区域——问题往往不在标签本身，而在上下文。

HTML Text Extract

从HTML页面（URL、文件或标准输入）中提取主体内容文本，去除导航、页脚、广告和模板文本。可直接传递给readability_check或其他文本工具。

下载

• 检查是否用了 IE8 或更老内核（现代项目基本不考虑，但遗留系统要注意）；若需兼容，得手动 document.createElement("nav")
• 确认没把 nav 套在
  里还塞了 logo 和搜索框——视觉上挨着 ≠ 语义上属于
• 动态渲染的导航（如 React/Vue 中从 API 拉取菜单）容易漏掉 aria-label 或初始 aria-expanded 状态，JS 插入后要补全 ARIA 属性
• 移动端用汉堡菜单时，别只靠 display: none 隐藏 nav，记得同步设 aria-hidden="true" 并管理焦点顺序，否则键盘用户会陷入不可见区域

最常被忽略的一点：nav 的语义契约是双向的——你标了它，就得真给它装导航链接；你没标，辅助技术就当它是普通内容。它不控制样式、不触发跳转、不自动高亮当前页，这些全是 JS/CSS 的事。语义化不是加分项，是基础契约。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！