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 · 14 comments
Assignees
Labels
a11y-needs-resolution Issue the Accessibility Group has raised and looks for a response on. Closed Accepted as Editorial css-display-3 Current Work Needs Testcase (WPT)

Comments

@jonnyjames
Copy link

jonnyjames 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
Copy link
Collaborator

SelenIT commented Aug 22, 2018

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

@fantasai
Copy link
Collaborator

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
@jensimmons
Copy link
Contributor

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
Copy link
Member

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
Copy link
Member

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
Copy link
Contributor

jensimmons 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
Copy link
Contributor

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
Copy link
Contributor

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.

@plehegar plehegar added the a11y-tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response. label Feb 15, 2020
@michael-n-cooper michael-n-cooper added the a11y-needs-resolution Issue the Accessibility Group has raised and looks for a response on. label May 20, 2020
@w3cbot w3cbot removed the a11y-tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response. label May 22, 2020
@fantasai fantasai removed the a11y label Oct 29, 2020
@jensimmons
Copy link
Contributor

jensimmons commented Oct 6, 2023

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

screenshot of Can I Use page linked above

@aardrian
Copy link

aardrian commented 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: 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:

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
Copy link

@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
Copy link

aardrian commented 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?

@rthrejheytjyrtj545
Copy link

rthrejheytjyrtj545 commented 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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a11y-needs-resolution Issue the Accessibility Group has raised and looks for a response on. Closed Accepted as Editorial css-display-3 Current Work Needs Testcase (WPT)
Projects
None yet
Development

No branches or pull requests