Safari 16 (release version) still broken

[aardrian]

• VoiceOver announces the wrong column and row count for each table; VoiceOver does not announce column headers when moving between columns in a table; VoiceOver table navigation commands do not work (Ctrl + Option + ⌘ + ← ↑ → ↓).
• As of Safari TP 151, buttons can be navigated with VoiceOver button command (Ctrl + Option + ⌘ + J) but its accessible name is not announced.
• As of Safari TP 152, a button's accessible name is announced.
• Safari 16 has regressed from Safari TP 152 for buttons; a button's accessible name is not announced and it has none in the accessibility tree.

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

[Fyrd]

Thanks @aardrian, just want to confirm these deficiencies seem bad enough to still treat the feature as being partially supported vs listing them under "Known Issues"?

[aardrian]

Yes. Tables are unusable for VoiceOver users, which means de facto WCAG violations. A button without AC accessible name (itself a WCAG violation) will require the user to switch modes and navigate differently (not to mention use a different trigger). So the issue is both known and unsupported to the extent it breaks valid markup and creates barriers.

[aardrian]

Oh and keyboard-only non-Safari users cannot put focus on the button (big WCAG issue there, if browsers acted as if they were on the hook for WCAG).

[Fyrd]

Yeah, sounds reasonable, thank you. @jensimmons FYI

[jensimmons]

We strongly disagree with the judgement that display: contents should not be used by web developers because of the accessibility of the implementation in Safari 16. We’ve been working hard to resolve the main issues with display: contents and the accessibility tree so that web developers can begin to use this value.

Please remove the note “Partial support refers to severe implementation bug that renders the content inaccessible.” It no longer applies to Safari 16.

Adrian’s arguments can be summarized into three items. Let’s address each one.

VoiceOver announces the wrong column and row count for each table; VoiceOver does not announce column headers when moving between columns in a table; VoiceOver table navigation commands do not work (Ctrl + Option + ⌘ + ← ↑ → ↓). Tables are unusable for VoiceOver users, which means de facto WCAG violations.

As stated elsewhere, our team is still working on display: contents accessibility support for HTML tables.

• Bug 239479: Support display:contents for table elements
• Bug 239478: Support display:contents for elements with role attributes equal to: directory, grid, treegrid, table, row, gridcell, cell, columnheader, tree, treeitem

Web developers should not apply display: contents to an HTML table because it will not be accessible in WebKit.

It makes sense to list this limitation under known issues. But the need for more work to support HTML tables does not prohibit web developers from using display: contents everyplace else. The generic “severe implementation bug that renders the content inaccessible” does not empower web developers with the information they need to understand what’s happening, or to know that they can now safely use display: contents for the majority of their usecases.

As of Safari TP 151, buttons can be navigated with VoiceOver button command (Ctrl + Option + ⌘ + J) but its accessible name is not announced. As of Safari TP 152, a button’s accessible name is announced. [In] Safari 16… a button’s accessible name is not announced and it has none in the accessibility tree. A button without AC accessible name (itself a WCAG violation) will require the user to switch modes and navigate differently (not to mention use a different trigger).

This is clearly a bug in Safari 16.0. One that we have already resolved. The fix is currently in Safari 16.1 beta.

This bug only affects buttons that have display contents applied directly to them, like button { display: contents }, which is a rare use of this value. Again, this bug does not prevent web developers from safely using display: contents for the majority of their usecases.

Keyboard-only non-Safari users cannot put focus on the button.

No button can be focused via keyboard on our platforms. This has nothing to do with display: contents. The reasons are explained in this comment.

[jensimmons]

For confirmation, the Safari 16.1 beta release notes are at https://developer.apple.com/documentation/safari-release-notes/safari-16_1-release-notes

• Fixed display:contents buttons failing to expose their accessible name.

[aardrian]

Web developers should not apply display: contents to an HTML table because it will not be accessible in WebKit.

This is also true for tables with flex, grid, block, and inline-block. These all exist in the wild because I have encountered them in accessibility reviews.

This is clearly a bug in Safari 16.0. One that we have resolved. The fix is currently in Safari 16.1 beta.

If it corresponds to what I see in TP 152, then yes, its accName will be announced. I look forward to it.

This bug only affects buttons that have display contents applied directly to them, like button { display: contents }, which is a rare use of this value.

I have encountered it enough in accessibility reviews that it was one of four common elements of HTML that I used in my own support testing. So while you may suggest it is rare, I have encountered end users who are fundamentally blocked and sites that effectively fail WCAG SC 2.1.1 (and all the risk that comes with it).

Again, this bug does not prevent web developers from safely using display: contents for the majority of their usecases.

I am pointing out the use cases that leave disabled users stranded. A full barrier in a few core elements, IMO, outweighs support for more generic elements whose function and semantics are not as critical to users.

No button can be focused via keyboard on our platforms. This has nothing to do with display: contents. The reasons are explained in this comment.

That is demonstrably not true. Mobility impaired users enable full keyboard access, described in Apple's own documentation. It is a well documented feature outside of Apple's materials.

What that means is for a mobility-impaired user who relies on the keyboard via that macOS feature, the button with display: contents is inaccessible to them. The users most at risk are those most harmed by this bug.

For confirmation, the Safari 16.1 beta release notes are at https://developer.apple.com/documentation/safari-release-notes/safari-16_1-release-notes

That is awesome, and I look forward to testing it. However, release notes are not confirmation. Test cases are. Based on prior release notes getting it wrong (1, 2), until this is tested and demonstrated that is not evidence but simply an assertion.

I maintain the note “Partial support refers to severe implementation bug that renders the content inaccessible” applies to Safari 16. Whether it applies to Safari 16.1 is yet to be seen.

[cookiecrook]

No button can be focused via keyboard on our platforms.

That is demonstrably not true.

@aardrian you are correct. Jen was handed that line on an internal thread. Someone misspoke, and I was busy with TPAC and didn’t see it in time to correct it. @jensimmons was just the messenger. In hindsight, that comment may have been intended in the context of the click-focusability issue mentioned in the referenced link.

In addition to the system FKA feature you mentioned, all controls (including buttons) can be focused by default by using Option+Tab in Safari. If you change the setting in Safari Prefs, you can focus all controls with Tab similar to other browsers.

Users can also focus web buttons with dozens of built-in assistive technologies (VoiceOver, etc.) and third-party utilities (like “Shortcat”).

[cookiecrook]

FWIW, Chrome has the opposite default, but also has a setting to more closely match the Mac focusability defaults. I don’t recall if Firefox does.

[cookiecrook]

I also agree with Jen that the majority of display:contents usage is unblocked for authors by the hard work @twilco and others put into this Safari 16 release.

The table bug is should absolutely be referenced, but it is not blocking most authoring use cases.

[aardrian]

I see responding here is mostly moot since @jensimmons did an end-run around this and filed a PR to undo some of this: #6458

Regardless, "not blocking most authoring use cases" is a weird statement since this is about users. And for users who are impacted there is little option (other than asking them to get add-ons, rely on workarounds, or otherwise tell them they are holding it wrong).

[Fyrd]

After @aardrian and I solicited feedback (here and here) from the community the consensus seems pretty clear that developers and other accessibility experts agree that "partial support" is the more appropriate description given the deficiencies (some even arguing for "no support").

I'll further add that originally I made the assumption that not many developers would be interested in using display: contents on button and table elements, however after just a little searching I found at least one blog post discussing using it on buttons and another for table elements which to me demonstrates that there's real world use cases for doing so.

As a result I will restore the value to "partial" to ensure developers are more clearly made aware of the issue.