Element not exposed to accessibility tree when it is set to display: contents
Reported by hi...@hiddedevries.nl, Apr 20
Chrome Version : 66.0.3359.117 (Official Build) (64-bit) OS Version: OS X 10.12 URLs (if applicable) : https://codepen.io/hidde/pen/gzbMeL Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari: FAIL Firefox: FAIL (bug here: https://bugzilla.mozilla.org/show_bug.cgi?id=1455357) 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 possible. 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.
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. Thanks..
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.
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - 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.
Clearing the Mac bit as it doesn't look Mac specific. Redirecting to Blink Accessibility.
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. Thanks!
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: https://hiddedevries.nl/en/blog/2018-04-21-more-accessible-markup-with-display-contents) * use of <nav> element in a Grid Layout (as described here: https://twitter.com/AmeliasBrain/status/991026364512813056) 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!
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: https://bugzilla.mozilla.org/show_bug.cgi?id=1455357 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: http://adrianroselli.com/2018/05/display-contents-is-not-a-css-reset.html#Bugs
Is there any news on this issue? Fwiw, this problem is now listed as an implementation bug on Can I Use: https://caniuse.com/#feat=css-display-contents
Tests for fieldset/legend in https://github.com/web-platform-tests/wpt/pull/12691
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