Should non-modal top layer elements that come after modal dialogs also escape inertness?

[mfreed7]

What is the issue with the HTML Standard?

It has been brought up that a popover, opened "from" a modal dialog, becomes inert unless the popover is a flat tree descendent of the dialog. E.g.

<dialog id=d1>Dialog</dialog>
<div popover id=p1>Popover</div>
<script>
  d1.showModal();
  p2.showPopover();
</script>

In this example, the popover is rendered inert, which means that clicking on the popover light dismisses it, because the popover behaves as pointer-events:none and the click goes through it. Other examples might include a "toast" that shows up (via popover=manual) and has a Close button to dismiss it. That close button would not be click-able, even though the toast might obscure part of the modal dialog.

Here's a live example: https://jsbin.com/mugebod/1/edit?html,output

It might be possible (web-compat-wise) to change that behavior, so that other top layer elements such as popovers and non-modal dialogs which come after the blocking (topmost) modal dialog also escape inertness.

I believe it's still correct to have prior top layer elements (such as d1 in my linked example above) stay inerted, since they're "behind" the topmost modal dialog in the top layer stack.

Thoughts? @alice

---

See a related discussion in CSSWG about the new interactivity property, here:

https://github.com/w3c/csswg-drafts/pull/11178/files#r1845716939

Also see the current HTML spec for how modal dialogs escape inertness, here:

https://html.spec.whatwg.org/multipage/interaction.html#modal-dialogs-and-inert-subtrees

[mfreed7]

Other examples might include a "toast" that shows up (via popover=manual) and has a Close button to dismiss it. That close button would not be click-able, even though the toast might obscure part of the modal dialog.

Thanks to @argyleink, here's a demo of that use case (minus the part where it obscures the dialog): https://codepen.io/argyleink/pen/gbYpNLY/a533152314a2ce88bb6ae830f48e032b

[alice]

Oops, I meant to reply to this last week and it slipped my mind. Thank you so much for filing it!

I think you've captured it pretty well.

I think if I could wave a magic wand, I would make the dialog "blocking" behaviour instead a function of the top layer under certain circumstances. Then, everything above the "blocking" top layer would be excluded from the inerting behaviour, and everything below it would be included. That would remain consistent with the current behaviour of <dialog> and fullscreen elements, other than the undesirable behaviour described in this issue. It would also be consistent with the visual appearance of relevant top layer elements. Dialogs' blocking behaviour is visually indicated by positioning them such that they visually block other other content, often with a backdrop. Likewise for fullscreen elements, which obscure literally all other content other than higher top layers.

[alice]

@smhigley just reminded me that this might get a little interesting with accessibility API mapping, since in some screen readers a modal dialog doesn't let a screen reader user move their virtual cursor outside of it once they are in it, regardless of whatever else is going on with the accessibility tree. So we might need to take extra care with the mappings for those APIs, and move other top layer nodes inside the dialog in the accessibility tree to ensure that they can be accessed.

@jcsteh may have thoughts on how feasible this is; I'm less familiar with the APIs where this occurs. From a browser internals perspective I believe this should be manageable; it would be equivalent to using aria-owns to append those elements to the end of the dialog.

[alice]

Another approach to this problem, though probably not a workable one, might be to prevent elements outside the “blocking” top layer element from forming another non-blocking top layer on top of it. i.e., if your popover element is outside the dialog, it simply doesn’t get to be rendered on top of it.

This would probably be considered a breaking change from the perspective of sighted non screen reader users, since it would change the behaviour of popovers for those users. It would also require more re-tooling of pages converting from pre-popover code which placed to-be popover elements at the end of the document as a kind of top layer hack, as described by Scott’s original problem statement.

[scottaohara]

fwiw, i think this idea makes a lot of sense @alice. as you said, depending on how feasible it is

move other top layer nodes inside the dialog in the accessibility tree to ensure that they can be accessed.

and i think you're saying it would only be the top layer nodes that would appear "above" the modal dialog in the top layer stack - so if there was a manual popover that existed on the page prior to the modal dialog being invoked - that would become inert.

but from my experience working with product teams and their users, rarely has it worked out where if a user invokes a modal dialog, that they would be able to access or think to access content outside of the modal. in the cases where content was actually accessed outside of the modal, it was often thought that the modal just wasn't implemented properly.... it's supposed to be modal after all. So, moving any content which should be accessible into the dialog's a11y tree would both help with discoverability, and make it less likely people might think "this is just another poorly implemented modal dialog"

[alice]

Right, I misspoke a little originally: I meant that things in the top top layer should generally not be inert. A popover is always “in the top layer”, but if it’s below a blocking top layer like a dialog, then it’s not in the top top layer. You could certainly have multiple top layers of popover which should all be non-inert, too, so it’s more complex than just “which top layer is on top”, but as an intuition, I would expect the very top layer certainly shouldn’t be inert.

[mfreed7]

Another approach to this problem, though probably not a workable one, might be to prevent elements outside the “blocking” top layer element from forming another non-blocking top layer on top of it. i.e., if your popover element is outside the dialog, it simply doesn’t get to be rendered on top of it.

I'm afraid there will be use cases, though. E.g. a tooltip or select picker that is rendered "old school" as a popover at the end of the <body>. Yes, that can be done by moving the popover up into the DOM of the <dialog> but perhaps in some cases that can't be done. Or doesn't make sense - like if there's a single component that provides the "one tooltip" that can be attached to multiple things on the page. It might not want to be moved around in the DOM just to make it work.

I think if I could wave a magic wand, I would make the dialog "blocking" behaviour instead a function of the top layer under certain circumstances. Then, everything above the "blocking" top layer would be excluded from the inerting behaviour, and everything below it would be included.

I liked this phrasing, since that's roughly what I was going for. A modal dialog creates a new "block" in the top layer stack. Everything below that point in the top layer stack is inert. Everything after it escapes inertness. So a new, nested modal dialog creates a fresh "block" and inerts the prior top layer elements.

[scottaohara]

I misspoke a little originally

but i got what you were saying @alice, just needed to make absolutely sure :) thank you

and with @mfreed7's reply, seems we're on the same page. Just need to ideally also re-parent the a11 tree for those additional top layer elements into the highest modal block, to mitigate the "why is there content outside of my modal?" issue.