A11y: Keep focus in modal

I added a "focus trap" to the klaro dialog using some javascript that will add two functional tabbable elements at first and last position, if you focus them, the focus will be set accordingly to the actual first or last tabbable element. This way your focus is trapped within the dialog.
Please review

thank you! i've tested MR100 on macOS Sequoia. the tabbing problem looks like solved now. but in addition to that i've also tested the stepper in voiceover (ctrl-option arrow left and right) within the dialog modal, but i am not entirely sure what the expected behavior should be. should it be as shown in safari.mp4 (better mute your audio cuz i am skipping through the interface fast which can be very distracting) so that it stops at the last and first element in the AOM or should it behave like with tabbing and jump from the last element to the first (tab) and from the first to the last (shift tab)? i am gonna do some more research (we have the a11y office hour in about an hour, gonna ask others there, and i am gonna ask over in the a11y slack if necessary as well - made me curious).
and there is another detail i've noticed, when testing the same in edge the voiceover stepper gets trapped within the privacy policy link (edge.mp4). as soon as the voiceover cursor is on the privacy link i cant step forward but also am unable to step backward, i am trapped within the link. and finally i've tested the same setup with firefox. at first i've thought it is behaving like safari, first with the tabbing and then with the voiceover stepper. but well, watch the video until the end, and you will notice the stepper is able when getting back to the close button to step past it outside the dialog modal and you then start stepping through the entire background of the dialog - you are actually leaving the AOM (firefox.mp4)

one addition, other dialog modals in core (tested admin/structure/types/manage/playground/fields) when testing in safari and edge behave the same way like the safari.mp4 example does. firefox is close but also shows some unique odd behavior. when you are back at the beginning of the dialog with VO arrow left you then jump between the close button and the title instead of sticking to the close button. i will research the expected behavior for the voiceover cursor still, but that quick test proofs that something more is off in klaro within the scope of this MR or klaro in general compared to the behavior of drupal core.

Thank you rkoller for testing this!

IMHO the best option would be to use the <dialog> element, but this would be something rather to be implemented within the klaro-js library. I´m going to go through your feedback and try to improve the behaviour. It´s just a quickshot solution so far i just tested in nvda and firefox, so this feedback is very very helpful.

Unfortunatly i dont have a macOS at the moment to test voiceover.
But i made a little changes to make it more like the drupal core modals, so that you tab from first to last and from last to first.
I also made some little changes how the "functional tab handles" are displayed and also added a text-content, hoping this might fix something for voiceover....

For me the behaviour using tab navigation is now the same in firefox/chrome/edge , also using nvda.

we have discussed the issue in yesterdays a11y office hour. The other attendees, @katannshaw and @the_g_bomb, were also uncertain what the expected behavior would be with voiceover activated in regard to the start and end of dialog modals. I have asking over in a11y slack still on my to do list - hope i will get to it over the weekend. but i've remembered https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/ and there safari with voiceover behaved the same like in safari.mp4.

i've pulled the latest changes for MR100 (see safari_latest.mp4). you managed somehow that tab and VO-arrow left and right behave the same in regard to reaching the end or the start of the dialog modal! wow! firefox behaves the same now like safari. the only thing, in edge i still have a "VO arrow trap" on the privacy policy link.

I like the consistency inbetween tab and VO arrow but it would be still good to find out what the expected behavior would be for actual screenreader users.

p.s. i completely agree that going with the dialog element would be the cleanest approach, but yep that should ideally happen upstream.

Thanks rkoller for your feedback and engagement.
I´m sure we can adjust the behaviour as expected once we know what this would be :)
I´m happy it works consistently now... the bug with edge macos and VO i realy cant explain and it doesnt realy make sense.
But also i guess people using this combination is only a few. I mean the total usuage share for edge is below 5% including microsoft users, i dont even find data about macOs users with edge, so i would be fine living with that. Does this bug only occur in this MR100 ?

that was a good idea! completely overlooked that possibility, i've tested now on 3.x-dev and i ran into the same issue. so the problem is out of the scope of this issue. probably a bug with voiceover and edge?