focusability of elements with CSS display:contents

[dbaron]

WebKittens

@annevk

Title of the spec

Focusability of elements with CSS display:contents

URL to the spec

https://drafts.csswg.org/css-display-3/#box-generation

URL to the spec's repository

https://github.com/w3c/csswg-drafts

Issue Tracker URL

No response

Explainer URL

No response

TAG Design Review URL

No response

Mozilla standards-positions issue URL

https://github.com/mozilla/standards-positions/issues/772

WebKit Bugzilla URL

https://bugs.webkit.org/show_bug.cgi?id=255149

Radar URL

No response

Description

The discussion in https://github.com/w3c/csswg-drafts/issues/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 https://github.com/w3c/csswg-drafts/issues/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: https://github.com/web-platform-tests/wpt/pull/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 https://github.com/w3c/csswg-drafts/issues/2632#issuecomment-1497976046. 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).

[nt1m]

@cookiecrook @AndresGonzalezApple @twilco @fleizach

[cookiecrook]

@jensimmons https://github.com/mozilla/standards-positions/issues/772#issuecomment-1504819789

[jensimmons]

It's Rachel Andrew who has the proposal for separating DOM order from tab order. (People often confuse she & I.)

[jensimmons]

https://developer.chrome.com/blog/reading-order/

[annevk]

The problem from my perspective with display:contents that was never resolved by the CSS WG is that HTML has a concept of "focusable area" that depends on elements having a CSS box ("being rendered"). However, as I understand it with display:contents there would be no box. Nobody did the work however to account for that mismatch.

Addressing that mismatch sounds reasonable, but I think it requires more than a set of browser patches.

[annevk]

@dbaron created https://github.com/whatwg/html/pull/9425 to address that concern and it looks rather simple. I've asked some people for review, including @cookiecrook. 😊

Overall this is probably okay (in particular if we expose these elements to AT despite not having a box I agree with OP that they should be focusable), but due to display:contents the element now lacking a box it's unclear what to do about focus outlines/rings as was pointed out in Mozilla's review. Is that something the web developer should solve or do we need something else for that? For that I'd be inclined to make it the web developer's problem for now, but we might have to revisit if this leads to inaccessible experiences.

[nt1m]

Our focusability checks don't depend on the CSS box, they only depend on the element's style, so this is feasible.

See: https://searchfox.org/wubkat/rev/49a9b51cd3f2e1941aa86570e9948012b4c1cbfa/Source/WebCore/dom/Element.cpp#769-785

That being said, the focus outline is a real concern, we don't have a way to draw around those elements.

[annevk]

Hey @dbaron, do you all have any further thoughts on the outline issue? We tried to think of some alternatives, but none of them were great. Seems better to just not use display:contents if you need focusability.

[dbaron]

So I think my preference for outline is that we say that if a developer is going to depend on focusability of something with display: contents, they need to add appropriate styles to draw the focus outline (for example, by drawing it on an appropriate descendant or descendants).

I admit that developers aren't going to get that right all the time. But the same is true of the current situation. That is, I think developers will sometimes not do what we want if we say either of:

• developers shouldn't use display: contents if they need an element to be focusable, or
• developers should add appropriate focus styles if they use display: contents on something that is focusable.

(Note that needing an element to be focusable is often a need for users using keyboard navigation or similar, that may not apply to users using a mouse. So developers may well miss it.)

Then the question is which problem is worse: is it worse to have an element that the user needs to get to but that can't be focused at all, or worse to have it be focusable but without a good indication that it's focused. The latter at least gives a keyboard user a chance to figure out what's going on, whereas with the former they're out of luck. So my inclination is that having the element be focusable but without an indication of focus is less bad than having it not be focusable at all when it should be. I admit that this is just my instinct and I haven't attempted to confirm this. And there's also the confounding factor that the two problems might occur at different rates.

[annevk]

Having discussed this with colleagues I suggest a tentative position of "neutral" (to be finalized one week from now absent any objections) given that there's not really a satisfactory solution here. We're okay with https://github.com/whatwg/html/pull/9425 landing though, to be clear.