模态对话框里的Tab循环，为什么要与关闭动作一起说明

页面上覆盖一块带按钮的浮层，视觉上像对话框，键盘用户却还可能继续走到它背后的内容。模态对话框的关键因此不只是覆盖在什么位置，还包括打开后焦点怎样进入、在哪里移动，以及如何结束这一状态。W3C的Dialog (Modal) Pattern将这些行为分别说明。[1]

该模式把活动模态对话框下方的窗口内容描述为inert，即用户不能与对话框外的内容交互。Tab与Shift加Tab也不会把焦点送到对话框外。这里讨论的是模态模式的行为要求，不能从一层灰色背景直接推断某个页面已经做到这些事情。

Tab向内部下一个可Tab到达的元素移动；在最后一个元素上按Tab，则回到第一个。Shift加Tab反向移动，在第一个元素上操作时回到最后一个。两个方向形成内部循环。原文还特别说明，此处tabbable指tabindex为零或更大的元素，同时强烈不建议使用大于零的值。

循环本身并不回答怎样离开。该模式另外规定Escape关闭对话框，并强烈建议Tab顺序中包含可见的关闭按钮，例如关闭图标或取消按钮。因此，在设计交付里只写“焦点不能出去”，会漏掉结束对话框的动作；内部导航与关闭机制需要同时表达。

打开时焦点应进入对话框，但不意味着任何内容都机械地选第一个操作按钮。原文说明，内容的性质和长度会影响初始位置；若包含需要按结构阅读的列表、表格或多段内容，可以先聚焦开头的静态元素。对于较长内容，它还讨论了避免开头因聚焦而滚出视野的安排。

关闭后通常回到触发对话框的元素，模式也保留例外：原触发元素已经不存在，或流程中的下一步更适合其他位置。把返回目标与理由写清，可以避免关闭后位置不明。这里是对原模式的整理，没有替某个应用决定或安装焦点处理代码。

本次完整阅读的是APG网页提取文字，未打开示例、运行键盘或读屏测试。页面还提醒，标记aria-modal为true时，实际交互和视觉处理必须与模态相符；属性名称不是行为验收。本文解释界面模式，不据此宣告任何网站符合全部无障碍要求，页面首次发布日期仍未确认。