Your build starts here
Replace bracketed details with your own goal, context, and checks. Keep the first build small enough to inspect.
Review [list-to-dialog workflow] using the actual implementation and the applicable dialog pattern. Identify how the dialog opens, where focus initially belongs, how its name is exposed, how it closes, and the intended destination after closing. Include [save, delete, filter, or refresh] operations that can change the underlying list.
Keep the active modal interaction contained and make its keyboard close behavior deliberate. When the original trigger no longer exists, choose a stable logical destination rather than focusing a detached element or sending the user to the page start. Preserve useful draft or error feedback when an operation fails.
Verify forward and reverse keyboard navigation, Escape where appropriate, successful mutation, failed mutation, an empty list, and reopening. Record the focused element at each transition. Report actual keyboard and assistive-technology checks separately.Make this prompt yours
Name the logical fallback in product terms, such as the next item or list heading, instead of prescribing an arbitrary selector.
You might also hear
- modal focus restore
- deleted trigger
- dialog keyboard
- focus fallback
- list mutation
The docs behind it
These references explain the underlying concepts and APIs. The prompt templates and project plans are original examples to adapt to your own setup.
Research sources reviewed .
Editorial review · October 28, 2026
Supported: Original modal review template. WAI supports contained modal focus and a logical return destination when the trigger disappears; failed mutation and record-change journeys are proposed tests.