Safari 16 (release version) still broken #6451
Conversation
- 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
|
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"? |
|
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. |
|
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). |
|
Yeah, sounds reasonable, thank you. @jensimmons FYI |
|
We strongly disagree with the judgement that 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.
As stated elsewhere, our team is still working on
Web developers should not apply 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
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
|
|
For confirmation, the Safari 16.1 beta release notes are at https://developer.apple.com/documentation/safari-release-notes/safari-16_1-release-notes
|
This is also true for tables with
If it corresponds to what I see in TP 152, then yes, its accName will be announced. I look forward to it.
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).
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.
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
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. |
@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”). |
|
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. |
|
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. |
|
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). |
|
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 As a result I will restore the value to "partial" to ensure developers are more clearly made aware of the issue. |
Ctrl+Option+⌘+←↑→↓).Ctrl+Option+⌘+J) but its accessible name is not announced.Ref: https://adrianroselli.com/2022/07/its-mid-2022-and-browsers-mostly-safari-still-break-accessibility-via-display-properties.html#D-Safari