How to interact with elements outside a modal?

[thedatadev]

Hey all,

With the recent update in @react-aria/overlays which adds the inert attribute to anything outside an active modal, I've found that things like toasts or chatbot widgets (e.g. Intercom) have lost interactivity while the modal is open. What's the recommended approach in making sure elements like these stay interactive? I see that there is a data-react-aria-top-layer attribute that gets used internally.

For context, I have a fullscreen modal (similar to the "fullscreenTakeover" variant seen in DialogTrigger) where I want to support certain features e.g.

• if a user uploads a file which turns out to be corrupted, display an error toast
• allow a user to interact with an Intercom chatbot widget for customer support

Thanks in advance!

[snowystinger]

Yes, you should make use of data-react-aria-top-layer for those components. 👍🏻

[Hanskrogh]

AriaKit's "solution" feels like a nicer trade-off over my earlier inertScope idea. But as you're saying I am not either sure to know whether this is always the right thing to do.

Right now, I’ve worked around it with a custom hook that strips inert from 1Password’s injected elements after the dialog mounts. The downside is that I’d have to maintain a list of every extension selector - an impossible task given how many browser extensions exist. In our case, it’s especially tricky because we’re building a form with autocomplete, and password managers like 1Password inject dropdown UIs that must remain interactive.

[thedatadev]

Thanks all for the input. There certainly doesn't seem to be a straightforward, clean solution to this.

Was there any reason in particular why this change was released ahead of jsdom supporting the "inert" attribute?

It also appears integration/e2e testing libraries like playwright and testing-library/cypress have yet to support this either:

• playwright: [Bug]: Elements with an inert="" attribute aren't hidden from the accessibility tree microsoft/playwright#36938
• testing-library/cypress: Elements with an inert="" attribute aren't being hidden from the accessibility tree testing-library/dom-testing-library#1364

Happy to open a Github issue and continue the discussion there as I feel some people might see this as an issue.

[snowystinger]

jsdom also doesn't support PointerEvents... which has been in browsers for 5 years. I don't know why we'd hold up support for important features based on jsdom. inert has been supported in every major browser for over 3 years. https://caniuse.com/?search=inert

Didn't know about playwright or cypress support. Cypress doesn't seem like bad behaviour though. It's not hidden, it's more... removed? So I think only playwright has an issue.

For instance, you could target an aria-hidden button that is meant for non-screen reader users. But inert really shouldn't be available to anyone for anything. Why do you need to find it with those tools?

[thedatadev]

For instance, you could target an aria-hidden button that is meant for non-screen reader users. But inert really shouldn't be available to anyone for anything. Why do you need to find it with those tools?

Targeting screen reader-specific controls is a valid point 👍

One main use case is to assert, that when a modal dialog appears, that no content under it can be interacted with. So, for example:

1. Click a modal trigger
2. Check that the modal dialog is visible
3. Check that no underlying content is accessible, e.g. by targeting a heading that was on the page, or a form submit button
4. ... proceed to make assertions for elements within the modal dialog

[snowystinger]

I think if you cannot target something, it's relatively safe to assume you cannot interact with it. If you really need to get past all of the tools and get an element regardless of it being hidden or inert, you can always go through dom apis like document.querySelector

If you want to make sure everything has inert applied, just target your element which should still be not inert (the dialog), then assert all its siblings and parents siblings are inert. Seems more accurate then just looking for specific elements on the page behind the dialog and trying to interact with them, that could be so many elements.