元素已被w3c标记为废弃，无语义、不被屏幕阅读器识别；应改用 搭配 和 aria 属性实现语义化导航，下拉菜单须用 role="menu" 及完整键盘交互逻辑。
menu 元素早就被废弃了，别再用
HTML5 里 <menu></menu> 没有实际语义，也不被主流屏幕阅读器识别，Chrome、Firefox 已将其降级为无意义的容器标签。W3C 明确标记为“obsolete”，MDN 文档里也写着“不推荐使用”。你写 <menu></menu>，浏览器不会报错，但等于白写——既不提升可访问性，也不影响渲染逻辑。
常见错误现象：<menu></menu> 套 <li> 后发现键盘 Tab 焦点跳过、NVDA 读不出“菜单”、移动端双指长按无上下文响应。本质是它根本不是语义化菜单元素。
- 真正该用的是
<nav></nav>（主导航）、<aside></aside>（侧边辅助导航）或带role="navigation"的容器 - 下拉/弹出类交互菜单，必须用
<ul></ul>+<li>+role="menu"/role="menuitem"配合 ARIA 属性 - 如果只是纯链接列表，
<nav><ul></ul></nav>就够了，加aria-label明确用途更稳妥
用 nav + ul 实现语义清晰的主导航
<nav></nav> 是唯一被广泛支持、具备明确导航语义的块级元素。它告诉辅助技术“这里是一组跳转入口”，且天然被搜索引擎和浏览器书签工具识别。
使用场景：页头主菜单、页脚分类链接、面包屑导航前的返回入口。
立即学习“前端免费学习笔记（深入）”；
参数差异不大，但有两个关键点不能漏：
- 必须给
<nav></nav>加aria-label或aria-labelledby，否则多组<nav></nav>时屏幕阅读器分不清哪个是“主导航” -
<ul></ul>内部必须用<li>包裹每个链接，不能直接放<a></a>—— 否则语义断裂，焦点管理失效 - 移动端点击区域小？别改
<a></a>的 padding，而是用display: block让整个<li>可点
示例：
<nav aria-label="主导航">
<ul>
<li><a href="/home">首页</a></li>
<li><a href="/products">产品</a></li>
</ul>
</nav>
下拉菜单必须靠 ARIA role + 键盘逻辑撑住
纯 HTML 没有“下拉菜单”原生元素。所有 hover 弹出、点击展开的菜单，都得靠 role="menu" 这套 ARIA 模式补全语义和交互预期。
容易踩的坑：
-
role="menu"必须直接作用在容器上（如<ul></ul>），子项用role="menuitem"，不能套在<div> 里再塞 <code><ul></ul> - 必须手动实现键盘导航：方向键切换焦点、Enter/Space 触发、Esc 关闭——CSS
:hover或click事件监听不够 - 菜单展开时，要动态设
aria-expanded="true"在触发按钮上，并用aria-controls指向菜单 ID - 焦点不能丢失：菜单关闭后，焦点应回到触发按钮；展开时，第一个
menuitem自动获得焦点 - 搜索框旁的“热门关键词”列表 → 用
<section></section>+aria-labelledby，不是<nav></nav> - 文章内“相关阅读”链接块 →
<aside></aside>更合适，它表示与主内容相关但非核心的导航 - 用户头像下拉的个人中心 → 必须是
role="menu"，且按钮要有aria-haspopup="true"
性能影响很小，但兼容性差在 JS 逻辑没写全——Safari 对 role="menu" 的键盘支持比 Chrome 更严格。
不要为了“结构好看”嵌套 nav 或 menuitem
一个页面通常只有一处主导航，最多再加一个页脚导航或语言切换栏。滥用 <nav></nav> 不会加分，反而让辅助技术困惑。
真实场景中，这些结构常被误用：
复杂点在于：菜单是否需要支持多级？ARIA menu 模式默认只处理一级。二级弹出得用 role="menuitem" + aria-haspopup="true"，再挂载另一个 role="menu" 容器——但这时键盘逻辑就得递归处理，稍不留神焦点就卡死。
