[Bug]: Consistency of dialog content narration

[kolaps33]

Component

Dialog

Package version

9.61.5

React version

18.3.1

Environment

System:
    OS: Windows 11 10.0.22631
    CPU: (22) x64 Intel(R) Core(TM) Ultra 7 165H
    Memory: 29.94 GB / 63.64 GB
  Browsers:
    Edge: Chromium (135.0.3179.66)
    Internet Explorer: 11.0.22621.3527

Current Behavior

JAWS narrates dialog content.
NVDA doesn't narrate dialog content.

Expected Behavior

Would be great if NVDA and JAWS has consistent behavior.
We could reach this by adding aria-describedby into dialog content. Then both JAWS and NVDA narrated dialog content.

So even without using aria-descibedby JAWS narrates dialog content. So it looks like they consider is important to narrate when dialog is opened. Therefore make it for Fluent dialog by default makes sense.

Reproduction

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

Steps to reproduce

1. Go to ecnlosed stackblitz example
2. Navigate to button "open dialog"
3. Press Enter key
   Observe JAWS, NVDA narration.

Are you reporting an Accessibility issue?

None

Suggested severity

Urgent - No workaround and Products/sites are affected

Products/sites affected

No response

Are you willing to submit a PR to fix?

yes

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.

[bsunderhus]

This would require DialogSurface to be aware of DialogContent id...

In a properly declared Dialog, DialogSurface is a parent of DialogContent... at the moment we don't have a proper mechanism to ensure there's id sharing between components. We can have a default id being declared on the parent level, but once user provides a custom id to DialogContent then DialogSurface would lose this information...

Here's a feature request on this functionality to ensure id's would be properly shared between compound components: #24163

[smhigley]

Consistency of experience between different screen readers is not a goal we should have -- rather we want to achieve internal consistency within any given screen reader (i.e. our content should behave like any other content when using a given screen reader). A more familiar example might be that apps on an iPhone should behave like iOS apps, and apps on Windows should behave like Windows apps. This is backed up by years of asking many different screen reader users their preferences, and running user studies.

We should not be trying to wrangle Dialog to make it behave like JAWS' default when using NVDA. Our Dialog should behave in the way the user expects a standard dialog to behave when using their own personal tech stack.

(that said @bsunderhus' id-sharing proposal looks really useful, and is still relevant to teams that need to do this for short confirmation-like dialogs)