aria-haspopup 不该设为 true，而应明确设为 "menu" 等具体类型；设为 true 已被 wai-aria 1.1 废弃，会导致屏幕阅读器无法识别弹出内容类型，丧失关键语义。
aria-haspopup 应该设成 true 还是 menu
直接说结论：aria-haspopup 不该设为 true，而应明确指定弹出类型，最常见的是 "menu"。设成 true 虽然不报错，但会丢失语义信息，导致屏幕阅读器无法准确告知用户“这是菜单”还是“这是对话框”或“这是列表”。
WAI-ARIA 1.1 规范已将 true 和 false 标记为过时值，只保留以下合法字符串值：
-
"menu"：对应右键菜单、下拉菜单（如<select></select>的替代实现） -
"listbox"：弹出一个可选中项的列表（类似自定义<select></select>） -
"tree"：弹出树形结构（如文件夹导航） -
"grid"：弹出二维表格结构（如日期选择器） -
"dialog"：弹出模态或非模态对话框（如点击「帮助」打开的帮助面板）
实际项目中 90% 场景用 "menu" 就够了；若弹出的是纯文字说明浮层（无交互），反而不该加 aria-haspopup，而该用 aria-describedby 或 role="tooltip"。
为什么只加 aria-haspopup 不够，还必须配 aria-expanded
单设 aria-haspopup="menu" 只告诉辅助技术“这儿能弹东西”，但没说明“当前弹开了没”。用户无法判断按钮是待触发状态，还是已展开、焦点正落在菜单里——这会导致重复操作或迷失上下文。
必须同步管理 aria-expanded 的布尔值：
- 菜单收起时：
aria-expanded="false" - 菜单展开且获得焦点时：
aria-expanded="true" - 这个属性要随真实 DOM 状态实时更新，不能靠 CSS visibility 或 opacity 控制后就忘了改它
- 注意：只有可展开/收起的控件才需要
aria-expanded；如果是点击即跳转新页、或打开新窗口，就不该加
示例片段：
<button aria-haspopup="menu" aria-expanded="false">账户</button>
aria-haspopup 和 role="menu" 的 DOM 结构怎么连才有效
光写对属性还不够，DOM 层级和角色组合必须符合 WAI-ARIA Authoring Practices 指南。常见错误是把 role="menu" 直接挂在 <div> 上却不设 <code>aria-labelledby，或让菜单脱离按钮的视觉/逻辑流。
正确做法：
- 触发按钮和弹出菜单之间要有明确的 DOM 关联：推荐用
aria-controls指向菜单容器的id（例如aria-controls="user-menu"） - 菜单容器必须有
role="menu"，且每个可交互项用role="menuitem"（不是button或div） - 菜单项内如果嵌套链接，需确保键盘焦点能自然落入（
tabindex="-1"+ 手动 focus 管理） - 避免用
display: none隐藏菜单——它会直接从可访问树中移除；改用hidden属性或visibility: hidden; position: absolute;配合aria-hidden="true"
浏览器和读屏器对 aria-haspopup 的支持差异
Chrome + NVDA 基本能正确播报“账户，菜单，已折叠”；但 Safari + VoiceOver 在某些版本里会忽略 aria-haspopup，只依赖 role="menu" 和父子关系。更麻烦的是，部分 Android TalkBack 版本会把 aria-haspopup="dialog" 错报成“弹出窗口”，而实际是轻量浮层。
所以不能只信属性，还得靠行为兜底：
- 确保键盘操作可用：按钮支持
Enter/Space展开，Escape收起，ArrowDown进入菜单 - 菜单展开后，焦点必须自动移到第一个
menuitem上 - 用
document.activeElement和aria-activedescendant配合处理复杂菜单（比如带搜索的下拉） - 真遇到兼容问题，优先保功能流（键盘+焦点+语义角色），再优化
aria-haspopup的精确值
最常被忽略的一点：弹出菜单关闭后，焦点必须回到原触发按钮，并重置 aria-expanded="false" —— 很多人只管打开，不管收尾。
