所有元素必须显式添加role="navigation"以兼容旧版屏幕阅读器，多个导航需用aria-label区分，下拉菜单须同步aria-expanded与aria-haspopup="menu"并动态管理焦点。
nav元素必须显式声明role="navigation"
即使用了<nav></nav>，旧版屏幕阅读器（如 JAWS 16、NVDA 2019.2 之前）仍可能忽略其语义，导致语音导航时跳过整个导航区。这不是 bug，而是 WAI-ARIA 规范明确要求的兜底行为。
正确写法是：<nav role="navigation"></nav>。不要写成 role="nav" 或 aria-role="navigation"——前者非标准值，后者属性名错误。
常见错误现象：键盘 Tab 进入导航后，屏幕阅读器只报“组”，不报“导航”，用户无法确认当前处于菜单上下文。
- 所有
<nav></nav>都应加role="navigation"，包括页脚里的次要导航 - 如果页面有多个
<nav></nav>，用aria-label区分，例如aria-label="主导航"或aria-label="快捷工具栏" - 避免嵌套
<nav></nav>——子菜单应放在父<li>内，用<ul></ul>表示层级，而非再套一层<nav></nav>
下拉菜单的 aria-expanded 和 aria-haspopup 必须动态同步
纯 CSS 实现的汉堡菜单或悬停下拉，在语音导航中极易“失联”：用户按 Tab 进入菜单项，却听不到“已展开”提示，也无法用方向键进入子项。
aria-expanded 控制读屏器播报状态，aria-haspopup="menu" 告诉辅助技术“此元素可触发子菜单”。二者缺一不可，且必须随视觉状态实时更新。
示例错误写法：@#@#@#@#@#@#@#@#@#@0 —— aria-haspopup 值应为"menu"，不是"true"；且未设aria-expanded。
- 初始状态：菜单收起时，
aria-expanded="false"；展开后立即改为"true" -
aria-haspopup是静态属性，始终为"menu"（不能是"dialog"或"listbox"） - 若用
input[type="checkbox"]驱动展开，需监听change事件更新这两个属性，不能只靠 CSS 类切换
焦点管理必须覆盖键盘操作全流程
语音导航重度依赖键盘 Tab / Shift+Tab / Enter / 空格 / 方向键。CSS-only 下拉菜单常忽略焦点流控制，导致子菜单展开后焦点仍卡在父链接上，用户无法用方向键进入子项。
关键点不在“能不能展开”，而在“展开后能不能被访问到”。这需要两层保障：DOM 顺序 + tabindex 控制。
- 子菜单
<ul></ul>必须紧跟对应<li>之后，确保 Tab 顺序自然向下 - 子菜单默认
tabindex="-1"，展开时保持该值；收起时仍保留，仅靠max-height: 0和overflow: hidden隐藏，不移除 DOM - 首次展开后，用 JavaScript 调用
.focus()主动将焦点移到子菜单第一个<a></a>，否则屏幕阅读器不会自动播报内容 - 按 Esc 键必须收起菜单并把焦点移回原触发链接——这点 90% 的纯 CSS 方案做不到
媒体查询断点与语音导航逻辑必须对齐
桌面端用:hover展开下拉，移动端用:checked触发汉堡，看似合理，但语音用户在平板横屏（768px）下可能既无法悬停，又没点击 checkbox——此时菜单既不响应 hover，也不响应 click，彻底不可达。
断点设计不能只看像素，要看交互能力。真正要对齐的是“用户能否可靠触发”的能力边界，而非设备宽度。
- 把
@media (hover: hover) and (pointer: fine)作为桌面逻辑开关，比min-width更准确 - 移动端逻辑应同时响应
pointer: coarse和hover: none，覆盖触屏平板、折叠屏、带触控笔的二合一设备 - 所有断点内的导航结构必须保证：键盘 Tab 可遍历、屏幕阅读器能识别层级、无 JS 时基础功能仍可用（如 checkbox 驱动的菜单）
aria-expanded的同步时机和tabindex="-1"的持续存在——它们不写在 HTML 里就等于没写，光靠 CSS 类名切换毫无意义。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
