How can I keep keyboard focus inside a modal dialog while it is open?

Choose a deliberate starting point inside the dialog and move focus there when it opens. Often that is the first useful control; for a short confirmation, it might be the primary action. If the dialog contains an explanation users should read before acting, you could instead focus an appropriate heading or introductory element, provided your implementation makes it focusable.

As one product-specific example, Microsoft’s WinUI keyboard guidance recommends placing initial focus on the most logical first or primary action and cautions against starting on a control with a potentially harmful outcome. That guidance is for Windows apps, not a universal specification for web dialogs. [S2]

Write down the reason for your choice. For example: “On open, focus the ‘Project name’ field because entering a name is the task’s first step.” Avoid moving focus to a destructive action just because it happens to appear first in the markup.

No. A visual dimming layer does not, by itself, define keyboard focus behavior. As an implementation requirement, specify that Tab moves through the dialog’s usable controls and wraps from the last to the first. Shift+Tab should move in reverse, wrapping from the first to the last. Keyboard users should not land on controls in the page behind the dialog while it is acting modally.

Microsoft’s Fluent UI Web Components documentation describes its modal dialog as making outside content inert and containing the tab sequence, so Tab and Shift+Tab do not move focus outside. This supports the containment behavior for that component; it does not prove that every overlay or dialog implementation behaves that way. [S1]

For a dialog with no obvious form controls, decide how a keyboard user enters and leaves the dialog’s content, and test the result. Also check that closing controls, such as a close button, are reachable without requiring a mouse.

As a practical behavior to specify and verify, return focus to the control that opened the dialog. That lets someone continue from the point where they started. If that control no longer exists or cannot receive focus, choose a nearby, meaningful fallback—for example, the next relevant control in the updated page—and make the fallback explicit in your design notes.

The two cited documents do not establish a universal focus-return rule: the Fluent UI extract addresses outside content and tab containment, while the WinUI extract addresses initial focus. Treat focus restoration as a separate behavior to specify and test, rather than assuming either source settles it. For dialogs opened from changing content, test the fallback after the content changes.

Use this copyable spec, adapting the bracketed parts to your interface:

“On open, move focus to [starting control] because [reason]. While the modal is open, Tab and Shift+Tab cycle through its usable controls; focus does not move to the page behind it. On close, return focus to [opening control]. If it is unavailable, move focus to [meaningful fallback].”

Then review it with a keyboard, without relying on a mouse: open the dialog, note the starting focus, press Tab through the controls until the sequence wraps, repeat with Shift+Tab, close the dialog, and check the returned focus. Repeat the close test after making the opener unavailable if that situation can occur. This is a behavior checklist, not a guarantee that any particular framework or overlay implements it automatically.