aria-labelledby比aria-label更适合导航区域，因为它能复用页面中已有的可见标题（如<h2 id="nav-title">导航</h2>），避免硬编码导致的文案脱节、多语言维护困难及重复朗读问题。
为什么 aria-labelledby 比 aria-label 更适合导航区域
因为导航栏通常有明确的视觉标题（比如“主菜单”），而 aria-labelledby 能复用已有文本节点，避免冗余字符串和翻译维护问题。用 aria-label 硬编码容易和 UI 脱节——改了页面文字却忘了同步更新 aria 属性，屏幕阅读器就会读错。
- 优先指向一个
id对应的可见标题元素（如<h2 id="nav-title">导航</h2>），而非写死字符串 - 若无显式标题，再考虑用
aria-label="主菜单"，但必须确保该文案与设计系统一致 - 不要对
<nav>同时设aria-label和aria-labelledby，后者会覆盖前者，且可能引发重复朗读
如何让 <nav> 的结构被辅助技术准确识别
HTML5 的 <nav> 元素本身已自带 role="navigation"，但仅靠它不足以表达层级关系。嵌套的 <ul><li><a> 是标准模式，但若用了自定义组件（如 <div role="menu">），就必须补全所有语义属性。
- 一级菜单项用
role="menuitem"，并加tabindex="0"保证键盘可聚焦 - 展开/折叠状态必须通过
aria-expanded="true/false"实时同步，不能只靠 CSS 类控制 - 子菜单容器需设
role="menu"，且用aria-haspopup="true"标明触发行为 - 禁用项要同时设
aria-disabled="true"和tabindex="-1"，否则键盘仍能聚焦
键盘导航中 ArrowUp/ArrowDown 失效的常见原因
很多实现只处理 Tab 键切换，却忽略方向键遍历——这直接导致不支持鼠标的操作者无法高效使用下拉菜单。根本问题常出在事件监听或焦点管理逻辑上。
- 监听的是
keydown而非keypress（后者已被废弃，且不捕获方向键） - 未阻止默认行为：
event.preventDefault()缺失会导致页面滚动而非菜单移动 - 焦点未按 DOM 顺序正确迁移：应跳过隐藏项（
aria-hidden="true"或display: none），只聚焦可操作项 - 动态加载的子菜单项，其
tabindex值未在显示后重置为0
用 document.querySelectorAll 扫描大纲时漏掉 <h1> 到 <h6> 之外的导航锚点
依赖 h1–h6 构建大纲是基础，但真实项目里常有跳转到 <section id="contact"> 或 <div id="faq"> 的链接。这些 ID 若未出现在 heading 元素中，就不会被辅助技术识别为大纲节点。
立即学习“前端免费学习笔记（深入）”；
- 对关键内容区块补充
aria-labelledby指向一个隐藏但可访问的标题：<div id="faq" aria-labelledby="faq-label">...</div><span id="faq-label" class="visually-hidden">常见问题</span> - 避免用
aria-hidden="true"包裹整个导航区域——即使视觉上折叠，也要保留其语义结构 - 运行时检查可用性：用浏览器 DevTools 的 Accessibility 面板查看“Landmarks”和“Headings”，确认
<nav>和所有id锚点都列在其中
真正麻烦的不是写对一行 aria 属性，而是当 JS 动态渲染菜单、路由切换后，那些属性是否还活着——状态同步比初始渲染更难盯住。
