Consistency needed in display: contents

[jensimmons]

According to this tweet, both Firefox and Chromium do not handle accessibility properly when display: contents is applied to button.

Whatever the decision is about when browsers earn "support" rather than "partial support" on Can I Use, that decision should apply consistently across browsers.

I believe it would be most helpful to web developers if "partial support" in this case applies when there were so many problems with the accessibility of display: contents that those bugs were not easily summarized on Can I Use. The message was "don't use this for any use case, because no matter what you are doing, it's going be broken for too many users".

Now every browser (since Safari 16) has full accessibility support for most of the use cases for display: contents. Web developers should feel free to use it, except for a few specific exceptions. And they should have very clear information about those exceptions where they should absolutely not use it, because it is not accessible.

For Firefox, all Chromium browsers, and Safari 16.0, that includes button. For Safari 16.0, 16.1, and STP that includes HTML Tables. We have already written notes to mark such warnings.

I believe it is better for the difference between "broken in all cases" and "broken for these specific 1 or 2 cases" to be clear — and to be a different color, olive green vs bright green boxes. I believe this will empower developers to do the right thing for accessibility. Because they will have the knowledge they need to do the right thing.

I am not advocating to apply "supported" because I devalue accessibility. Nothing could be further from the truth. I am not advocating for "supported" because I believe there are too few people affected — or any of the other many accusations made in various threads on GitHub and on Twitter recently.

Developers should absolutely not apply display: contents to button or HTML tables until the accessibility problems are fixed.

The question at hand is about which method of communication will make it easiest for developers to clearly understand the current state of reality. The remaining accessibility problems with display: contents are with button and HTML tables, not with other elements. (Please let’s not muddy the waters in this issue debating the accessibility of technology that has nothing to do with display: contents. That is not helpful. General accusations that boil down to "she doesn't care" / "they don't get know what they are doing" are not helpful.)

If there are problems with the accessibility of display: contents when it is applied to other elements, then we should absolutely add those elements to the list, in additional notes.

I've created two PRs:
Option 1 — browsers with remaining problems with button and HTML tables are marked "partial supported" #6467
Option 2 — browsers with remaining problems with button and HTML tables are marked "supported" #6468.

I vastly prefer the second, because I do believe it helps developers understand how to build accessible web sites.

Let's empower web developers to do the right thing. By providing them with clear information. And let them know if they want to apply display: contents to grid items or flex items — which is what developers want to use this CSS value for the most — they now can. And it will be accessible.

[jensimmons]

According to this blog post, <ul>, <ol>, <dl> are not accessible when display: contents is applied in Chromium 103 on Windows 11 or Android 12.

I expect that's still true today. If we can retest and confirm, then let's add another note, and apply it's number to the Chromium browsers.

[Fyrd]

Thanks @jensimmons for bringing this up. Ordinarily I would agree that as long as the most common uses of the feature work we should go with the "Supported" value. As I you may have seen however after reaching out to the community responses were strongly in favor of going with "partial" as long as bugs result in content being made inaccessible.

Some pointed out that the people will simply not read the notes (hard to tell if true but certainly possible) and it was also brought up that the caniuse data may be used programmatically and not include the notes which would certainly be problematic. Based on this out of an abundance of caution I'd also prefer to err on the side of "partial" support. Either people read notes and will then learn it's safe to use in many cases (and that support differs per version) or they don't read notes and will assume it's safe everywhere.

So I think we should go with option 1, partial across browsers for now with appropriate notes. I may also get rid of some of the older notes that are less relevant and will help clarify the message for the latest versions.

Let me also ping @aardrian & @ericwbailey here as it would be great if we could be on the same page on this.

[aardrian]

Jen already pinged me on Twitter about filing a broader issue here, so I am glad she got ahead of me on this.

I agree with Jen and choose her Option 1 ("Partial").

As long as features render fundamental web technologies (tables, lists, headings, buttons, links, etc) inaccessible / inoperable then the "Supports" status should be "Partial".

The reason I have settled on just four elements/constructs for now (tables, lists, headings, buttons) is because:

• they are the most commonly broken HTML elements I have seen in my testing with display properties that stymie users; and
• this testing is done in my free time, which means I have to be judicious how many elements I test.

I am about to touch on other properties, even though this issue is scoped to how best to report support for contents. But the following examples could/should help demarcate where something slips from "Supports" to "Partial":

1. There needs to be room for some documented exceptions based on end user (not developer) feedback. For example, Safari/VoiceOver does not announce lists to users when the bullets are explicitly removed. James Craig has explained this (the closest to public documentation I can find), so I don't consider list-style: none to be a Safari bug and would mark list-style: none as "Supports". Sure, it annoys many developers, but Priority of Constituencies and all.

2. When block, inline-block and contents are applied, they also do not announce as lists in VoiceOver nor can they be navigated with list navigation commands (although <dl> are unaffected). This may be intentional, but I cannot be sure from James' explanation, and there is no Apple documentation (that I can find). Safari should/could get "Partial" support for display: block and display: inline-block for lists (again, pending clarification on if this intentional), but there is an easy case for "Supports".

3. I agree Chrome should get "Partial" support for display: contents for lists. Unlike Safari, there is no documentation suggesting removing the bullets is a trigger for a different exposure. Also unlike Safari, when I apply list-style: none in Chrome, JAWS/NVDA can still navigate them with list commands. However, they cannot when display: contents is applied, suggesting a bug.

4. Similarly, both Firefox and Safari break with tables rendered using flex and grid (I confirmed Firefox 5 days ago), so Firefox and Safari¹ should both get "Partial" for flex and grid, especially given that I run into tables styled with those properties regularly. Safari has the same problem with tables with display: block and display: inline-block, bolstering why it should be "Partial" for those properties (especially if the list issues already cited are bugs).

The good news on all of this is browser makers seem to be more motivated to fix bugs that are impacting their public support claims, including listings on this site. Chrome moved quickly to test, confirm, and discuss my button bug this week. Firefox engaged me on Twitter without me tagging them. An Apple dev fixed the headings issue after reading my post and engaging me (unprompted) on Twitter. Surfacing these issues publicly, even if they are years-old bugs, is helping them get attention with the devs in the browser teams who might not even know these are in the backlogs.

Thanks for tagging me @Fyrd and especially for soliciting and engaging with feedback from users of the site outside of this forum.

Footnotes

1. Sadly, I cannot test Safari 16 on iOS. My testing time and equipment are paid out of my own pocket, and while I just bought the latest iPad, I didn't realize it won't get the latest iPadOS and Safari 16 until October. That was my (costly) mistake. ↩

[ericwbailey]

Thank you for pinging me here, @Fyrd. I am glad to see the bug marked as partial support.

To supply some additional context behind my hardliner answer to your tweet:

• Situations where the underlying semantic, announced information is discarded by the presence of display: contents runs afoul of potential lawsuits in the United States and many other nations. In this context, caniuse was inadvertently facilitating both access issues and potential legal risk.
• Not every service that consumes caniuse exposes its notes. This means the nuance of this problem is lost.

Anecdotally, I find many developers I work with don't fully internalize that assistive technology has shades of support when it comes to the combination of web technologies required to function. They are used to web technologies either working or not, and communicating to them that there is the potential for lack of support on the OS, browser, and AT levels oftentimes leads to further confusion.

I would also like to express some thoughts around macOS/iOS and Safari that further colored my feedback:

• Safari is a quasi-evergreen browser, meaning that its browser updates are tied to operating system updates. This represents a lot more friction to an update path than an app or device restart.
• Many disabled individuals purposely avoid updating their software, as it represents a very real risk of breaking how they operate their device. Regressions and straight-up support breakage are commonplace.
• Apple prevents older hardware from receiving software updates, meaning there may be a scenario in the future where someone wants to update, but cannot.
  • This is especially relevant considering the historic barriers disabled individuals face towards employment, coupled with the cost of Apple hardware.

Don't get me wrong: I love that Safari is catching up with, and in some cases outpacing other browsers in the market. But due to the nuance previously described I would advocate for a healthy dose of caution.

[Fyrd]

Thanks all, I've gone ahead and made a first pass at updating the display: contents data based on our latest conversation. This does not yet include updates for the support for lists. Is there a Chromium ticket for this yet?

I also noticed the Firefox bug has this comment: https://bugzilla.mozilla.org/show_bug.cgi?id=1791648#c2 which suggests browsers may have an issue in displaying a focus indicator for elements without a layout box, curious if this is indeed an issue across browsers.

Also as it's been mentioned the data can be used programmatically, while true for the caniuse data it is even more common for the MDN BCD data so it would be worthwhile to bring up these same concerns there (as already started by @aardrian).

[SebastianZ]

I stumbled over this issue because of reading the article linked to from

Partial support refers to severe implementation bugs that renders content inaccessible for many element types.

Sorry for just skimming through the comments here, though the main accessibility issues linked there (like generally losing the accessibility role) already seem to be solved in all browsers and only issues for edge cases (like focusability of buttons with display: contents) are still open.

Therefore, I believe it's time to update the support status to "full support" everywhere. This indicates to authors that they can now generally use this value. Though the remaining issues should still be linked, of course, to note that there are still some remaining bugs.

Sebastian

[ericwbailey]

Anecdotally, I find many developers I work with don't fully internalize that assistive technology has shades of support when it comes to the combination of web technologies required to function.

browsers may have an issue in displaying a focus indicator for elements without a layout box

Sorry for just skimming through the comments here

[aardrian]

@SebastianZ

Therefore, I believe it's time to update the support status to "full support" everywhere.

Firefox, Chrome, and Safari each have bugs open (linked from my post above, which you may have missed if skimming). These may be edge cases for you, but not for those they affect. They remain critical blockers for those users.

[aardrian]

Chrome and Safari have regressed on support for elements with display: contents:
https://adrianroselli.com/2022/07/its-mid-2022-and-browsers-mostly-safari-still-break-accessibility-via-display-properties.html#Update16

Chrome seemed to decide broadly that all semantics should be stripped. Credit to Safari for improvements on buttons (mostly on mobile), but tables and lists regressed.