This bug is based on the conclusion in https://github.com/w3c/csswg-drafts/issues/2632 (and was also discussed a bit in https://github.com/whatwg/html/issues/1837 ). In WebKit, elements with display: contents are not currently focusable, but they should be.
This behavior currently matches other browsers. However, I think this behavior is problematic 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 and I believe implemented in WebKit in https://bugs.webkit.org/show_bug.cgi?id=243486 ) match the focusability, which it currently does not.
Steps to reproduce:
1. load https://cdpn.io/aardrian/debug/NWqbggX (taken from two of the Gecko/Chromium bugs below)
2. press Option+Tab to cycle through buttons
Expected results: focus moves through all buttons (although perhaps no visual indication of focus on the display:contents button)
Actual results: focus skips the display:contents button
Parallel Chromium and Gecko bugs are:
I have a change to Chromium to fix this (though I haven't merged it yet, partly out of concern for whether other browsers are willing to match):
Confirmed this bug persists in Safari 17 (macOS 14).
And confirmed the bug persists in Safari TP 180 (Safari 17.4 beta).
Adrian, this is still "a bug" because the standards questions have not been settled yet. There's not agreement on how browsers should behave. That needs to be decided before any browser can conform to the decisions.
Agreed it is a bug (no quotes) and also agree that OP's request for position and standards clarity are blockers.
I encourage all browsers (and their representatives in the standards bodies) to settle this so users don't have to wait any longer.