[Bug]: Dialog non-focusable text not announced by NVDA unless modalType="alert"

[marciat]

Component

Dialog

Package version

9.55.0

React version

18.2.0

Environment

System:
    OS: Linux 6.8 Ubuntu 22.04.5 LTS 22.04.5 LTS (Jammy Jellyfish)
    CPU: (16) x64 AMD EPYC 7763 64-Core Processor
    Memory: 54.79 GB / 62.79 GB
    Container: Yes
    Shell: 5.1.16 - /bin/bash

Current Behavior

When a Dialog component has some text that is not part of a focusable/interactable element, such as a description, and the modalType is not "alert", this text is not announced by NVDA. However it is announced by Windows Narrator.

Expected Behavior

Similar to what happens in Windows Narrator, it would be expected that when the dialog first opens, all the text in it will be read out by NVDA.

Reproduction

https://stackblitz.com/edit/h3ydjyr4?file=src%2Fexample.tsx

Steps to reproduce

1. Turn on NVDA.
2. Navigate to "Open Modal Dialog" and press it.
3. Observe that the description is not announced, only the link.
4. Press "Close" button to close the dialog
5. Navigate to "Open Alert Dialog" and press it.
6. Observe that both the description and link are announced.

Are you reporting an Accessibility issue?

yes

Suggested severity

Medium - Has workaround

Products/sites affected

No response

Are you willing to submit a PR to fix?

no

Validations

• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• The provided reproduction is a minimal reproducible example of the bug.

[smhigley]

Hi! Different screen readers have different behaviors when it comes to initially entering a new page or section of content; this isn't something that is in the purview of authors -- it is entirely up to screen reader developers and screen reader users (and their software settings).

An alert dialog that uses role=alertdialog is a very specific an unusual type of UI, and should be resevered for urgent, blocking errors. It should never be used in general as a substitution for dialogs to try to force someone's screen reader to behave differently from it was designed to behave.

For very small confirmation-style dialogs, you could add aria-describedby="contentId" to the DialogSurface, where contentId is the id of the element containing the Dialog's body text. That will, for some (but not all!) screen readers cause the body text to also get read out when it is opened. However, it is never the job of a UI author to try to force a screen reader to behave a certain way, any more than it's the job of a UI author to change the brightness setting or color temperature of a user's monitor to display colors the way they wer designed.