Repository navigation
[css-a11y][css-display] display: contents; strips semantic role from elements #3040
Description
The display: contents; property is part of the CSS Display Module Level 3. APA tracking of CSS Display Module Level 3
display: contents; causes an element’s children to appear as if they were direct children of the element’s parent, ignoring the element itself. This can be useful when a wrapper element should be ignored when using CSS grid or similar layout techniques.
Unlike display: none; where users are unable to interact with the element to which it is applied, by using display: contents; the element is still visible and you can interact with it but only “through its contents” (See Ire Aderinokun’s blog post on “How display: contents; Works”).
Scott O’Hara raised the issue that in the latest version of Bikeshed, the use of display: contents; on the Table of Contents has led to accessibility issues for both screen readers and even standard keyboard tab use, which he notes in “display contents causing TOC issues".
Hidde de Vries blog post “More accessible markup with display: contents” explains that current browsers that support display: contents; “do not only interpret it as a layout thing, but also derive meaning from it”. The display property only affects the visual layout, but by applying display: contents; to an element, browsers strip the element of its role semantics, causing accessibility issues.
Currently, the note for display properties states that “The display property has no effect on an element’s semantics: these are defined by the document language and are not affected by CSS. Aside from the none value, which also affects the aural/speech output [CSS-SPEECH-1] and interactivity of an element and its descendants, the display property only affects visual layout: its purpose is to allow designers freedom to change the layout behavior of an element without affecting the underlying document semantics."
When display: contents; is applied to some elements, for example, form elements such as , and <textarea> (see Effects of ‘display: contents;’ on Unusual Elements), it treats the display: contents; as display: none;.
Hidde de Vries has filed bugs with Firefox, Chrome 66 and Safari and Webkit. Firefox 62 apparently has a fix that is included in the next release in early September 2018. Pressure needs to be applied to the other browser vendors to fix the issues of display: contents; interfering with the element’s inherent role semantics.
The CSS A11Y Task Force recommends one or both of the following approaches:
- Encouragement for browser vendors to fix this issue
- A warning note in the module document advising developers of the issues with
display: contents;
Activity
SelenIT commentedon Aug 22, 2018
Maybe the issue about focusing behavior of elements with
display:contents(#2632) can be considered related here?fantasai commentedon Oct 11, 2018
Agreed this is a very unfortunate implementation bug. Happy to add a warning note until implementations fix their bugs.
[css-display-3] Add note warning that 'display: contents' is fundamen…
jensimmons commentedon May 22, 2019
Those of us teaching new layout techniques to the world have been talking about this for a while now — telling people they cannot use
display: contents;until this is fixed. We changed Can I Use to reflect the problem: https://caniuse.com/#feat=css-display-contents to help spread the word.tabatkins commentedon May 22, 2019
The a11y-tree issue has been fixed in Chrome, thanks to some great work from Alice Boxhall. There's still potentially focus-related issues tho.
css-meeting-bot commentedon May 22, 2019
The CSS Working Group just discussed
display: contents and a11y.The full IRC log of that discussion
<fantasai> Topic: display: contents and a11y<fantasai> github: https://github.com//issues/3040
<AmeliaBR> fantasai: We added warning to the spec from this issue. But we're still missing browser fixes.
<AmeliaBR> florian: I think Chrome has fixed the accessibility tree issue, but still not focusability.
<AmeliaBR> rachelandrew: Yes, Chrome is working on it.
<AmeliaBR> fremy: Yes, issue is the focusability. So it's not keyboard accessible.
<AmeliaBR> Rossen_: In summary, Chrome has made progress but not done yet. Any other asks beyond nudging WebKit and Mozilla?
<AmeliaBR> jensimmons: Mozilla has shipped it per spec. It's Webkit and Chrome.
<AmeliaBR> … this is truly, deeply important that we get this fixed.
<AmeliaBR> florian: So, it's fixed in Mozilla?
<AmeliaBR> jensimmons: yes. But that's not the main reason for the fix. It's that this is broken for now & we need to recommend that people don't use it.
<AmeliaBR> fremy: I'm not sure it's entirely fixed in Firefox when it comes to focusability.
<fantasai> Current note in the spec fwiw: https://github.com/w3c/csswg-drafts/commit/10d721ddefe82730a712b392eaf8695c75764e30
<fremy> link: https://tabatkins.github.io/bikeshed/ (try to tab-navigate the table of contents on the left)
<AmeliaBR> Rossen_: Let's not go too deep into who has or hasn't done what. The point is to elevate this issue & get people to raise it in your team.
<AmeliaBR> jensimmons: if there are still issues in Firefox, file a bug & please let me know.
jensimmons commentedon May 22, 2019
I believe this is already entirely fixed in Firefox, but someone on the call (I couldn't hear who) mentioned that they thought it was not yet fixed. If that's true — if something seems still not right in Firefox, do file a bug, and let me know.
rachelandrew commentedon May 22, 2019
It was mentioned on the call that Chrome have a partial fix for this and are working on it. https://bugs.chromium.org/p/chromium/issues/detail?id=835455
Firefox has fixed some of the problems but issues still remain, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1500958
jensimmons commentedon May 22, 2019
Ticket for sorting out the current status of things on Can I Use: Fyrd/caniuse#4706
I believe all the partially-fixed stages (both the "still super broken" and the "almost there, but not") should have yellow-green boxes. (Which means Firefox drops back to yellow-green). There's a bit of debate about that. I'd love others to chime in.
And there's a lot of detail to document around which browser having which level of support when & links to bug tickets. It'd be helpful if folks could help see that this is correct.
1 remaining item
jensimmons commentedon Oct 6, 2023
There is still more work for browser engines to do. It's documented at: https://caniuse.com/css-display-contents
aardrian commentedon Oct 7, 2023
That visual Can I Use table implies all browsers have been broken in the same way.
All browsers ironed out the broader
display: contentssemantics issues many versions / years ago (barring a 113-114 Chrome regression). Safari has caught up as of v17 (with one known outstanding issue for headings: https://bugs.webkit.org/show_bug.cgi?id=261978).Where all browsers are struggling is with interactive elements that have
display: contents, including Safari (I filed a PR with Can I Use), owing to some disagreement on how to interpret the spec. As such, there is a request for position by Chrome from each engine:Which has lead to this WHATWG proposal:
whatwg/html#9425
In other words, this may need to be coordinated with WHATWG as it appears to be running at the problem as well.
bleper commentedon Oct 8, 2023
@aardrian The specification clearly states that only the layout should change, and the CSSWG follows this in resolutions about things related to focus, such as #3323.
aardrian commentedon Oct 8, 2023
@rthrejheytjyrtj545 I am not clear on what your link and comment mean for what I posted. Are you refuting, adding context, or something else?
bleper commentedon Oct 8, 2023
@aardrian Apart from the fact that this is the topic of another issue that has long been closed and is referenced in the discussion of this issue, from a CSS point of view this is a settled issue, because if it were not so there would be no point in solving other issues related to providing focus state to the user.
aardrian commentedon Oct 9, 2023
@rthrejheytjyrtj545 Yet browsers are still struggling. If the user cannot get to the interactive control, then the semantics are de facto stripped. Also, two comments above suggest focus concerns could be in scope for this issue.
Either way, I may be misunderstanding your comments (I am still fuzzy, in fact). I was mostly reaffirming Jen's note that browser engines have more to do and adding references to outside efforts of what they are trying to do.