When developing a modal component using the native <dialog> element’s showModal method, it might be observed that focus can tab out of the dialog (even in modal mode) and onto the browser’s address bar.
This behavior can be surprising, as common accessibility guidance for modals has historically emphasized the need to trap focus within the modal itself.
However, further investigation reveals that trapping focus within the <dialog> element (even when in modal mode) is no longer a requirement. Therefore, focus-trapping advice is considered deprecated when using the native <dialog> element.
Key Insights
To provide context without requiring a full review of the extensive GitHub Issue discussion, several key points from prominent individuals are summarized below.
Scott O’Hara provided comments shedding light on the history and context of focus-trapping recommendations:
WCAG does not normatively mandate that focus must be trapped within a dialog. The normative WCAG specification contains no explicit requirements for focus behavior within a dialog.
The informative 2.4.3 focus order understanding document does discuss limiting focus behavior within a dialog. However, this guidance applies to scripted custom dialogs and predates the widespread availability of the inert attribute or the native <dialog> element.
The ARIA Authoring Practices Guide (APG) aims to illustrate ARIA usage. Without native HTML features such as <dialog> or inert, trapping focus within a custom dialog was considerably simpler than replicating the behavior provided by the <dialog> element.
Both the APG modal dialog guidelines and the WCAG understanding document were developed prior to broad support for the inert attribute or the <dialog> element. The alternative to advising developers to trap focus would have been to instruct them to set tabindex="-1" on all focusable elements outside the modal dialog.
Léonie Watson contributed, explaining why it is acceptable for a screen-reader user to shift focus to the address bar:
Within a standard page context, users can tab out of the content area, navigate browser chrome, use keyboard commands to access the address bar or menus, or close the tab. This flexibility provides users with choices for escaping the current context.
It appears logical for similar options to remain available to users within a dialog context, mirroring the behavior in a standard page context.
Finally, Matatk presented the conclusion from the W3C’s Accessible Platform Architectures (APA) Working Group, which endorsed the idea that the <dialog> element’s showModal method does not necessitate focus trapping.
The APA Working Group addressed this question across multiple meetings, concluding that the native dialog element’s current behavior should be maintained. This allows users to tab from the dialog to browser functionalities.
A significant benefit identified is that keyboard users can, for instance, open a new tab to research information or modify browser settings. Concurrently, the dialog element offers an additional natural escape mechanism (such as moving to the address bar) in scenarios like kiosk environments where other standard keyboard shortcuts might be unavailable.
Based on these insights, it appears that focus trapping is not a concern when the Dialog API’s showModal method is implemented correctly.
This clarification should simplify the process of building components.
