Dialog Tabbing over buttons should stay within the dialog

[aedu-hostettler]

Could you prioritise this feature request, so it could get installed with a production release? (we are in mid of integration release cycles currently)

Is your feature request related to a problem? Please describe it.
When a dialog is opened (when there are 2 buttons and the closing x), its not visible, that the focus is on the first (primary, most right) button. When i use the tab keyboard button, the second is focused, then the closing x and then i have to toggle through alot of browser controls, until i get back to the primary button within the dialog.

Describe the solution you'd like
It would be nice, if the initial focus on the primary button would be visible, and after reaching the closing-x button, that the next tabulator hit would not leave the dialog itself, and the primary button would be focused again. (so one can toggle through the buttons within the dialog with tabulator keyboard.)

So desired focus order -> on dialog load -> right primary button (is already focused, but not visible (blue-border)), then closing-x on top (if displayed, because there are some cases, where we want to force the user to select from below displayed buttons), and then from left to right the displayed normal buttons on bottom. This focus-cycle should be repeatable unlimited times, without going out of the dialog to browser-controls - and with Shift-Tab the same order in cycle in reverse

Maybe you can use an approach like this, but instead of focusing on an input element, use the first or last button within the dialog, dependent on what was the last one focused, or if tab or shift-tab was used (the event does not contain, by which action the focus was lost)
https://css-tricks.com/a-css-approach-to-trap-focus-inside-of-an-element/
or maybe better something like this
https://www.w3.org/TR/2017/NOTE-wai-aria-practices-1.1-20171214/examples/dialog-modal/js/dialog.js

Describe alternatives you've considered
We would have to implement a custom tabbing order for each dialog, and somehow make sure, the focus does not leave the dialog itself.

As an additional topic: is the flex-flow-reverse the final solution to the alignment of buttons? Its a bit counter intuitive to place the buttons in a html-order, and then it is displayed in reverse. Also maybe for users it could be counter intuitive, that the tabbing-order is in reverse (right to left, and then the closing-x on top)? - But on the other hand, if you would remove the reverse-flow, and use a float-end or text-end css class, all the existing button orders, would have to be manually changed. What do you think about that? (Its also a thought for the Process-Navigation-Button-Component in v9 of design-system. (the dividerline, where below the buttons would be for navigating back (on the left/start, and forth (right/end) within a multistep/page process)