焦点陷阱是否应该阻止用户访问上下文 UI，例如浏览器？
Should a focus trap prevent a user from reaching the context UI like e.g. the browser?
当我们将焦点困在模态内时，焦点应该在模态内循环还是用户应该能够到达外部，比如浏览器 UI？
从网络官方规范看不清楚：https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal
至少在上述规范提供的示例中，它实际上是这样的，除了模态中的可聚焦元素之外，您无法触及任何东西：https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog.html
这会带来一些副作用，比如破坏开发者工具：
这里有一段视频可以进一步说明：https://streamable.com/i4zcsp
您只负责将焦点置于内容内。也就是说，任何 HTML。您不必担心用户将焦点转移到属于浏览器本身的其他交互元素。
我经常在浏览器中打开多个选项卡，查看不同的网站。如果其中一个页面碰巧打开了一个捕获键盘焦点的对话框，我会不希望我的焦点被捕获，这样我就无法将焦点放在浏览器的选项卡上面板并切换到另一个选项卡。我也不希望焦点被困住，以至于我无法进入浏览器的主菜单（文件、编辑、查看等）。我也不希望焦点被困住，以至于我无法进入浏览器的地址栏（alt+D 或 cmd+L）。
您的 OP 中的一个细微差别。您提到了对话框的“官方规范”。关于对话的规范语言，确实没有“官方”规范。您提到的“WAI-ARIA Authoring Practices”是一个很棒的资源，应该尽可能地遵循，但是不遵循它并不意味着您不符合 WCAG。注意在“1. Introduction”部分，它说的第一件事是：
This section is informative.
你可以看到informative and normative的定义。特别是：
Content identified as "informative" or "non-normative" is never required for conformance.
问得好！我的简短回答是：它不应该允许 tab 在模态之外。
长答案：
Like non-modal dialogs, modal dialogs contain their tab sequence. That is, Tab and Shift + Tab do not move focus outside the dialog. However, unlike most non-modal dialogs, modal dialogs do not provide means for moving keyboard focus outside the dialog window without closing the dialog.
这导致两件事：
- Tab 和 Shift + Tab 被困。到达最后一个（第一个）元素会将焦点移到另一端。
- 您有“将键盘焦点移出对话框的方法”。但是，您必须关闭对话框。
所以当你注册一个按键事件监听器（并处理Esc关闭对话框和恢复焦点）时，你还应该处理提到的Ctrl+L 到达 URL 栏（resp. Awesome Bar），也许 Ctrl+K 用于搜索栏。
为
查找更多键盘快捷键
考虑到多样性，您可能希望关闭所有未在内部处理的内容的模态。用户测试会提示您人们的期望。
关于开发人员工具：在另一个 window 中打开它们可能会成功。
当我们将焦点困在模态内时，焦点应该在模态内循环还是用户应该能够到达外部，比如浏览器 UI？
从网络官方规范看不清楚：https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal
至少在上述规范提供的示例中，它实际上是这样的，除了模态中的可聚焦元素之外，您无法触及任何东西：https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/dialog.html
这会带来一些副作用，比如破坏开发者工具：
您只负责将焦点置于内容内。也就是说，任何 HTML。您不必担心用户将焦点转移到属于浏览器本身的其他交互元素。
我经常在浏览器中打开多个选项卡，查看不同的网站。如果其中一个页面碰巧打开了一个捕获键盘焦点的对话框，我会不希望我的焦点被捕获，这样我就无法将焦点放在浏览器的选项卡上面板并切换到另一个选项卡。我也不希望焦点被困住，以至于我无法进入浏览器的主菜单（文件、编辑、查看等）。我也不希望焦点被困住，以至于我无法进入浏览器的地址栏（alt+D 或 cmd+L）。
您的 OP 中的一个细微差别。您提到了对话框的“官方规范”。关于对话的规范语言，确实没有“官方”规范。您提到的“WAI-ARIA Authoring Practices”是一个很棒的资源，应该尽可能地遵循，但是不遵循它并不意味着您不符合 WCAG。注意在“1. Introduction”部分，它说的第一件事是：
This section is informative.
你可以看到informative and normative的定义。特别是：
Content identified as "informative" or "non-normative" is never required for conformance.
问得好！我的简短回答是：它不应该允许 tab 在模态之外。
长答案：
Like non-modal dialogs, modal dialogs contain their tab sequence. That is, Tab and Shift + Tab do not move focus outside the dialog. However, unlike most non-modal dialogs, modal dialogs do not provide means for moving keyboard focus outside the dialog window without closing the dialog.
这导致两件事：
- Tab 和 Shift + Tab 被困。到达最后一个（第一个）元素会将焦点移到另一端。
- 您有“将键盘焦点移出对话框的方法”。但是，您必须关闭对话框。
所以当你注册一个按键事件监听器（并处理Esc关闭对话框和恢复焦点）时，你还应该处理提到的Ctrl+L 到达 URL 栏（resp. Awesome Bar），也许 Ctrl+K 用于搜索栏。
为
查找更多键盘快捷键考虑到多样性，您可能希望关闭所有未在内部处理的内容的模态。用户测试会提示您人们的期望。
关于开发人员工具：在另一个 window 中打开它们可能会成功。