display: contents accessibility

[jensimmons]

Description

The CSS rule display: contents is a useful feature that developers have wanted to use for years. But the original CSS property was not designed to fully take into consideration how browser engines could implement this in an accessible way. Because it required significant refactor of the entire accessibility system in browser engines, it's taken time to fix. In the meanwhile, using display:contents could make large chunks of content disappear for some users.

Because of the accessibility problems, the message to developers has been "yes, this is implemented everywhere, but don't use it!" Of course, not everyone gets the memo, and people are using it anyway.

Great progress has been made improving the accessibility of elements that have display:contents applied & their children. But there is still more work to do.

By including this work in Interop 2024, we can finally get all the browsers on the same interoperable, accessible implementation.

Specification

https://www.w3.org/TR/css-display-3/

Open Issues

There is one open issue: w3c/csswg-drafts#3040, which looks stale, and only open because it needs test cases.

Tests

There are tests for display: contents here, but the needed accessibility test coverage is missing. For this proposal to be part of Interop 2024, we will need to write new tests.

Current Implementations

• Blink
• Gecko
• WebKit

Standards Positions

None found.

Browser bug reports

https://bugs.chromium.org/p/chromium/issues/detail?id=1366037
https://bugzilla.mozilla.org/show_bug.cgi?id=1791648

Developer discussions

https://adrianroselli.com/2018/05/display-contents-is-not-a-css-reset.html
And more from Adrian: https://adrianroselli.com/?s=display%3A+contents
https://cloudfour.com/thinks/see-no-evil-hidden-content-and-accessibility/
https://hidde.blog/more-accessible-markup-with-display-contents/
https://www.smashingmagazine.com/2019/05/display-box-generation/#display-contents

Workarounds

There is no work-around. If developers use display: contents in specific usecases, it's not accessible.

Accessibility Impact

This is all about making display: contents fully accessible.

Privacy Impact

No privacy impact.

[aardrian]

Adding nuggets, assuming I understand this issue correctly.

Tests

Do you have a version of this with the current releases of each browser? In my experience, beta releases tend to have shifting support and regressions, so I am generally more interested in what has shipped to users.

Standards Positions

• WHATWG: Allow elements with display:contents to be focusable. whatwg/html#9425 (just a PR, so not a position so much as discussion)
• CSSWG: [css-display][css-aam][selectors-4] How elements with display:contents get focused? w3c/csswg-drafts#2632

Browser bug reports

• https://bugs.webkit.org/show_bug.cgi?id=255149
• https://bugs.webkit.org/show_bug.cgi?id=261978

[jensimmons]

WPT tests can be run on any browser. The infrastructure at WPT is setup to test multiple versions of the major desktop browsers (on older operating systems), so yes, the customer versions of Chrome, Firefox and Safari are easily testable.

If you go to https://wpt.fyi/interop-2023, you can click the "Stable" button to switch. Both the future and the current versions of the three browser engines are scored as part of the Interop project.

[aardrian]

Ace, that is great info.

Though I cannot figure out how to get from that page to the stable version of the test you shared. I did discover I can tweak the URL to get it, though:
https://wpt.fyi/results/css/css-display?label=master&label=stable&aligned&q=display%20contents

Thanks!

[jensimmons]

Can I Use has details on what's buggy in which browser version: https://caniuse.com/css-display-contents

[alice]

I’m really glad to see continued attention being paid to the accessibility issues with display: contents.

I would, however, really like to retire the narrative that the accessibility issues were due to “misunderstandings” or “bugs” on the part of implementers.

The design of the feature apparently made an unstated, unchecked and incorrect assumption about how accessibility API support was implemented in at least two browser engines at the time: that the accessibility tree was built off the DOM tree, rather than (effectively) the CSS box tree. Since display: contents elements don't generate CSS boxes, naturally they don't appear when walking that structure, and there's no way to reach them. As such, correcting the issue in these browsers entailed not fixing a bug or a few faulty lines of code, but a significant refactor of the entire accessibility system in those engines. Not only that, but it required addressing subtle questions such as “if an element doesn’t have a CSS box associated with it, what dimensions do we report to assistive technologies?”

As long as this “just a bug that nobody bothered to fix for ages” narrative persists, we’re making invisible the work that was actually necessary to even begin addressing the issue.

Furthermore, while it seems that there may have been some well-intentioned design goals around accessibility, these goals don't seem to have been well documented, nor the desired accessibility outcomes specified. The first mention of accessibility in the spec seems to have been the addition of a note that these unspecified requirements haven't been implemented correctly. How could implementers understand or test something that wasn't specified to begin with?

For this issue, I would just like to ask that the description be edited to avoid perpetuating this "implementation bug" narrative.

[jensimmons]

There's an open issue in the Interop 2023 Accessibility Testing Investigation Project (a current project that's already written over 850 new tests this year) for writing accessibility tests for display: contents.

web-platform-tests/interop-accessibility#60

[zcorpan]

We discussed this proposal in the Interop Accessibility investigation check-in meeting today (minutes).

Since tests aren't written yet and per feedback from @alice in web-platform-tests/interop-accessibility#60 (comment) about what we're currently able to test may be insufficient to fully/usefully test display: contents, I think this proposal is better to include in the Accessibility investigation effort for 2024.

[cookiecrook]

FYI @rahimabdi's PR web-platform-tests/wpt#43740 is likely going to land with some new focus tests that no engines are passing at the moment. If there are issues including the new focus tests in Interop 2024, they are broken out into a separate file, so they can be included in Interop or not.

[zcorpan]

Thank you for proposing display: contents accessibility for inclusion in Interop 2024.

We are pleased to let you know that this proposal was accepted as part of the Accessibility focus area. You can follow the progress of this focus area on the Interop 2024 dashboard.

For an overview of our process, see the proposal selection. Thank you for contributing to Interop 2024!

Posted on behalf of the Interop team.