[css-a11y][css-display] display: contents; strips semantic role from elements

[jonnyjames]

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;

[SelenIT]

Maybe the issue about focusing behavior of elements with display:contents (#2632) can be considered related here?

[fantasai]

Agreed this is a very unfortunate implementation bug. Happy to add a warning note until implementations fix their bugs.

[jensimmons]

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]

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]

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]

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]

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]

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.

[jensimmons]

There is still more work for browser engines to do. It's documented at: https://caniuse.com/css-display-contents

[aardrian]

That visual Can I Use table implies all browsers have been broken in the same way.

All browsers ironed out the broader display: contents semantics 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:

• Mozilla: Focusability of elements with display:contents mozilla/standards-positions#772
• WebKit: focusability of elements with CSS display:contents WebKit/standards-positions#164

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.

[rthrejheytjyrtj545]

@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]

@rthrejheytjyrtj545 I am not clear on what your link and comment mean for what I posted. Are you refuting, adding context, or something else?

[rthrejheytjyrtj545]

@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]

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