With an open dialog modal also elements in the background are added to the accessibility object model

Problem/Motivation

The background for dialog modals isn't hidden and excluded from the accessibility object model (AOM). That has several implications. If a screenreader user is opening the rotor while a modal is open the list of available elements contains all elements from within the modal plus all the elements from it's background. It is impossible to distinguish with a screenreader which element belongs to the background and which to the modal:

see modal_false.mp4

If a user accesses the List additional actions button on the Content (Content) view for example and then steps through the interface with VO-right arrow as demonstrated in the video the voiceover cursor keeps stepping through the elements in the background. The screenreader user is potentially unaware of that fact.

see focus_arrow.mp4

If the user then accesses the List additional actions button again via the rotor and instead of using VO-right arrow uses just the tab key then the focus transitions back into modal. But the fact that one was first in the background of the modal and then transitions back into the modal goes unnoticed as well.

see focus_tabbed.mp4

Based on my research there are currently mainly two options, either to use the aria-modal attribute alongside the already used role="dialog" or the use of aria-hidden in the combination with inert. I've quickly added the former (aria-modal) within devtools and it improves the situation significantly:

see modal_true.mp4

the ARIA Authoring Practices Guide (APG) also utilizes and recommends the use of the aria-modal="true" attribute (https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/examples/dialog/). I've brought up the topic at the monthly a11y office hour today (10-19-2024). For the record, the attendees at the accessibility meeting were @alejandrosrez, @itmaybejj, Jackie Van Vliet, Laura Flannery, @mgifford @rainbreaw, @rkoller, @shaal, and @simohell.
In regards of the two options the consensus was aria-hidden might be currently the more stable option but aria-modal is en par (two or three years ago that was different) and as demonstrated in the video is also working more or less out of the box with minimal effort. In addition it is also the more future proof choice since the support in browser for aria-modal is only getting better than worse while aria-hidden might be degrading over time. It was also noted that the modal should function like a focus trap and scenarios like in focus_arrow.mp4 and focus_arrow.mp4 should be avoided and not be possible in the first place. So adding the aria-modal attribute would be a quick and easy short term fix for this issue.

But dialog.js is part of the jQuery UI and that is getting deprecated. The corresponding issue for that is: #2158943: Add a native dialog element to deprecate the jQuery UI dialog. The groups consensus was the ideal long term goal for dialogs in Drupal, which should be implemented in the linked issue, should be using the native dialog element (https://caniuse.com/dialog - 94,25%) in combination with the aria-modal attribute (https://caniuse.com/?search=aria-modal) and the edge cases should be handled with some extra javascript. That javascript could be reduced in the future as the browser support improves further.

Update: The longterm goal is being covered and worked on in https://www.drupal.org/project/dialog_native now, therefore this issue could be rescoped to the short term fix only.

Steps to reproduce

• activate the screenreader
• Go to /admin/structure/views/view/content
• Go into Content: Title (Title) in the fields section
• Open the rotor in case you are in voiceover

Proposed resolution

Add aria-modal="true" to the div of the dialog modal created by jQueryUI that has the role="dialog" attribute.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet