Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jonnyjames opened this issue Aug 22, 2018 · 8 comments

Comments

Projects
None yet
7 participants
@jonnyjames
Copy link

commented Aug 22, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Aug 22, 2018

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

@fantasai

This comment has been minimized.

Copy link
Collaborator

commented Oct 11, 2018

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

fantasai added a commit that referenced this issue May 16, 2019

@fantasai fantasai added Agenda+ and removed Agenda+ F2F labels May 16, 2019

@jensimmons

This comment has been minimized.

Copy link

commented 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

This comment has been minimized.

Copy link
Member

commented 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

This comment has been minimized.

Copy link
Member

commented 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

This comment has been minimized.

Copy link

commented 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

This comment has been minimized.

Copy link
Contributor

commented 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

This comment has been minimized.

Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.