Closed Bug 1767561 Opened 2 years ago Closed 1 year ago

Remove inert subtrees from the accessibility tree

Categories

(Core :: Disability Access APIs, enhancement)

enhancement

Tracking

()

RESOLVED FIXED
112 Branch
Tracking Status
firefox112 --- fixed

People

(Reporter: Jamie, Assigned: Jamie)

References

Details

Attachments

(2 files)

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.

Assignee: nobody → emilio
Status: NEW → ASSIGNED

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...

Assignee: emilio → nobody
Status: ASSIGNED → NEW

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.)

Assignee: nobody → jteh
Status: NEW → ASSIGNED
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/250efc6230c9
Deal with inert much like we deal with visibility: hidden. r=Jamie
Pushed by jteh@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c5790658fe68
part 2: Add a11y tests for inert, dialog and fullscreen. r=emilio,morgan
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 112 Branch
Regressions: 1818720
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: