A dialog may look finished when its close button disappears, while the keyboard user is left at the top of the document. This is easiest to miss when a team tests the open dialog but stops before testing the return trip. The W3C Authoring Practices Guide describes both directions: move focus into a modal when it opens and, in the usual case, return it to the invoking control when it closes.
Check the whole interaction
Start on the button that opens the dialog. Activate it with a keyboard, then inspect where focus lands. It should move to an element inside the dialog. Tab forward and backward: focus should remain within the active modal. Close it with the provided control, then repeat with Escape. After closing, find the visible focus indicator and continue tabbing. Can the user understand where they are without starting over?
When the original trigger still exists, returning focus there usually keeps the workflow intact. When closing the dialog removes its trigger—for example, after deleting a row—the W3C guidance allows another logical destination. In that case, define and test the destination instead of sending focus to the page body.
Treat opening and closing as separate states
A checklist limited to ARIA attributes will not prove that the focus path works. Test the initial focus, the forward and reverse Tab sequence, Escape, the close control, and the post-close destination. If the dialog has a long heading or several paragraphs, consider whether initial focus on static content helps users orient before reaching an action. W3C's dialog pattern explains why that choice depends on the content.
A scan can help identify accessibility barriers, but this sequence also needs manual keyboard testing. ADAFix website accessibility repairs can be part of a broader review and documented repair workflow; it does not replace checking the dialog's real behavior with a keyboard.
Source: W3C WAI modal dialog pattern.
Top comments (0)