Dialog composability and accessibility

[soykje]

From last customers feedbacks, we noticed two topics that we may interested in discussing:

Styling issues when composing a Dialog

When composing a Dialog with or without Dialog.Header or Dialog.Footer some styles are not correctly managed: rounded corners, ...

Focus behaviour when having a Dialog with no interactive content

In this specific case we get focused (with focus styles) on close button, and this might be questionned: do we focus any content when displaying a random web page? 🤔 According to several feedbacks on this behaviour we may want to rediscuss it.

Here it would be about having an agreement on:

1. Keeping focus (with focus styles) by default as is (which means on close button or dialog content)
2. Allowing a pattern where no visible focus would be shown but the user could start keyboard navigation with the Dialog as a starting point (not the beginning of the document).
3. Integrating this pattern in our component default behaviour

Here you'll see an example of a possible workaround, that we may want to document or to forbid 😅 We use here the Radix onOpenAutoFocus prop to force focus on hidden element, to ensure user will start keyboard navigation in the dialog.

[acd02]

Styling issues when composing a Dialog

Stackblitz

👆 This is a StackBlitz demonstrating the styling issues one can encounter when not using the Dialog.Header or Dialog.Footer components.

You will notice that there are missing paddings, and it's up to the consumers to add those missing styles themselves.
Perhaps we could improve this aspect.

[Powerplex]

Keeping focus (with focus styles) by default as is (which means on close button or dialog content) => Already can be done using onOpenAutoFocus

Allowing a pattern where no visible focus would be shown but the user could start keyboard navigation with the Dialog as a starting point (not the beginning of the document). => Simply use onOpenAutoFocus to do event.preventDefault and the focus trap will start in the dialog.