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:
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.
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.
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:
📌
Add a native dialog element to deprecate the jQuery UI dialog
Needs work
. 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.
/admin/structure/views/view/contentContent: Title (Title) in the fields section Add aria-modal="true" to the div of the dialog modal created by jQueryUI that has the role="dialog" attribute.
Active
11.0 🔥
It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.
I've rescoped the issue just being about adding aria-modal="true" to the dialog modal since the long term goal is being worked on in
https://www.drupal.org/project/dialog_native →
now. I've updated the issue summary accordingly.
And i've created an issue upstream now: https://github.com/jquery/jquery-ui/issues/2246