nav标签只用于站点级主要导航区块，如页眉主导航、侧边菜单、汉堡菜单、文章目录及分页控件；禁用于相关推荐、页脚杂链、搜索框、登录按钮、面包屑及单链接，且必须配aria-label、嵌套ul/li结构并含真实href链接。
nav 标签只用于真正承担页面级跳转功能的主导航区块，不是所有带链接的容器都该用它——用错地方反而会干扰屏幕阅读器识别、稀释语义价值。
哪些地方该用 nav 标签
必须满足两个前提：一是链接组属于站点或应用级别的主要导航路径；二是用户能通过这些链接快速切换核心内容区域。常见合规场景包括：
- 页眉顶部横栏主导航（如“首页｜产品｜文档｜关于”）
- 左侧垂直功能菜单（如后台系统中的“仪表盘｜用户管理｜日志查询”）
- 响应式汉堡菜单展开后的完整导航列表
- 文章内部的章节锚点目录（需加
aria-label="本文目录"） - 分页控件（如“上一页｜1｜2｜3｜下一页”，推荐
<nav aria-label="分页"></nav>）
哪些地方不该用 nav 标签
即使视觉上像导航栏，只要不承担全局跳转功能，就不该套 nav。典型误用有：
- 文章末尾的“相关阅读”或“猜你喜欢”推荐块 → 用
<section></section>或普通列表更合适 - 页脚一堆杂项链接（版权、隐私政策、社交媒体图标）→ 属于页脚信息，归入
<footer></footer> - 搜索框、登录按钮、语言切换器 → 它们是操作入口，不是导航项，应独立放在
<header></header>内 - 面包屑（Breadcrumb）→ W3C 明确建议不用
nav包裹，可用<ol class="breadcrumb"></ol>并配aria-label - 单个链接，比如
<nav>首页</nav>→ 不构成“导航集合”，会被辅助技术忽略
nav 内部结构怎么写才规范
语义清晰 + 键盘可访问 + 读屏友好，三者缺一不可。推荐结构是 nav > ul > li > a，而不是纯 div 布局或裸 link：
- 必须用
<ul></ul>或<ol></ol>组织多个链接，让读屏器能播报“列表共 X 项” - 每个
@#@#@#@#@#@#@#@#@#@0
无障碍与多 nav 共存的关键细节
一个页面可以有多个 nav，但必须让人和机器都能分辨用途：
- 每个
nav都要配aria-label（如aria-label="主导航"）或aria-labelledby（关联已有标题） - 不能只写
<nav></nav>，否则 Lighthouse 会报 “Navigation landmark not present” - 避免重复写
role="navigation"——nav标签本身已自带该 role，多写可能覆盖默认行为 - 不要用
title属性替代aria-label，它对键盘/语音用户无效，且仅悬停触发
