HTML dialog 关闭后焦点去了哪里：returnValue、cancel 事件与无障碍恢复

原生

你有没有碰到过自己开发的模态框关闭后，按键盘Tab键突然跳到了完全不相关的页面底部元素上？原生HTML dialog 关闭后的默认焦点行为，很多人封装组件时没特意留意，很容易给无障碍体验埋下隐性问题。

关闭原生dialog后，浏览器默认会把焦点放回触发打开弹窗的那个元素，要是触发元素已经提前从DOM中移除，焦点就会脱离正常的可交互元素流，直接落到页面根节点上。

下面用一个保存设置的确认框串起整条事件链路。示例不需要依赖任何前端框架，打开页面后直接在浏览器控制台就能观察完整的事件触发顺序。

先把 dialog 的三个结果分开

show() 是非模态打开，页面其他区域仍可交互；showModal() 会进入模态状态，交互焦点被限制在对话框内。确认框通常应该使用后者，但不要把“模态”理解成“关闭后焦点自动回到原按钮”。

打开设置

    名称 
    取消
    保存
  

表单的 method="dialog" 不会提交到服务器，而是让按钮完成关闭动作。点击“保存”时，returnValue 会变成 ok；点击“取消”则是 cancel。如果直接调用 dialog.close()，没有传参数时结果通常是空字符串。

把 cancel、close 和 returnValue 接到同一条检查线上

cancel 是关闭请求阶段的事件，最常见的触发方式是按 Esc。它可以被 preventDefault() 拦住，例如表单有未保存内容时先给用户一次确认。close 则发生在对话框已经关闭之后，不能拿它阻止关闭。

const openButton = document.querySelector('#open-settings');
const dialog = document.querySelector('#settings-dialog');
let restoreFocusTo = null;

openButton.addEventListener('click', () => {
  restoreFocusTo = document.activeElement;
  dialog.showModal();
});

dialog.addEventListener('cancel', (event) => {
  if (dialog.querySelector('input').value === 'pending') {
    event.preventDefault();
    dialog.querySelector('input').focus();
  }
});

dialog.addEventListener('close', () => {
  const result = dialog.returnValue;
  console.log('dialog result:', result);
  if (restoreFocusTo instanceof HTMLElement) {
    restoreFocusTo.focus();
  }
});

这里有两个容易漏掉的细节。第一，保存焦点对象要发生在 showModal() 之前，否则保存到的可能已经是对话框里的元素。第二，焦点目标可能在关闭期间被移除，所以恢复前要重新确认它仍然是 HTMLElement，实际项目还应检查 isConnected 和 disabled 状态。

按钮结果和 Esc 取消不要混成一个状态

业务层最好只在 close 中读取最终结果，但要把“用户主动取消”和“按 Esc 放弃”区分开时，可以在 cancel 事件里先记录原因。默认 Esc 关闭时，returnValue 可能仍为空；不要用“非 ok 就算取消”替代真实的状态定义。

let closeReason = 'unknown';

dialog.addEventListener('cancel', () => {
  closeReason = 'escape';
});

dialog.addEventListener('close', () => {
  const result = dialog.returnValue || closeReason;
  if (result === 'ok') {
    saveSettings();
  } else {
    discardDraft({ reason: result });
  }
  closeReason = 'unknown';
});

如果业务要求 Esc 不许直接丢弃草稿，就在 cancel 中阻止默认关闭，再显示页面内的二次确认；不要在 close 之后试图把对话框“重新打开”来挽回焦点和状态。

焦点恢复要覆盖四个异常分支

• 触发按钮已被条件渲染移除：找到页面上的合理替代目标，例如表单标题。
• 触发按钮已禁用：不要强行 focus()，把状态提示放到仍可访问的容器。
• 对话框由程序直接关闭：仍然走同一个 close 处理器，避免漏掉清理。
• 对话框内没有合适的首个控件：给标题或关闭按钮增加 tabindex="-1"，并明确设置初始焦点。

可以在键盘操作下完成一次最小验收：按Tab选中“打开设置”按钮，按Enter唤起弹窗，弹窗内按Tab时焦点不应跳到遮罩外的页面元素上；分别点击保存按钮、点击取消按钮、直接按Esc键关闭弹窗，观察页面状态文本和焦点位置；最后提前移除触发按钮再关闭弹窗，确认页面不会出现焦点丢失的问题。

常见问题：原生 dialog 还要补哪些代码

调用 close() 后为什么 returnValue 是空的？

close() 没有传入返回值时不会凭空知道用户选择。需要业务结果时，使用 dialog.close('ok')，或让 method="dialog" 的按钮携带明确的 value。

cancel 事件能代替 close 事件吗？

不能。cancel 只代表收到关闭请求，而且可以被阻止；close 才是对话框已关闭后的统一收口点。

浏览器会自动恢复焦点吗？

不要把它当作可靠的业务契约。保存触发元素并在 close 中做存在性、可用性检查，才能覆盖组件卸载和程序关闭等路径。

把关闭流程变成可回归的验收表

一个可维护的确认框组件，至少要覆盖四个明确的行为定义：打开前记录下当前的焦点元素、明确返回按钮对应的操作结果、允许用Esc键触发关闭逻辑、关闭后指定好明确的焦点落点位置。把这四项写进组件测试用例或者手工验收记录里，后续不管换成React、Vue还是Web Components实现，组件的行为边界都能保持一致。