nav标签专用于页面主要全局导航，如页眉菜单、侧边栏目录、页脚核心链接及面包屑；必须嵌套ul/li结构并配aria-label明确标识，禁用在锚点、评论区等非主导航场景。
nav 标签不是用来“分段导航”的装饰容器，而是专用于包裹**页面中主要的、全局性的导航链接集合**。用错地方反而会破坏语义，让屏幕阅读器困惑、SEO效果打折。
nav 标签只该用在哪些位置
它对应的是用户一眼就能识别出的“主干导航”，比如：
- 页眉顶部横向菜单（
首页 / 产品 / 关于 / 联系） - 侧边栏一级目录（如文档站的左侧大纲）
- 页脚中的核心栏目链接（
服务条款 / 隐私政策 / 合作伙伴），前提是这些是站点级入口，而非次要链接 - 面包屑导航（
首页 > 分类 > 文章），可单独套一层nav并加aria-label="面包屑导航"
别把它塞进文章内锚点列表、评论区跳转链接、或“回到顶部”按钮里——那些该用 div 或普通 a。
ul + li 是 nav 内部唯一推荐的结构
直接在 nav 里写一堆 a 标签，看似省事，实则丢掉三样东西：语义层级、键盘 Tab 顺序控制、以及屏幕阅读器对“这是个列表”的识别。
立即学习“前端免费学习笔记（深入）”；
正确写法必须嵌套 ul 和 li：
<nav aria-label="主导航">
<ul>
<li><a href="/">首页</a></li>
<li><a href="/products">产品</a></li>
<li><a href="/about">关于</a></li>
</ul>
</nav>
这样做的实际好处：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
-
ul自带隐式role="list"，读屏软件会报“列表，3项” -
li是天然的焦点容器，Tab 键能按顺序进入每个a，不会跳过或乱序 - 多级下拉时，子菜单只需在对应
li内再套ul，结构自然嵌套
aria-label 是 nav 的强制配套项
没有 aria-label 的 nav，等于告诉屏幕阅读器：“这里有个导航，但我不知道它叫啥”。尤其当页面有多个 nav（比如顶部+页脚），不加标识就会混淆。
写法很简单，但必须具体：
- ✅
<nav aria-label="主导航"> - ✅
<nav aria-label="页脚快速链接"> - ❌
<nav aria-label="导航">（太模糊） - ❌
<nav>（完全没 label）
如果导航文字本身已足够说明用途（比如“主导航”出现在视觉标题旁），也可用 aria-labelledby 指向那个标题元素，但 aria-label 更直接可靠。
响应式折叠时 nav 本身不能消失
很多人做移动端汉堡菜单，一收起就把整个 nav 设为 display: none。这会导致屏幕阅读器彻底“看不见”导航，键盘用户也无法 Tab 进去。
正确做法是保持 nav 始终在 DOM 中，仅用 visibility: hidden 或 clip-path 隐藏视觉呈现，同时确保：
- 折叠状态下的菜单仍可通过
aria-expanded="false"显式声明 - 展开按钮有
aria-controls指向对应nav的 id - JavaScript 切换时同步更新
aria-expanded和焦点管理（比如展开后自动 focus 第一个a）
语义结构一旦写进 HTML，就不能靠 CSS 或 JS “藏起来”了——它得一直可访问。
