Request for Mozilla Position on an Emerging Web Specification

• Specification Title: CSS Display Level 3 (but specifically a question about focusability of display: contents)
• Specification or proposal URL (if available): https://drafts.csswg.org/css-display-3/#box-generation and the discussion in [css-display][css-aam][selectors-4] How elements with display:contents get focused? w3c/csswg-drafts#2632
• Explainer URL (if available): none
• Caniuse.com URL (optional): https://caniuse.com/css-display-contents (note particularly the footnotes that reference bugs on this topic!)
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=1553549 and https://bugzilla.mozilla.org/show_bug.cgi?id=1791648
• Mozillians who can provide input (optional): @emilio

Other information

The discussion in w3c/csswg-drafts#2632 concluded with the spec editors saying that existing specifications require that display:contents elements are focusable just as other elements are, and that no spec changes were needed. (However, this requires some amount of analysis to determine.)

This conclusion disagrees with behavior that is currently interoperable between browsers. However, I think this interoperable behavior is problematic (and the issue conclusion was correct) because elements with display:contents are exposed to assistive technology as having their normal roles, and the contract for the meaning of accessibility roles includes support for certain role-specific keyboard interactions which often include focusability. So I think it's important that the exposure to AT (as agreed in the CSSWG in w3c/csswg-drafts#2355) match the focusability, which it currently does not.

This issue is currently covered by:
https://bugzilla.mozilla.org/show_bug.cgi?id=1553549
https://bugzilla.mozilla.org/show_bug.cgi?id=1791648
https://bugs.chromium.org/p/chromium/issues/detail?id=1366037
https://bugs.webkit.org/show_bug.cgi?id=255149

I also have a draft Chromium CL to fix this in Chromium (and match what the spec editors believe the specs require):
https://chromium-review.googlesource.com/c/chromium/src/+/3910374
which has an automatically-generated PR to WPT that will be merged when/if it lands:
web-platform-tests/wpt#39247

I think landing this Chromium CL is the right thing to do -- I think the inconsistency between keyboard behavior and what is exposed to assistive technology should be fixed, as I described in w3c/csswg-drafts#2632 (comment). However, my main concern is that I had the feeling from that CSSWG issue and from some of the browser bugs that other implementors might be grudgingly accepting the CSSWG resolution without actually planning to follow it.

This isn't a great situation to be in, so I'm attempting to escalate that situation into the standards-positions process to try and get a clearer understanding of other browser positions before we decide whether or not to change Chromium behavior (which, as I said above, I believe is bad but interoperable).