<nav>必须包裹完整导航链接集合并设aria-label或aria-labelledby,禁止单链接、混入非导航元素,推荐原生列表结构,复用宜用服务端包含或构建工具。
<nav> 不是装饰性容器,它必须包裹一组导航链接,且需明确语义边界——否则屏幕阅读器可能跳过、Lighthouse 报 Navigation landmark not present。
常见错误现象:<nav>首页</nav> 或 <nav><a href="/">首页</a></nav>。这类写法会让辅助技术降级为普通段落,失去导航地标(landmark)作用。
<ul> 或 <ol> 包裹多个 <li>,每个含一个 <a>
<div role="list"> 替代,但优先选原生列表<nav>
没有可见标题的 <nav>(比如纯图标汉堡菜单、无文字的页脚快捷入口),光靠标签名无法传达用途。屏幕阅读器只会读 “navigation”,用户不知道这是主菜单还是语言切换区。
aria-label="主导航" 适合命名固定、无需翻译的场景aria-labelledby="nav-title" 更灵活,对应一个隐藏但可访问的标题,例如 <h2 id="nav-title" class="visually-hidden">管理面板导航</h2>
aria-labelledby 会覆盖 aria-label
搜索框、登录表单、主题切换按钮、语言下拉选择器,哪怕视觉上紧挨着导航栏,也不属于导航语义范畴。混入会导致自动化测试报 Landmark contains non-navigation content,键盘用户 Shift+Tab 也可能卡在非链接控件里。
立即学习“前端免费学习笔记(深入)”;
<search> 标签包裹<form> 或 <section aria-label="用户账户">
<nav>,但必须加 aria-label="当前位置"
<nav>:例如 <nav aria-label="主导航"> + <nav aria-label="相关文章"> + <nav aria-label="页脚快速入口">
直接在每个 index.html 里手写一遍 <nav> 结构,维护成本高、易出错。现代项目里有几种可靠复用方式:
.shtml,用 <!--#include file="nav.html" -->,无 JS 依赖,SEO 友好fetch('nav.html') 插入到 <div id="navbar"></div>,注意加 catch 处理失败html-webpack-plugin 或 vite-plugin-html 注入;Vue/React 直接封装为组件<iframe> 或内联 <object>:破坏语义流、影响焦点管理和无障碍遍历最容易被忽略的一点:<nav> 不提供任何默认样式或交互逻辑,它的价值全在语义层。写完记得跑一次 axe 或 Lighthouse,看是否触发 landmark-no-duplicate-main 或 navigation-landmark 类警告——这些不是“建议”,而是无障碍合规的实际门槛。