nav 标签仅在包裹真实跳转链接、结构可访问、语义精准时生效；空、含 logo/搜索框或伪链接的 nav 会被忽略，必须按“站点级、重复性、主要跳转路径”标准筛选内容，内部用 ul/li 结构，当前页加 aria-current="page"，多 nav 需 aria-label 区分，href 须准确匹配部署路径与协议。
许多开发者对 HTML5 的 标签存在认知偏差，认为只要把看起来像导航的元素一股脑放进去，就能自动提升网站的可访问性与语义结构。然而实际情况并非如此——浏览器和屏幕阅读器的判断标准远比想象中严格。一个空的 ，或者混入了按钮、搜索框的 ，辅助技术很可能直接将其忽略。换句话说，用错位置不仅无法带来好处，反而会给依赖这些技术的用户制造障碍。
nav 标签不是为了“让导航看起来像导航”
那么，哪些链接应当纳入 ，哪些必须排除？核心判断标准在于：这组链接是否承担着「站点级、重复性、主要跳转路径」的功能。
- ✅ 应该放进去的典型代表：网站的顶部主导航菜单、侧边栏的目录导航、以及页面内部的锚点跳转链接。例如指向首页的
href="/index.html"，指向产品列表的href="/products"，或者指向页面内某个章节的href="#features"。 - ❌ 必须移出去的常见错误：用 JavaScript 控制的交互按钮（如
）、纯装饰性的 Logo 区域、搜索表单、以及社交媒体图标链接。这些元素要么不是链接，要么不属于站点级的主要导航路径。 - ⚠️ 需要特别处理的：面包屑导航。它可以放在
里，但必须用aria-label="面包屑"明确标注，并且不能和顶部的主导航混在同一个容器内。
内部结构怎么写才不踩坑
选对了链接，内部结构如何组织同样关键。使用 来包裹导航链接，不仅是为了方便编写 CSS 样式，更重要的是 WCAG（网页内容无障碍指南）和主流屏幕阅读器对这种列表结构有最稳定、最可靠的识别支持。如果只平铺一堆 标签，键盘导航用户可能无法感知到这是一个“导航列表”，Tab 键的顺序也容易变得混乱。
具体操作时，有几个细节务必注意：
- 结构必须完整：老老实实写成
，别为了省事省略。 - 标记当前页面：对于指向当前页面的链接（比如在“关于我们”页面时，导航里依然有“关于我们”的链接），一定要加上
aria-current="page"属性。这能明确告诉辅助工具用户当前所在的位置。 - 区分多个导航区域：如果一个页面有多个
（比如顶部导航和页脚导航），必须用aria-label为它们分别命名，例如和。 - 避免冗余角色：现代浏览器已经原生支持
的语义，再额外添加role="navigation"属性反而画蛇添足，甚至可能干扰解析。
href 值写错，nav 再规范也没用
前面说了这么多语义和结构，但最基础、也最常出问题的一环，其实是链接的 href 值。语义再准确，结构再完美，如果链接点不开或者跳错了地方，一切都是白费功夫。常见的错误往往不是语法问题，而是开发环境、部署路径和交互预期没有对齐。
这里有几个实用的避坑指南：
- 内部路径：对于网站内部的页面链接，优先使用根相对路径（如
href="/contact"），避免使用相对路径（如href="contact.html"），后者在子目录页面下很容易导致 404 错误。 - 锚点跳转：如果页面有固定定位的头部，锚点跳转时目标内容会被遮挡。解决方法是在 CSS 中为
html元素设置scroll-padding-top，或者直接给目标元素加上scroll-margin-top。 - 外部链接：指向其他网站的链接，必须包含完整的协议，写成
href="https://example.com"。只写href="example.com"会被当作相对路径处理。 - 邮箱链接：邮件链接务必写全
mailto:前缀，即href="mailto:help@example.com"。漏掉这个前缀，链接就会变成一个找不到的页面路径。
说到底， 标签本身并不处理任何跳转逻辑，它的核心职责是向浏览器和辅助技术清晰地宣告：“这里是一组导航链接”。至于导航是否真的能用、是否可靠，完全取决于每一个 href 的值是否与实际的路由、部署的目录结构以及协议层级严丝合缝地对得上。这一点，往往比语义本身更值得反复检查。
