When a Dialog opens, the role="dialog" element automatically gains focus, and so has an outline, eg:
In practice, it's probably best for consumers to programmatically give focus to an interactive element within the Dialog when it opens. But we should consider revisiting the Dialog focus treatment for cases when that isn't done.
For a11y's sake, we should retain some indication of focus, but it can be opinionated.
Note: the Dialog focus can already be disabled by passing shouldFocusAfterRender={false} to the <Dialog>, but this leaves the focus on the button that triggered the dialog, which is outside the dialog boundaries and so creates havoc when attempting to navigate the open dialog by keyboard.
When a Dialog opens, the
role="dialog"element automatically gains focus, and so has an outline, eg:In practice, it's probably best for consumers to programmatically give focus to an interactive element within the Dialog when it opens. But we should consider revisiting the Dialog focus treatment for cases when that isn't done.
For a11y's sake, we should retain some indication of focus, but it can be opinionated.
Note: the Dialog focus can already be disabled by passing
shouldFocusAfterRender={false}to the<Dialog>, but this leaves the focus on the button that triggered the dialog, which is outside the dialog boundaries and so creates havoc when attempting to navigate the open dialog by keyboard.