New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 835455 link

Starred by 24 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 2018

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 2018

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.

This is even more complicated than I realised, actually.

Since the element won't have a CSS box model object (layout object) associated with it, it has no meaningful dimensions, meaning we can't associate any dimensions with the accessibility node.

This may be possible to work around for landmark roles, but for widget roles we run into added issues (apart from being unable to touch explore to the widget) - the element will also be unfocusable more or less by design.

There is a discussion of the focusability issue here but it seems unlikely that there will be any spec changes such that these elements will be required to be focusable.

I'm honestly not sure what the right solution is here. Firefox worked around the bounding box issue by marking the node as "offscreen", which I imagine produces a workable if sub-optimal experience, but I don't know that there is a reasonable solution to the focusability issue.
FYI that the Firefox fix did not address display: contents globally, only on a limited basis. Buttons are still affected. New issue filed there:

Mentioning it here because the Firefox team appeared to deal only with the list example in the original report. I'd like this fix to avoid being limited in the same way.
Project Member

Comment 19 by, Nov 12 (2 days ago)

The following revision refers to this bug:

commit 94eba324eda18982e67915d39b37aa87f29e025a
Author: Alice Boxhall <>
Date: Mon Nov 12 03:27:45 2018

Process attribute changes in AXObjectCache after layout is clean.

Processing attribute changes can cause AXObjects to get created,
which can cause crashes if layout is not clean.

Also, check that nodes do not need distribution updates before
processing attribute changes.

Bug: 835455
Change-Id: Ibf7a3d0e2d7befe53e43096e6d0414a5623e8885
Commit-Queue: Alice Boxhall <>
Reviewed-by: Nektarios Paisios <>
Reviewed-by: Keishi Hattori <>
Reviewed-by: Dominic Mazzoni <>
Cr-Commit-Position: refs/heads/master@{#607134}

Project Member

Comment 20 by, Nov 12 (2 days ago)

The following revision refers to this bug:

commit e7316d0c2c1a3ea146197778d926502c9646e4bf
Author: Alice Boxhall <>
Date: Mon Nov 12 05:43:59 2018

Prefer walking the LayoutTreeBuilder tree when building the Accessibility tree.

This is in preparation for cl/1242572, which will include elements
with a display: contents style in the Accessibility tree.

Since display: contents means an element will not get a LayoutObject,
walking the Layout Tree means we miss some elements.

Change-Id: I63c7da185da25f4661bfdeacb5a29ce79c2a3701
Commit-Queue: Alice Boxhall <>
Reviewed-by: Nektarios Paisios <>
Reviewed-by: Dominic Mazzoni <>
Cr-Commit-Position: refs/heads/master@{#607152}

Sign in to add a comment