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。必须提供明确视觉线索：

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

• 在按钮右侧加一个向下箭头图标（▾ 或 SVG），并确保足够清晰
• 悬停/聚焦时改变背景色或边框，强化可交互感
• 菜单展开时，箭头应旋转 180°（CSS transform），直观表示状态切换
• 避免仅用颜色区分——色觉障碍用户可能无法识别

常见错误：把 aria-haspopup 当成“自动下拉开关”

这是最常踩的坑：设了 aria-haspopup="menu" 就以为完事了，结果鼠标悬停没反应、键盘打不开、屏幕阅读器读出来却无法操作。

立即学习“前端免费学习笔记（深入）”；

• 它不是 CSS :hover 的替代品，也不等价于 details/summary
• 不处理 Escape 键关闭菜单？用户会卡住
• 菜单关闭后没把焦点移回触发按钮？键盘用户会丢失上下文
• 用 display: none 隐藏菜单但没同步设 aria-hidden="true"？屏幕阅读器可能仍尝试读取

真正的提示，来自一致的行为 + 明确的状态 + 可见的反馈——aria-haspopup 只是其中一环，而且是最容易被当成“已搞定”的那一环。