nav标签必须包裹真实跳转链接，禁用伪链接、广告及操作控件；内部须用ul/li结构保障可访问性；多nav需aria-label区分；当前页必须设aria-current="page"且同步路由状态。
nav 标签必须包裹真实导航链接，不能塞广告或 JS 事件占位符
很多页面把 <nav></nav> 当成“带链接的 div”来用：里面塞了广告跳转、纯图标按钮（<button></button> 没 href）、或者只有 onclick 却没实际跳转能力的“伪链接”。这种写法会让屏幕阅读器识别出一个“导航区域”，但进去后发现全是哑巴链接——用户无法跳转，也无法理解当前上下文。
真正有效的 <nav></nav> 必须满足：至少有一个可聚焦、有明确 href 或合法 role="link" 的元素，且该元素代表真实页面间或页面内跳转意图。
- 该用：
@#@#@#@#@#@#@#@#@#@0、@#@#@#@#@#@#@#@#@#@1 - 不该用：
@#@#@#@#@#@#@#@#@#@2（没真实跳转） - 广告链接必须移出
<nav></nav>，哪怕它看起来像菜单项
ul + li 不是“可选装饰”，而是读屏播报结构的硬性依赖
去掉 <ul></ul> 和 <li>，只留 <nav>@#@#@#@#@#@#@#@#@#@3<li>@#@#@#@#@#@#@#@#@#@4</li></nav>
<div> + CSS Flex 替代 <code><ul></ul>，即使样式一模一样
<ul></ul>，不能靠 aria-haspopup 单独撑结构aria-current="page" 必须和 URL 状态严格同步，不能只靠 class
仅加 class="active" 对屏幕阅读器完全无效。用户按 Tab 键进入导航，听到的是“首页，链接；关于，链接；服务，链接”，根本不知道哪一个是当前页。尤其当多个导航项文字相同时（比如三个“详情”），不靠 aria-current 就无法区分。
这个属性不是“锦上添花”，而是告诉读屏“你现在就在这儿”的唯一可靠方式。而且它必须随路由变化实时更新——单页应用里，JS 切换视图后，只改 class 不改 aria-current，等于欺骗辅助技术。
- 合法值只有：
aria-current="page"（当前页面）、aria-current="step"（流程步骤）、aria-current="location"（地理定位） - 禁止用
aria-current="true"或aria-current="active"，W3C 不认，部分读屏直接忽略 - React/Vue 项目里，确保路由守卫或 useEffect 中同步设置 DOM 属性，不只是 class
多个 nav 共存时，aria-label 不是可选项，而是跳转前提
页面里同时有顶部主导航、侧边目录导航、页脚快速链接，却都只用裸 <nav></nav>，屏幕阅读器用户按 N 键跳导航时，只会停在第一个，然后卡住——因为所有 <nav></nav> 都没名称，读屏无法告知“你要跳去哪个导航”，更不会提供选择列表。
aria-label 是让每个 <nav></nav> 可被独立识别和跳转的最小必要条件。没有它，多导航场景下的可访问性直接归零。
- 必须写成：
<nav aria-label="主导航">...</nav>、<nav aria-label="文章目录">...</nav>、<nav aria-label="页脚链接">...</nav> - 避免用
aria-labelledby指向一个隐藏的<h2></h2>，除非该标题在 DOM 中真实存在且可聚焦 - 如果导航本身有可见标题（如“目录”），优先用
aria-labelledby关联它，比重复写aria-label更健壮
最常被绕过的点是：语义化不是“标签用了就完事”，而是每一步都要验证是否被辅助技术真实识别。打开 Chrome DevTools → Elements → Accessibility 面板，挨个点开 <nav></nav>，看 computed role 是不是 navigation、name 是不是你写的 aria-label、children 是否正确解析为 listitem —— 这三样缺一不可。
