aria-hidden incorrectly set with Dialog container changes

[angrycat9000]

Steps to reproduce

Steps:

1. Open this link to live example: https://codesandbox.io/p/devbox/patient-frost-x4rgvs?from-embed=&workspaceId=ws_Q9rT7Lz72nradL4qgt4vA4
2. Note that div#root has aria-hidden set. This is hiding all React content including the modal
3. If you close and reopen the dialog. aria-hidden is not set.

Current behavior

The dialog is hidden for accessibility testing because its ancestor, div#root, is marked as aria-hidden.

This was set by the ModalManager on the first render because div#root was a sibling of the dialog on the first render.

On the second render the container ref changes and the dialog is now inside of div#root which is still marked as aria-hidden

Expected behavior

When the container for a modal is changed, the ModalManager should re-evaluate which elements should be aria-hidden. It should remove the aria-hidden from div#root when it is no longer a sibiling of the modal.

The state should be the same as if the dialog container was always set to be inside div#root in the same render it was set to be opened.

Context

This bug occurred in automated testing. The test is attempting to use getByRole('dialog') to locate the dialog. However because the aria-hidden is incorrectly set, on the render root, it considers everything inaccessible and it fails to locate the dialog.

Similar to but not identical:

• [joy-ui][Modal] Select Option is not accessible when placed in a Modal or Drawer because aria-hidden is set #41998
• [Modal] aria-hidden should not be applied on non-portal modals #19450
• [Dialog] Accessibility issue when testing dialog with transitions disabled #31171

Your environment

npx @mui/envinfo

Tested this in Chrome 150.0.7871.187 on Windows

  System:
    OS: Linux 6.18 Ubuntu 24.04.4 LTS 24.04.4 LTS (Noble Numbat)
  Binaries:
    Node: 24.15.0 - /home/codespace/nvm/current/bin/node
    npm: 11.12.1 - /home/codespace/nvm/current/bin/npm
    pnpm: 10.30.1 - /home/codespace/nvm/current/bin/pnpm
  Browsers:
    Chrome: Not Found
    Firefox: Not Found
  npmPackages:
    typescript: catalog: => 6.0.3 

Search keywords: Dialog Modal aria-hidden container

[atharv-sys32]

I'd like to pick this up. On first render the ModalManager marks the modal's siblings as aria-hidden, and the target container is one of those siblings. When the container ref changes, the modal moves inside it but the manager never re-evaluates the aria-hidden state, so the element stays hidden and the dialog is inaccessible to assistive technologies. I'll add a regression test that moves the container after mount and verifies aria-hidden is cleared on the previously-hidden sibling.

[silviuaavram]

Hi! In your example, when opening the dialog, I don't see any aria-hidden on the root. It's on the sibling element.

[atharv-sys32]

Hi @silviuaavram, you're right. In the example the aria-hidden is on the sibling element, not on #root.

The bug needs a specific sequence: the dialog opens with the default container (document.body), so #root gets aria-hidden as its sibling. Then the container prop changes to a node inside #root while the dialog stays open. The dialog now renders inside #root, but the stale aria-hidden is never removed, so the dialog sits inside a hidden ancestor and is inaccessible to assistive technologies.

PR #48889 fixes exactly this. It re-registers the modal with the ModalManager when the resolved container changes while the dialog is open, and the regression test covers the flow (open on body, switch container to a node inside #root, assert the stale aria-hidden is cleared). All checks are green.

I can also make a minimal sandbox that reproduces the sequence if that would help.

[angrycat9000]

Hi! In your example, when opening the dialog

Thanks for pointing that out @silviuaavram. @atharv-sys32 is right it only happens in certain case. If you close and then re-open the dialog it shows up where expected. I updated the description to include this to avoid confusion.