255149 2023-04-07 07:09:56 -0700 elements with CSS display:contents are not focusable 2026-04-27 00:25:18 -0700 1 1 1 Unclassified WebKit DOM Safari 16 Mac (Intel) macOS 13 NEW InRadar P2 Normal --- 1 dbaron ahmad.saleem792 ahmad.saleem792 aroselli cfleizach cyb.ai.815 jcraig jensimmons koivisto mike rniwa tyler_w webkit-bug-importer oldest_to_newest 1947270 0 dbaron 2023-04-07 07:09:56 -0700 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: https://bugs.chromium.org/p/chromium/issues/detail?id=1366037 https://bugzilla.mozilla.org/show_bug.cgi?id=1553549 https://bugzilla.mozilla.org/show_bug.cgi?id=1791648 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): https://chromium-review.googlesource.com/c/chromium/src/+/3910374 1948776 1 webkit-bug-importer 2023-04-14 07:10:15 -0700 <rdar://problem/108048437> 1983482 2 aroselli 2023-10-07 13:52:46 -0700 Confirmed this bug persists in Safari 17 (macOS 14). 1983485 3 aroselli 2023-10-07 14:30:44 -0700 And confirmed the bug persists in Safari TP 180 (Safari 17.4 beta). 1983709 4 jensimmons 2023-10-09 09:42:07 -0700 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. 1983710 5 aroselli 2023-10-09 10:00:32 -0700 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. 2204560 6 ahmad.saleem792 2026-04-26 00:38:05 -0700 This fixes it in WebKit: bool Element::hasFocusableStyle() const { auto isFocusableStyle = [](const RenderStyle* style) { return style && style->display().doesGenerateBox() && style->visibility() == Visibility::Visible && !style->effectiveInert() && (style->usedContentVisibility() != ContentVisibility::Hidden || style->contentVisibility() != ContentVisibility::Visible); }; if (renderStyle()) return isFocusableStyle(renderStyle()); // Compute style in yet unstyled subtree without resolving full style. CheckedPtr style = const_cast<Element&>(*this).resolveComputedStyle(ResolveComputedStyleMode::RenderedOnly); return isFocusableStyle(style.get()); } Changing: return style && style->display().doesGenerateBox() to: return style && style->display() != Style::DisplayType::None It fixes both - https://wpt.fyi/results/css/css-display?label=master&label=experimental&aligned&q=display-contents-focus 2204666 7 rniwa 2026-04-26 13:47:56 -0700 That seems like a reasonable change to me. 2204795 8 ahmad.saleem792 2026-04-27 00:25:18 -0700 Pull request: https://github.com/WebKit/WebKit/pull/63669