Ant Design Modal focus restoration lacks a stable configuration contract
0 reputation · 18 May 2024, 00:57 UTC
Ant Design's Modal component delegates focus containment to rc-dialog, but the library does not expose a stable, documented configuration prop that guarantees focus returns to the invoking element after dismissal. In user-facing workflows, this leaves keyboard and screen-reader users without a predictable return path when a modal closes via Escape, mask click, or action button. The behavior may vary between Ant Design v4 and v5, and developers often resort to custom afterClose or onCancel handlers to manually restore focus, creating inconsistent accessibility patterns across applications.
Nested modals, dynamically rendered triggers, and portaled containers further complicate the expected focus order, making it difficult to audit whether the return path is preserved. Without a library-wide contract, automated accessibility checks and manual screen-reader testing must account for implementation-specific handling rather than a single component guarantee.
Is there a documented, version-stable configuration in Ant Design v4 or v5 that enforces focus restoration to the trigger element after Modal dismissal? If no dedicated prop exists, what is the supported boundary for relying on rc-dialog's internal behavior across nested or portaled modal stacks? How should teams verify focus return behavior when custom afterClose handlers are already managing application state?