Generated by 🚫 dangerJS against 6609918

I'm doing a deep dive into the logic. I'm migrating the Modal from the classes API to hooks. Once it's done. I will come back to this pull request :).

@oliviertassinari Thanks for keeping me posted.

@mackersD You can follow #16254. In theory, we could work in the two in parallel as they touch different files. But I would be interested in finding ways to make the logic correct as well as bundle size efficient.

I'm looking at the web accessibility guidelines, it seems that the aria-hidden approach we are using is considered "legacy": https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/dialog.html. They encourage the aria-modal="true" instead.
However, from the UI components, I can benchmark, it seems that there is no consensus on what's the correct approach is.

@eps1lon Do you have a preference?

Sounds expected. WAI-ARIA considers it legacy and most of the libraries haven't caught up.

On the other hand I only have access to chrome vox which isn't considered a good screen reader as far as I remember. It will still read content from stacked modals and the body in the WAI-ARIA practices. I don't get this behavior for our SimpleModal demo.

But this is only for chrome vox. We should verify that other screen readers work recognize aria-modal as well and make the rest of the page inert. aria-modal would be convenient but if it's not supported by many screenreaders we should stick to the aria-hidden workaround.

@eps1lon Thanks for the input. I'm in favor of keeping the current aria-hidden logic waiting for aria-modal to be better supported: https://developer.paciellogroup.com/blog/2018/06/the-current-state-of-modal-dialog-accessibility/.

I have refactored the ModalManager code, hopefully, it's simpler.

@mackersD It's a great first pull request on Material-UI 👌🏻. Thank you for working on it!

😁 thanks!