浏览器原生 popover 怎么做无障碍菜单：焦点回收、关闭事件与兼容降级

做操作菜单如果只靠点击切换，鼠标用户用着好像没什么问题，键盘操作的用户很容易踩到两个明显的断点：菜单弹开之后焦点不知道落去了哪里，按 Escape 关掉菜单之后，焦点也未必能回到最开始触发它的按钮。现在完全可以先用浏览器原生 Popover API 搭出基础行为，再把能力检测和必要的降级路径补齐。

最小可靠方案是用带有 popovertarget 的按钮关联一个 popover 元素，让浏览器处理打开、轻量关闭和焦点返回；业务代码只监听状态变化，不要重新手写一套遮罩与焦点陷阱。

先把菜单任务说清楚

下面的例子是文章卡片右上角的“更多操作”：用户可以打开菜单，选择“复制链接”或“稍后处理”。它不是阻塞式对话框，页面其他内容仍然属于非模态场景；如果任务需要用户先完成确认，应该考虑 dialog 的模态能力，而不是把 popover 当成弹窗替代品。

菜单入口使用原生按钮，不用给一个普通的 div 强行加键盘监听。这样触发方式、可聚焦性和表单语义先有了稳定基础。

用 HTML 建立触发按钮和面板关系

最小写法只有一层关联：按钮的 popovertarget 值等于面板的 id。默认状态适合“同一时间只需要一个临时菜单”的场景。

订单周报
  
    更多
  

  

    复制链接
    稍后处理
  

按钮和面板之间的绑定关系还能帮辅助技术识别展开状态，面板显示时，按钮的展开语义会同步更新；关闭动作完成后，键盘焦点通常会自动回到打开它的按钮。这也是优先用原生关联能力的核心原因。

把键盘路径当成主流程验收

打开菜单后按 Tab，焦点应该能自然进入菜单内部的可操作按钮；按 Escape，菜单直接关闭，焦点回到触发按钮。用鼠标点击菜单外部区域，也应该触发浏览器默认的轻量关闭逻辑。这里不需要额外在页面上追加全屏遮罩，更不应该把页面主体设置成不可交互状态。

如果菜单里还有自定义控件，可以在打开后的状态中确认第一个按钮是否可见、可聚焦。不要用 autofocus 解决所有问题：它可能让复杂页面的焦点跳跃，先验证浏览器默认的焦点顺序，再决定是否需要精确聚焦。

const menu = document.querySelector('#order-actions');
const trigger = document.querySelector('[popovertarget="order-actions"]');

menu.addEventListener('toggle', (event) => {
  if (event.newState === 'open') {
    trigger.dataset.menuState = 'open';
  } else {
    delete trigger.dataset.menuState;
    trigger.focus();
  }
});

上面的监听器只做状态记录和保险式焦点回收。实际项目中，若关闭动作已经由浏览器返回焦点，再次调用 focus() 也要确认不会打断用户正在进行的键盘操作；当菜单可能由多个按钮打开时，应使用事件对象提供的来源信息记录正确触发者。

理解 auto、manual 和关闭事件的边界

默认的 popover 等价于自动状态，适合临时操作菜单。它能响应 Escape 和外部点击。popover="manual" 则把显示与隐藏交给代码，适合需要同时保留多个面板的少数场景，但也意味着你要自己承担关闭、状态同步和焦点验收。

需要在状态变化时更新按钮样式，可以监听 toggle；需要在状态切换前阻止某些变化，则使用 beforetoggle，但不要在这个事件里再次触发另一个 popover 的开关动作，否则可能遇到状态冲突。事件对象的 oldState、newState 和 source 适合做日志或轻量 UI 同步。

不支持原生能力时给出可用降级

不要仅凭浏览器名称判断兼容性。先检测 HTMLElement.prototype 是否拥有 popover，不支持时再启用现有菜单组件或最小的备用实现。备用实现至少要保留按钮可聚焦、Enter/Space 可打开、Escape 可关闭、点击外部可关闭以及关闭后返回触发按钮这几条行为。

const canUsePopover = Object.hasOwn(HTMLElement.prototype, 'popover');

if (!canUsePopover) {
  document.documentElement.classList.add('no-popover');
  // 在这里接入项目已有的菜单降级实现，不要把菜单内容隐藏成不可达状态。
}

能力检测通过也不代表所有周边配套能力都完全支持，定位、动画和新式 interest invoker 仍可能存在表现差异，所以移动端窄屏、缩放 200%、高对比度模式和全键盘操作的场景，都要单独走一遍验证流程。

上线前用一组短清单复查

• 触发控件是真正的 button，可见文本或标签能说明菜单用途。
• popovertarget 与面板 id 唯一匹配，页面上没有重复 ID。
• 鼠标、Tab、Enter/Space、Escape 四条路径都能正常完成打开和关闭操作。
• 关闭后焦点回到触发按钮，菜单内没有键盘完全无法触达的操作。
• 旧浏览器会走能力检测后的备用路径，不会出现内容永久隐藏的问题。
• 如果改用 manual，已有的多个面板、外部关闭和焦点管理都有对应测试。

相关问题

popover 能直接替代模态对话框吗？

不能。Popover 是非模态浮层，页面其他内容仍可交互；需要用户先处理确认、表单或危险操作时，应评估 dialog 的模态语义和焦点管理。

为什么不建议给每个菜单都手写全屏遮罩？

额外加遮罩反而会带来点击穿透、焦点困住、滚动锁定和关闭顺序混乱等更多问题。普通操作菜单优先用原生 auto popover 就好，只有产品交互需求确实超出它的能力边界时，再考虑引入自定义浮层。

小结

原生 Popover API 的价值不只是少写几行开关状态的代码，更重要的是把触发关系、轻量关闭逻辑和辅助技术语义都交给浏览器底层处理。前端代码可以集中放在业务动作处理、状态记录和兼容降级实现上；最后要用真实键盘操作路径复查焦点流转逻辑，而不是只看菜单能不能正常弹出来。