aria-haspopup 用于声明弹出内容的具体类型（如 menu、listbox、dialog），而非泛泛提示“有弹窗”；必须严格匹配弹出容器的 role，且需手动实现键盘交互与状态同步。

aria-haspopup不是“提示有弹窗”，而是声明弹出内容的类型

很多人以为加了 aria-haspopup="true" 就能让屏幕阅读器说“这个按钮有弹窗”，但这是错的。它真正的作用是告诉辅助技术：“这个元素激活后，会弹出一个 特定类型 的交互式内容”，比如菜单、对话框或列表框——而不是泛泛的“弹窗”。

用错值会导致读屏器跳过、误读，甚至完全忽略子菜单逻辑。例如：

• aria-haspopup="true" 是 ARIA 1.1 已废弃的值，NVDA/JAWS 可能直接不播报，VoiceOver 可能报“未知弹出类型”
• aria-haspopup=""（空字符串）或 aria-haspopup="dialogue"（拼写错误）属于非标准值，AT 行为不可预测
• 给 <details></details> 或原生 <select></select> 加 aria-haspopup 属于冗余，反而干扰语义

该用哪个值？看弹出内容的真实 role

必须严格匹配你实际渲染的弹出容器的 role，否则键盘用户无法导航、AT 无法同步状态：

• 弹出的是 <ul role="menu"></ul> + <li role="menuitem"> → 用 aria-haspopup="menu"
• 弹出的是 <div role="listbox"> + <code><div role="option">（如自定义下拉）→ 用 <code>aria-haspopup="listbox"，且触发器要配 role="combobox"
• 弹出的是 <dialog role="dialog" aria-modal="true"></dialog> → 用 aria-haspopup="dialog"，并确保 aria-controls 指向该 <dialog></dialog> 的 id
• 弹出的是树形结构（role="tree"）→ 用 aria-haspopup="tree"，不能简写成 "menu"

值选错，屏幕阅读器可能把菜单项读成“按钮”或“文本”，键盘方向键失效，用户根本不知道怎么操作。

为什么加了 aria-haspopup 键盘还是打不开？

aria-haspopup 不触发任何行为，它只是“说有”，不是“让它有”。键盘支持（Enter/Space 展开、Esc 关闭、Arrow 键导航）必须手动实现：


Doc To HTML
使用 MinerU 文档处理引擎将 Word 文档（.doc、.docx）转换为保留结构和格式的干净 HTML。
下载
• 触发器（如 <button></button>）需监听 keydown，对 Enter 和 Space 调用展开逻辑
• 展开后必须立即将焦点移到第一个可交互项（如第一个 menuitem 或 option）
• 必须同步更新 aria-expanded="true"（关闭时设为 false），否则 AT 不知道当前状态
• 菜单容器要设 role="menu"（或其他对应 role），每个子项要有正确 role 和 tabindex="0"（或隐式可聚焦）

漏掉任意一环，键盘用户就会卡在按钮上，反复按 Space 却没反应——这不是 aria-haspopup 写错了，是交互链断了。

比 aria-haspopup 更简单的情况：优先用

如果只是展开一段说明文字、静态提示或无复杂交互的面板，别硬套 aria-haspopup。直接用原生 <details></details>：

<details><summary>常见问题</summary><p>这里是展开内容...</p>
</details>

它自带以下能力，无需 JS：

• 键盘 Space 切换展开/收起
• 屏幕阅读器自动播报“已折叠/已展开”状态
• 语义明确，所有主流 AT（NVDA、JAWS、VoiceOver）都支持一致

aria-haspopup 是给“菜单”“对话框”“树”这类需要完整键盘导航和焦点管理的复杂组件准备的。用错场景，反而增加 bug 风险和维护成本。