aria-hidden warning on closing mui dialogue

I'm using Material-UI (MUI) v6 to create a dialog that opens when a user clicks a button. I'm facing accessibility warning that only occurs on closing the dialog for the first time after render/mount. The warning doesn't appear on subsequent opens and closes of the dialog.

It happens on a component with a button which triggers dialog open.
I haven't explicitly used the aria-hidden attribute anywhere in my code, so I assume it's coming from MUI's internal implementation.

Here's the warning I'm seeing in the console:

Blocked aria-hidden on a <div> element because the element that just received focus must not be hidden from assistive technology users.
Avoid using aria-hidden on a focused element or its ancestor.
Consider using the inert attribute instead, which will also prevent focus. For more details, see the aria-hidden section of the WAI-ARIA specification at https://w3c.github.io/aria/#aria-hidden.

Link to live example:

stackblitz : https://stackblitz.com/run?file=Demo.js
codesandbox : https://codesandbox.io/embed/m69y7p?module=/src/Demo.js
mui doc: https://mui.com/material-ui/react-dialog (open console on official doc then open and close dialog)

Sample code:


const Sample = () => {
  const [openDialog, setOpenDialog] = React.useState(false);

  const handleClose = () => setOpenDialog(false);
  const handleOpeng = () => setOpenDialog(true);

  ...
  return (
    <>
      <Button onClick={handleOpen}
      <Dialog open={openDialog} onClose={handleClose}>
        {/* Dialog content */}
      </Dialog>
    </>
  );
};

Questions:

Why is this warning occurring only on the first render?
How can I resolve this accessibility issue while maintaining the functionality of my dialog?
Are there any best practices for handling focus management with MUI dialogs that I should be aware of?

Any insights or solutions would be greatly appreciated!

npx @mui/envinfo

  System:
    OS: Windows 11 10.0.22631
  npmPackages:
    @emotion/react: ^11.13.3 => 11.13.3
    @emotion/styled: ^11.13.0 => 11.13.0
    @mui/base:  5.0.0-beta.58
    @mui/core-downloads-tracker:  6.0.2
    @mui/icons-material: ^6.0.2 => 6.0.2
    @mui/lab: ^6.0.0-beta.9 => 6.0.0-beta.9
    @mui/material: ^6.0.2 => 6.0.2
    @mui/material-nextjs: ^6.0.2 => 6.0.2
    @mui/private-theming:  6.0.2
    @mui/styled-engine:  6.0.2
    @mui/system:  6.0.2
    @mui/types:  7.2.16
    @mui/utils:  6.0.2
    @mui/x-data-grid: ^7.15.0 => 7.15.0
    @mui/x-internals:  7.15.0
    @types/react:  18.3.3
    react: ^18.3.1 => 18.3.1
    react-dom: ^18.3.1 => 18.3.1
    typescript:  5.4.5
    next: 14.2.5

Solution

tl;dr

Use closeAfterTransition={false} https://mui.com/material-ui/api/modal/

I found very useful thread on this exact topic. Here's a short explanation of what's happening:

When you open a dialog via a button, the button's ancestor gets aria-hidden, presumably so that screen readers (SR) can't interact with it while the dialog is open.
When you close the dialog, the aria-hidden is removed so that SRs can interact with the button again.
Also, when closing, the focus is moved back on the opener button.

Now comes the important part. You get Blocked aria-hidden on a <div> only when 3 happens before 2. In this case, as the error message explains, we are trying to place focus somewhere where SRs don't have access, which is a No No and browser correctly warns about that.

This ordering is dependent on the closeAfterTransition prop on the MUI Dialog. When false and user triggers dialog close, aria-hidden is removed (2) and then focus is placed on the opener button (3). Meaning there is no issue. You can see it in action here. However, when it's true (the default), the order is the other way around and you get the warning.

To your questions:

Why is this warning occurring only on the first render? - Not sure. Probably it's the browser choosing not to spam you with the same error all the time.
How can I resolve this accessibility issue while maintaining the functionality of my dialog? - try closeAfterTransition={false}
Are there any best practices for handling focus management with MUI dialogs that I should be aware of? - Not in this case. It's MUI's responsibility to make such a simple case - closing a dialog - accessible.