css.properties.display - Safari (thru 16) flex, grid, contents problems
Nobody has claimed this yet.
- Dominant language
- JSON
- Stars
- 5.8k
- Forks
- 2.6k
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 186
Description
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, ordisplay: 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, ordisplay: grid. - I expect to be able to use a
<button>with my keyboard regardless of whether it hasdisplay: contents. - I expect VoiceOver with Safari to announce a
<button>'s accessible name regardless of whether it hasdisplay: 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
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the browser-compat-data entry for css.properties.display and compare its Safari support data with the table and button test cases linked in the issue. Check the linked WebKit bug and current Safari behavior before determining which compatibility notes or support values are inaccurate; done means the entry reflects the documented Safari accessibility limitations.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- css
- Domain
- accessibility
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100