-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consistency needed in display: contents
#6469
Comments
According to this blog post, 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. |
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. |
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:
I am about to touch on other properties, even though this issue is scoped to how best to report support for
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
|
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:
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:
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. |
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). |
I stumbled over this issue because of reading the article linked to from
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 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 |
|
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. |
Chrome and Safari have regressed on support for elements with 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. |
According to this tweet, both Firefox and Chromium do not handle accessibility properly when
display: contents
is applied tobutton
.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
tobutton
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 withdisplay: 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" #6467Option 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.The text was updated successfully, but these errors were encountered: