Focusability of elements with display:contents

[dbaron]

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

[emilio]

My main concern with this is that it creates yet another issue for keyboard users: Elements with display: contents that are focused can't show focus indicators on screen.

That's expected, since they generate no box, but that's rather bad user experience :(

So I guess if we do this we'd need to somehow start drawing outlines of display: contents elements, and that's not always clear how it should work, since they lack a box...

[emilio]

cc @jcsteh

[dbaron]

Yeah, I think there are two reasonable possibilities for how to handle focus outlines for display: contents:

1. We could say that when authors make a focusable element display: contents, they're responsible for creating focus styles that outline appropriate descendants.
2. We could leverage the way that outline is supposed to draw around descendants to paint outlines for elements with display: contents. (I don't currently remember how much implementations have moved towards (or away from!) actually making outlines draw around descendants.)

[emilio]

@dbaron I'm skeptic about (2) because it'd mean we both need to track overflow of something that doesn't have a box, and because fundamentally descendants of display contents elements can be in arbitrary-ish stacking contexts / z-order... I guess I could live with (1), but it also feels weird that it wouldn't work by default. Maybe it's good enough?

[emilio]

The other thing that we need to figure out if we do this is how this interacts with @fantasai's / @jensimmons' / etc proposals to change the focus order based on layout order...

[jensimmons]

I think you are thinking of @rachelandrew 's proposal.

[dbaron]

@emilio I'm curious if you have additional thoughts on this, particularly after my brief pitch on this topic to the CSS WG (2 weeks ago).

[emilio]

Yeah, I think I agree with you that this is kind of the lesser evil.

I think I'm positive on making them focusable assuming that:

• The answer for keyboard indicators is "authors are responsible for them". Anything else seems too magic to me.
• We have a sensible answer for how this interacts with the proposals in [css-flexbox][css-grid] Providing authors with a method of opting into following the visual order, rather than logical order w3c/csswg-drafts#7387.

[zcorpan]

Marking positive per @emilio 's comment.

[dbaron]

FYI, given feedback from accessibility folks, I'm going to try to investigate option (2) above, actually drawing outlines for elements with display: contents. I think it's the sort of thing where we don't need to get every edge case correct (e.g., z-index interactions) as long as we can find a straightforward and interoperable way to do it.

I'll try to post an issue to csswg-drafts once I've thought about it a bit more.