Chromium and WebKit have shipped inert such that it removes inert subtrees from the accessibility tree (similar to aria-hidden). While there are still some concerns that need to be resolved in the spec, there is rough agreement that this is the correct path forward, assuming appropriate usage of inert. This support needs to be implemented in Gecko before we can ship inert to release.

I haven't dug into this deeply, but I think the best way for us to deal with this is to listen to NS_EVENT_STATE_MOZINERT and NS_EVENT_STATE_TOPMOST_MODAL_DIALOG changes in DocAccessible::ContentStateChanged. MOZINERT is added to inert subtrees. For <dialog>, the root element (not the body!) gets MOZINERT, but that would propagate to the dialog, so the dialog gets TOPMOST_MODAL_DIALOG to override this. That's going to be tricky to handle; we can't just remove MOZINERT subtrees, since that could remove a TOPMOST_MODAL_DIALOG subtree.

Perhaps the simplest way to deal with this is to somehow not render TOPMOST_MODAL_DIALOG subtrees at all until MOZINERT subtrees have been removed. Or we might be able to make use of PruneOrInsertSubtree, but there's a risk of rendering the dialog twice if we render the dialog, then PruneOrInsertSubtree runs and removes the MOZINERT subtree then reinserts the dialog.

This seems rather similar to how visibility: hidden works.

Needs tests but this should do.

I don't think I'll have the time to write the tests. If someone from the a11y or dom teams could pick it up it'd be great, otherwise lmk and I might be able to get to it in the future...

Thanks! Treating this like visibility: hidden is an interesting idea and it makes sense. However, it also means inert will suffer from the same problems as visibility does now. Specifically, an ancestor becoming "invisible" for accessibility will cause re-creation of the entire subtree; see bug 1638713.

I guess we could fix it this way now (which would unblock shipping and would be no worse than CSS visibility) and then come up with a solution for both problems in future. Presumably, whatever solution we come up with for visibility should also apply to inert, since they seem pretty similar as far as RestyleManager post traversal is concerned.

Can you give me a sense of which elements will get processed in ProcessPostTraversal? I'm guessing it won't always be the whole subtree below a change.

(In reply to James Teh [:Jamie] from comment #5)

Can you give me a sense of which elements will get processed in ProcessPostTraversal? I'm guessing it won't always be the whole subtree below a change.

Pretty much all elements whose style has changed. Of course we only send notifications if the visibility / inertness changes tho.

<div id="d1" style="visibility: visible;">d1
  <div id="d2" style="visibility: visible;">d2
    <div style="visibility: visible;">d3</div>
  </div>
</div>

If we do:
d1.style.visibility = "hidden";

Strictly speaking, only d1's style has changed. However, we must traverse d2 (even though its style hasn't changed) because otherwise, we wouldn't add it back into the a11y tree. But do we traverse d3? (I realise we don't send a notification for it because of the skip flag, but I'm curious as to whether the function gets a chance to look at it at all.)

https://hg.mozilla.org/mozilla-central/rev/250efc6230c9
https://hg.mozilla.org/mozilla-central/rev/c5790658fe68