[meta] Address accessibility concerns

It's notable that the standard Drupal preview as a "Skip to main" link. That makes me think that an attempt to address accessibility concerns has been made to Core's preview system. We should review what's included and understand the gap between what's there and what's needed.

Depending on where we land with the intended layout, we might have to consider RTL/LTR language layout for the preview form controls.

For reference i'll add the points i've wrote up in the corresponding thread on the drupal slack in the #preview channel:

The first video (tab.mp4) illustrates two potential issues mentioned in the thread. First if the user clicks the toggle preview button there is no indication that a preview got opened. if it is a modal or a new browser window or in what form the preview surfaced. the focus remains on the toggle preview button. if you tab as a screen or you sequentially tab with VO-tab after the clicked the toggle preview button unaware that the preview is open you continue on the node edit form. that way the idea suggested in #2 ✨ [meta] Address accessibility concerns Active for adding a visually hidden skip to preview link that gets visible in focus like the skip to main content link might be a viable idea. aside that if you continue to tab and get into the scope of the preview window, as soon as you tabbed in you are "trapped" inside a loop of the four only focusable element within the preview. luckily one of them is the quit option but still it feels suboptimal. but i am not sure if it would be an requirement that the user should only tab through it once?

the second video (rotor.mp4 illustrates the interaction with the aural interface via the rotor (VO-u) in macos with voiceover. i go there through the different sections and that surfaces a potential source of confusion for screen reader users. as i step through the landmarks regions i get several regions with identical names (voiceover is highlighting the region in question with a black outline in the browser window). that way you have main , banner, breadcrumb navigation twice in the list. and due to the fact that the landmark role title doesnt provide any context for each of those twins it is hard to tell for the user without any other input aside the announcement which is which (based on the order but that would be the only clue and only viable for users familiar with the page, new users are more or less lost).
the form controls section doesnt have that many duplicated controls but still each of the entries lacks any context. to know each formcontrols exact purpose and where it is located, node edit form or preview is difficult to tell.
for headings the same. due to the fact that the preview doesnt have an h1 me as a user might consider main nav and breadcrumb may be being part of the node edit form? the button, links and the rest of the sections a similar situation. the only exception is the frame section with drupal frame. the only problem i see there is the naming. a more expressive name might be chosen. something like "article preview window" or might it be possible to even dynamically insert the chosen title of the node? would that make sense? but aside that i would consider to add a landmark region to the iframe as well. most screen reader users orient by headline or landmark in particular when they get to a page or site they are unfamiliar with ( https://heydonworks.com/article/responses-to-the-screen-reader-strategy-... first question and response) and i am uncertain how many screen reader users rely on the frames section to navigate. that way it might be a good thing to provide another option to orient and navigate with a landmark region.

the last detail might be in regards of the windows high contrast mode.

the decortional icon in the upper left of the preview window is hidden. and the close button might be a bit difficult to spit because it is that grey. aside that everything looks correct on a first look.

one other detail to note. the iframe currently doesn't have a title. it is just labeled with frame in the voiceover rotor.

wcag sc 4.1.2 https://www.w3.org/WAI/WCAG21/quickref/?showtechniques=412#name-role-value
technique h64:
https://www.w3.org/WAI/WCAG21/Techniques/html/H64.html

as discussed with @cosmicdreams on slack i'll rename the issue to a meta issue and start to created dedicated child issues for the problems listed in here.