aria-haspopup="menu" 仅声明关联菜单，不触发ui提示或自动展开；必须配合 aria-expanded 状态管理、键盘交互（enter/space 切换、escape 关闭）、焦点控制、视觉反馈（箭头图标旋转等）及语义化菜单结构（role="menu"/"menuitem"）才能实现无障碍可访问菜单。
aria-haspopup="menu" 本身不触发任何 UI 提示
aria-haspopup="menu" 只是告诉辅助技术（如屏幕阅读器）“这个元素关联一个菜单”，它不会自动弹出菜单，也不会显示视觉提示。用户是否感知到“可展开”，完全取决于你后续的实现——尤其是焦点行为、键盘交互和视觉反馈。
必须配合 aria-expanded 和显式交互逻辑
单独设 aria-haspopup="menu" 而不管理 aria-expanded 状态，会导致屏幕阅读器读成“按钮，有弹出菜单”，但用户按空格/回车后没反应，体验断裂。
- 点击或按
Enter/Space时，要切换aria-expanded值（"true"/"false"） - 菜单显示/隐藏需同步更新
aria-expanded，且菜单元素应有role="menu"和正确aria-labelledby - 焦点必须可进入菜单项：推荐用
focusable的role="menuitem"，并支持方向键导航
视觉提示不能只靠 aria 属性
sighted 用户看不到 aria-haspopup。必须提供明确视觉线索：
- 在按钮右侧加一个向下箭头图标（
▾或 SVG），并确保足够清晰 - 悬停/聚焦时改变背景色或边框，强化可交互感
- 菜单展开时，箭头应旋转 180°（CSS transform），直观表示状态切换
- 避免仅用颜色区分——色觉障碍用户可能无法识别
常见错误：把 aria-haspopup 当成“自动下拉开关”
这是最常踩的坑：设了 aria-haspopup="menu" 就以为完事了，结果鼠标悬停没反应、键盘打不开、屏幕阅读器读出来却无法操作。
- 它不是 CSS
:hover的替代品，也不等价于details/summary - 不处理
Escape键关闭菜单？用户会卡住 - 菜单关闭后没把焦点移回触发按钮？键盘用户会丢失上下文
- 用
display: none隐藏菜单但没同步设aria-hidden="true"？屏幕阅读器可能仍尝试读取
真正的提示，来自一致的行为 + 明确的状态 + 可见的反馈——aria-haspopup 只是其中一环，而且是最容易被当成“已搞定”的那一环。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
