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

jonnyjames has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-a11y][css-display] display: contents; strips semantic role from elements  ==
The `display: contents;` property is part of the [CSS Display Module Level 3](https://www.w3.org/TR/css-display-3/). [APA tracking of CSS Display Module Level 3](https://www.w3.org/WAI/APA/wiki/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](https://bitsofco.de/how-display-contents-works/)”). 

Scott O’Hara raised the issue that in the latest version of [Bikeshed](https://github.com/tabatkins/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](https://github.com/tabatkins/bikeshed/issues/1316)". 

Hidde de Vries blog post “[More accessible markup with display: contents](https://hiddedevries.nl/en/blog/2018-04-21-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](https://drafts.csswg.org/css-display/#the-display-properties) states that “The [display property](https://drafts.csswg.org/css-display/#propdef-display) has no effect on an element’s semantics: these are defined by the [document language](https://drafts.csswg.org/selectors-4/#document-language) and are not affected by CSS. Aside from the [`none`](https://drafts.csswg.org/css-display/#valdef-display-none) value, which also affects the aural/speech output [CSS-SPEECH-1](https://drafts.csswg.org/css-display/#biblio-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 <select>, <input> and <textarea> (see [Effects of ‘display: contents;’ on Unusual Elements](https://drafts.csswg.org/css-display/#unbox-html)), it treats the `display: contents;` as `display: none;`.

Hidde de Vries has filed bugs with [Firefox](https://bugzilla.mozilla.org/show_bug.cgi?id=1455357), [Chrome 66](https://bugs.chromium.org/p/chromium/issues/detail?id=835455) and [Safari](https://bugreport.apple.com/web/?error&bugaccess) and [Webkit](https://bugs.webkit.org/show_bug.cgi?id=185679). 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 recommendations:

- Encouragement for browser vendors to fix this issue
- A warning note in the module document advising developers of the issues with `display: contents;`  



Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3040 using your GitHub account

Received on Wednesday, 22 August 2018 11:44:19 UTC