Accessibility of detail modal

I have implemented one of the two suggestions.

Asserting focus in exiting modal test can be helpful here.

adding a tabindex to non-interactive is not adviced (see for example https://www.a11yproject.com/posts/how-to-use-the-tabindex-attribute/). https://html.spec.whatwg.org/dev/interactive-elements.html#the-dialog-el... suggests

As such, authors should use the autofocus attribute on the descendant element of the dialog that the user is expected to immediately interact with after the dialog opens. If there is no such element, then authors should use the autofocus attribute on the dialog element itself.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog suggests:

The autofocus attribute should be added to the element the user is expected to interact with immediately upon opening a modal dialog. If no other element involves more immediate interaction, it is recommended to add autofocus to the close button inside the dialog, or the dialog itself if the user is expected to click/activate it to dismiss.

i would rather lean toward the smallest commone denominator between the two aka focus on the dialog element itself instead of focusing on the close button cuz the intend of the dialog modal is that some browsing of the content and interaction with the elements in the modal happens. but i guess it would make sense to also start thinking and opening a follow up issue about the general structure of the dialog modal content (implementing the things we'Ve learned from the survey and which got aggregated into the quality indicators.png)

Not sure whether there is a better way of doing this but now the focus is on the modal element.Marking it NR.

Tested manually and focus is now set on modal. Moving it to RTBC.

thanks for the changes... the dialog modal getting the initial focus looks good... but i've noticed several more problems in the context of the a11y within the dialog modal. so far i have only tested it with modules that havent had an image carousel, plus i havent taken a closer look with voiceover active neither (see and hear dialog.mp4 and voiceover.mp4).

• with the dialog modal being the first element in focus it feels sort of odd to have the close button as the second in the tabindex? would it be possible and be better if the close button would become the last in the tabindex in the dialog modal?
• the back and forth buttons of the image carousel in the dialog modal are missing a visible focus outline (SC2.4.7).
• The labels for the next button with "slide right" is not clear (why not use something like "next image" and "previous image") in particular due to the fact that all the images in the carousel are labeled as decorational. with only two images you only have a single button cuz the other is disabled. with more than two images you then have a slide left and slide right buttons but no content you the user are sliding inbetween.
• the disabled button is not reflected in the aural interface and that way things might become confusing for screenreader users. using aria-disabled="true" instead of disabled would make the disabled button tabable and labeled as dimmed/disabled in for example voicover
• the tab order is odd. as demonstrated in voiceover.mp4, if the focus is on the slide right button, you press return and the button turns disabled and you press shift-tab to get back to the slide left button you get to the learn more button instead?!
• in dialog.mp4 and voiceover.mp4 i manage each time to get with the focus outside the dialog modal into the background of the modal which should not happen.

i set the issue back to needs work. the other option might be to move some of those points to follow up issues to keep the scope for this issue, but due to the fact that this issue is about the a11y of the dialog modal i set it back to needs work for now

Actually, each of these bullets should be its own sub-issue. If you want to collect all modal-related a11y issues, you can do a meta and do each bullet as a child; but, we need to keep scope as SMALL as possible for issues. Moving this one back to RTBC.

There will be more a11y fixes coming, but I aim to try to keep them as small and narrowly scoped as possible.

Automatically closed - issue fixed for 2 weeks with no activity.