aria-haspopup必须设为menu、listbox、tree、grid、dialog之一，禁用true；因ARIA 1.1已废弃该值，否则语义错误且读屏器可能忽略子菜单逻辑。
aria-haspopup 的取值和语义到底怎么选
辅助技术（比如屏幕阅读器）靠 aria-haspopup 判断一个元素是否关联弹出内容，但它的值不是“true/false”二选一——必须明确弹出类型，否则会被当作无效或降级处理。最常见错误是写成 aria-haspopup="true"，这在较新版本的 ARIA 规范中已被弃用（ARIA 1.1+），屏幕阅读器可能直接忽略或报错。
实际应使用以下取值之一：
-
aria-haspopup="menu"：对应传统下拉菜单（如导航栏中的“产品 > 解决方案”） -
aria-haspopup="listbox"：用于带选项列表的控件（如自定义<select></select>替代组件） -
aria-haspopup="tree"：适用于可展开/折叠的树形结构（如文件浏览器侧边栏） -
aria-haspopup="grid"：弹出的是二维表格布局（如日期选择器） -
aria-haspopup="dialog"：弹出模态对话框（注意：此时还应配aria-modal="true"和焦点管理）
为什么光加 aria-haspopup 不够，还得配 role 和焦点逻辑
只加 aria-haspopup 是“说有弹窗”，但辅助技术不会自动知道它该被当作什么角色来读、怎么交互。例如一个按钮触发菜单，必须同时声明 role="button"（哪怕它是 <div>），否则屏幕阅读器可能读作“未命名区域”，用户根本不知道能点。
<p>关键配套动作：</p>
<p><span>立即学习</span>“<a href="https://pan.quark.cn/s/cb6835dc7db1" style="text-decoration: underline !important; color: blue; font-weight: bolder;" rel="nofollow" target="_blank">前端免费学习笔记（深入）</a>”；</p>
<ul>
<li>触发元素必须有明确的 <code>role（button、combobox、menuitem 等），不能仅靠 CSS 样式伪装
role：菜单用 role="menu"，列表用 role="listbox"，对话框用 role="dialog"
Esc 关闭时，焦点应回到触发元素（且保持其 aria-expanded="true" 状态同步更新）aria-expanded 和 aria-haspopup 的配合陷阱
很多人以为 aria-haspopup 自动暗示“当前展开/收起状态”，其实完全不相关——它只描述“能力”，不描述“状态”。是否展开必须单独用 aria-expanded 控制，且它只对 button、combobox、menuitem、tab、treeitem 这几类 role 合法。
典型翻车场景：
- 给
<div role="navigation"> 加 <code>aria-expanded：无效，该 role 不支持此属性 - 菜单未展开时写了
aria-expanded="true"：屏幕阅读器会误读为“已打开”，用户按 Enter 却没反应 - 切换状态后忘了同步更新
aria-expanded：焦点在弹出层时按 Tab 离开，再回来无法感知当前状态 - 用 NVDA + Firefox 或 VoiceOver + Safari，按
Tab到触发元素，听读出的内容是否包含“has popup”或“menu”等关键词（例如：“产品，按钮，has popup menu”）——如果只读“产品，按钮”，说明aria-haspopup值不对或缺失 - 弹出后按
↓键，焦点是否自然进入第一个菜单项？如果焦点卡住或跳到页面底部，大概率是弹出容器缺少role="menu"或未及时focus()
正确做法：点击按钮 → 弹出菜单 → 设置 aria-expanded="true" + aria-controls="menu-id"；关闭后设为 "false"。
测试时容易被忽略的两个真实断点
开发完常跑一遍 axe 或 WAVE，但它们测不出动态行为。真正影响用户的两个点，往往要手动验证：
移动端的触摸反馈也别漏：iOS VoiceOver 双击触发时，若弹出层没有 role 和 aria-modal，系统可能不阻断背景交互，导致操作错乱。
