nav标签自带role="navigation"，被识别为独立地标区域，影响VoiceOver和TalkBack的阅读顺序与地标跳转；必须配合aria-label区分多导航区，内部需含可聚焦元素且避免嵌套或条件渲染导致地标缺失。
nav标签如何影响VoiceOver和TalkBack的阅读顺序
移动端语音辅助工具（如iOS VoiceOver、Android TalkBack）不是按HTML源码顺序线性读取，而是先构建语义大纲，再依地标（landmark）跳转。<nav></nav>自带role="navigation"，会被识别为独立地标区域；而<div class="nav">默认是<code>role="generic"，直接被跳过或降级为普通容器。这意味着用户按Control + Option + U（VoiceOver）或Local Context Menu + 5（TalkBack）唤出地标列表时，只有<nav></nav>能出现在可选菜单里。
常见错误现象：
- 多个
<nav></nav>没加aria-label，全部朗读为“导航”，用户无法区分顶部主菜单和页脚快捷链接 - 用
<div role="navigation">替代<code><nav></nav>，但漏写tabindex="0"，键盘焦点无法进入该区域 - 在React中把
<nav></nav>包裹在<div id="root">内，却未确保它在DOM渲染后真实存在——动态插入失败时，整个导航对读屏器“不可见” <h3>移动端多导航区必须显式标注aria-label</h3> <p>一个页面可能有顶部主导航、底部资源导航、面包屑导航，甚至侧滑菜单。仅靠<code><nav></nav>无法区分它们，因为所有<nav></nav>的默认名称都是“导航”。屏幕阅读器不会猜你意图，必须靠aria-label提供唯一、简洁、功能导向的名称。实操建议：
立即学习“前端免费学习笔记（深入）”；
- 主菜单用
<nav aria-label="主菜单"></nav>，避免“顶部导航”这类位置描述，Focus on function（如“网站全局导航”） - 页脚链接组用
<nav aria-label="快速链接"></nav>，而非“页脚导航” - 面包屑单独用
<nav aria-label="当前位置"></nav>，与导航逻辑分离 - 禁止给
<nav></nav>加aria-labelledby指向一个隐藏<h2></h2>——移动端读屏器对aria-labelledby支持不稳定，优先用aria-label
nav内部结构必须满足移动端聚焦与跳转前提
即使写了
<nav></nav>，如果内部没有可聚焦元素，VoiceOver/TalkBack会直接跳过整个区域。这不是bug，是设计逻辑：没有交互入口的“导航”，对用户无意义。关键约束条件：
-
<nav></nav>内部至少包含一个<a href></a>或<button></button>，且不能全部disabled或aria-hidden="true" - 避免用
<span onclick="..."></span>模拟链接——它不响应Tab键，也不被读屏器识别为导航项 - 下拉菜单的父级
<li>必须是可聚焦的，推荐用<button type="button" aria-expanded="false"></button>，而非<a href="https://www.php.cn/link/93ac0c50dd620dc7b88e5fe05c70e15b"></a>加preventDefault - 移动端触控目标尺寸必须≥48×48 CSS像素，否则焦点环可能无法稳定停驻，导致“跳过下一项目”现象
嵌套与重复使用nav会破坏移动端地标识别
移动端读屏器依赖清晰、扁平的地标层级。嵌套
<nav></nav>（比如<nav><nav>...</nav></nav>）会让VoiceOver误判为“导航中的导航”，部分版本直接忽略内层；重复出现<nav></nav>且无aria-label，则地标列表出现多个同名项，用户无法选择。容易被忽略的细节：
-
<nav></nav>不能放在<header></header>或<aside></aside>内部——它必须是顶层语义容器，否则某些Android版本TalkBack会降权处理 - 服务端渲染（SSR）页面中，若首屏HTML未包含
<nav></nav>，而靠JS动态插入，会导致首次加载时地标缺失；需确保初始DOM含语义结构 - React/Vue组件中，
<nav></nav>不应被v-if或useState条件渲染“消失”，否则地标列表实时更新延迟明显，用户切换页面后仍听到旧导航
- 主菜单用
