New issue
Advanced search Search tips
Starred by 21 users

Issue metadata

Status: Started
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug

issue 874753

Sign in to add a comment

Element not exposed to accessibility tree when it is set to display: contents

Reported by, Apr 20

Issue description

Chrome Version       : 66.0.3359.117 (Official Build) (64-bit)
OS Version: OS X 10.12
URLs (if applicable) :
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari: FAIL
    Firefox: FAIL (bug here:
    IE/Edge: n/a (does not support display:contents)

What steps will reproduce the problem?
1. In a grid container, add on grid item that is a <ul>
2. Verify that is has an accessible role of 'list'
3. Set the item to 'display: contents' with CSS
What is the expected result? 
The element still has its accessible role of 'list'

What happens instead of that?
The element is no longer exposed to the accessibility tree

Please provide any additional information below. Attach a screenshot if
Background: More meaningful/semantic markup improves accessibility as AT can better understand what stuff is on the page. In CSS Grid Layout, items can be placed on a grid when they are direct children. That is an incentive for authors to make flatter/less meaningful markup. display:contents solves this and lets users effectively place 'grand children' on the grid.
Labels: Needs-Triage-M66
Labels: Needs-Feedback Triaged-ET
hidde@ Thanks for the issue.

Tested this issue on Mac OS 10.13.3 on the reported version 66.0.3359.117 and the latest canary 68.0.3403.0 by following the below steps.

1. Launched Chrome and navigated to the given codepen link.
2. Opened Devtools -> Elements -> Accessibility and can see the list displayed there.
Attached is the screen shot for reference.

Request you to check and confirm of anything is missed from our end in triaging the issue.

Also request you to provide a screen cast of the steps followed which will be helpful in further triaging of the issue.

221 KB View Download
Thanks for triaging! 

In the screenshot, the list with ingredients is selected, that still has its accessible role, because it is not part of the grid.

The problem is in the list of sponsors, the second UL on the page (<ul class="sponsors"/>), which is set to display: contents, that does not have its accessible role. 
Project Member

Comment 4 by, Apr 23

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit - Your friendly Sheriffbot
In the attached screenshot, the element that has display: contents set to it, it shown as ‘Accessibility node not exposed’. When we remove 'display: contents' from it, this changes and it does get an accessible role.
Screen Shot 2018-04-23 at 14.06.01.png
532 KB View Download
Components: Blink>Accessibility
Labels: -OS-Mac
Clearing the Mac bit as it doesn't look Mac specific. Redirecting to Blink Accessibility.
Labels: M-68 FoundIn-68 Target-68 OS-Linux OS-Mac OS-Windows
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on chrome reported version 66.0.3359.117(as per screenshot provided in comment#5) using Mac 10.12.6, Windows 10 and Ubuntu 14.04 and same issue is seen on latest chrome 68.0.3405.0. As the issue is seen from introduction of Accessibility from M-64, hence considering this issue as non regression and marking it as untriaged.

Any updates on this?

I’d like to add two use cases:

* use of a <ul> element to group list items in Grid Layout (as described here:
* use of <nav> element in a Grid Layout (as described here:

Basically it affects any site that uses HTML elements with specific roles and wants to lay out that element’s children on a Grid. 

Accessibility experts start recommending to not use display:contents at all, that would be sad as it is a great future. 

Many thanks for looking at this!
Status: Assigned (was: Untriaged)
Agreed it would be a shame if people couldn't use display: contents! I started having a poke at this - no working solution yet but I'm interested in solving this.
@Alice: That's awesome, thanks for the update! 
FWIW, Firefox has fixed this issue in release 62.0a1:

Also note that adding ARIA roles does not put the node back into the accessibility tree. The attached image shows the accessibility tree with a role set.

Finally, I have more examples here:

44.1 KB View Download
Is there any news on this issue? 

Fwiw, this problem is now listed as an implementation bug on Can I Use: 
Blocking: 874753
Tests for fieldset/legend in
Status: Started (was: Assigned)
This is in progress. 

This is a non-trivial change as we have previously walked the layout tree to build the accessibility tree, so it requires a significant shift.

Sign in to add a comment