NVDA browse mode doesn't support aria-modal attribute

[khsbory]

Hello, all. I’m Hyongsop Kim in Korea and NVDA user. I want to report and suggestion about supporting aria-modal attribute. I’m using NVDA alpha snapshot latest version with Firefox and Chrome. As you know, once modal dialog will be applied, in old days, aria-hidden attribute is used to hide contents except dialog contents from assistive technology. But after ARIA 1.1 is published, aria-modal true or false attribute is added in ARIA spec, and if assistive technology support this, developers can work accessibility issues more easily, because if the dialog contents is not siblings of other contents, many code including infinite loop is required to use aria-hidden attribute. But now NVDA doesn’t support aria-odal attribute yet. Of course I know that NVDA supports role=”dialog” and if role=”dialog” is applied in modal window, browse mode hides all none dialog contents. But in some cases, I think just using aria-modal attribute is also needed. So please check this issue whether the attribute can be supported in NVDA.

Thank you.

[Adriani90]

cc: @MarcoZehe

[khsbory]

Role dialog and role alertdialog only is none modal. Because default aria-modal attribute is false. So NVDA browse mode should block none dialog contents only if aria-modal is set to true.

[brunoprietog]

Any news on this? It is very difficult to build modal dialogs that catch the focus correctly in all situations, especially when elements that belong to a dialog are eliminated. When that happens NVDA blurs the dialog.

[XLTechie]

Any update on this? Any code examples or test cases?

[Adriani90]

cc: @SaschaCowley

[JaiRai0304]

I think this is fixed. I tested the modal dialog in the link below with NVDA . With aria-modal="true" , I am not able to browse outside the modal dialog. https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/examples/dialog/

So this issue can be considered as closed.

[seanbudd]

Thanks for reporting back

[SaschaCowley]

I am easily able to access the content behind the dialog with NVDA alpha-33623,37b40464 (2025.1.0.33623). Reopening.

[SaschaCowley]

Any news on this? It is very difficult to build modal dialogs that catch the focus correctly in all situations, especially when elements that belong to a dialog are eliminated. When that happens NVDA blurs the dialog.

Supporting aria-modal will not fix this issue. Per the ARIA 1.3 spec:

When a modal element is displayed, assistive technologies SHOULD navigate to the element unless focus has explicitly been set elsewhere. Some assistive technologies limit navigation to the modal element's contents. If focus moves to an element outside the modal element, assistive technologies SHOULD NOT limit navigation to the modal element.

When a modal element is displayed, authors MUST ensure the interface can be controlled using only descendants of the modal element. In other words, if a modal dialog has a close button, the button should be a descendant of the dialog. When a modal element is displayed, authors SHOULD mark all other contents as inert (such as "inert subtrees" in HTML) if the ability to do so exists in the host language.

So it is still the responsibility of authors to appropriately trap focus. Remember that not all keyboard users are AT users, and ARIA is spackle, not rebar

[brunoprietog]

Still, NVDA should respect the aria-modal attribute. Voiceover on iOS, for example, hides all elements automatically so that you don't swipe them while interacting with the dialog.

Even, NVDA has another big problem being inside an element with dialog role. If you remove an element that is inside the dialog element and the focus was on that element, the focus of the browser goes to document.body and NVDA goes outside the dialog element container. This also does not happen with other screen readers.