css.properties.display - Safari (thru 16) flex, grid, contents problems

[aardrian]

What type of issue is this?

Browser bug (a bug with a feature that may impact site compatibility)

What information was incorrect, unhelpful, or incomplete?

Safari on macOS lists full support for contents, flex, and grid, but that is not accurate.

When tables have display properties of contents, flex, or grid applied:

• VoiceOver announces the wrong column and row count for each table;
• VoiceOver does not announce column headers when moving between columns;
• VoiceOver table navigation commands do not work (Ctrl + Option + ⌘ + ← ↑ → ↓).

When a <button> has display: contents applied:

• Does not receive keyboard focus;
• Can be activated with a mouse, but not keyboard;
• Cannot be navigated with VoiceOver button command (Ctrl + Option + ⌘ + J);
• As of Safari TP 151, can be navigated with VoiceOver button command (Ctrl + Option + ⌘ + J) but its accessible name is not announced;
• As of Safari TP 152, its accessible name is announced;
• Safari 16 has regressed from Safari TP 152 — the accessible name is not announced and it has no accName in the accessibility tree.
• None of this is fixed in Safari TP 153.

What browsers does this problem apply to, if applicable?

Safari

What did you expect to see?

• I expect to be able to navigate a table in Safari with VoiceOver regardless of whether it has display: contents, display: flex, or display: grid.
• I expect VoiceOver with Safari to announce cell headers as I move through a table regardless of whether it has display: contents, display: flex, or display: grid.
• I expect to be able to use a <button> with my keyboard regardless of whether it has display: contents.
• I expect VoiceOver with Safari to announce a <button>'s accessible name regardless of whether it has display: contents.

Did you test this? If so, how?

Yes, as documented here:
https://adrianroselli.com/2022/07/its-mid-2022-and-browsers-mostly-safari-still-break-accessibility-via-display-properties.html#D-Safari

Test cases:

• tables: https://cdpn.io/pen/debug/xxGEKKJ
• buttons: https://cdpn.io/pen/debug/NWqbggX

Can you link to any release notes, bugs, pull requests, or MDN pages related to this?

• Bug 239479 - AX: Support display:contents for table elements

I understand the button issue is tracked internally. Headings issues were fixed in the same round as one button fix (https://twitter.com/tylerwilcock/status/1555683694672678912), but I suspect there are more internal issues.

Do you have anything more you want to share?

I am editing this here because it looks like Can I Use uses this data.

MDN URL

https://developer.mozilla.org/en-US/docs/Web/CSS/display

MDN metadata

MDN page report details

• Query: css.properties.display
• Report started: 2022-09-13T13:13:49.511Z

[aardrian]

Opened a fresh issue to address HTML tables and how they break when CSS display properties are used in Safari: Safari Table Support - CSS Display Properties Break Tables. #19994

[aardrian]

Bumping this again since Safari Technology Preview for 17 might address some of these issues and it would be nice to get a stake in the ground for current support as a future reference.

[jacob-willden]

I tested the buttons page on Safari 17.0 on MacOS 12.7 and can confirm that buttons with display: contents still cannot be accessed via the keyboard, unlike buttons without the CSS rule. So only partial support from Safari should be listed on the compatibility table for contents.

[foolip]

@aardrian feel free to send a PR with the note you think would be appropriate. It would be added here:

browser-compat-data/css/properties/display.json

Lines 63 to 65 in 61d1d52

	"safari": {
	"version_added": "11.1"
	},

And this is an example to follow:

browser-compat-data/html/elements/img.json

Lines 126 to 136 in 61d1d52

	"safari": [
	{
	"version_added": "15"
	},
	{
	"version_added": "14",
	"version_removed": "15",
	"partial_implementation": true,
	"notes": "Safari doesn't preserve space for images without a valid <code>src</code>, which may disrupt layouts that rely on lazy loading (see <a href='https://webkit.org/b/224197'>bug 224197</a>)."
	}
	],

[aardrian]

I filed this over a year ago and, frankly, took a lot of unpaid time already to research it, file it, and have it sit even after I advocated for it. I don't get compensated for this and already spend a lot of time just trying to get massive companies with paid employees to listen to demonstrable barriers in their software (only to then have them come in and undo my changes).

If I sound frustrated, it's because I am.

So please file a PR on my behalf and consider adding all the notes I listed when I opened the issue.

You can find more detail in the linked blog post.