Using macOS 14 and Safari 17 with VoiceOver on a site that uses `aria-describedby` (Example: https://a11ysupport.io/tests/html/aria/aria-describedby.html) results in the accessible description not being announced after a pause, as it has in prior Safari versions. After the field name is announced as well as interaction instructions, VoiceOver then says "Press control option command slash to bring up the more content menu." After I perform that command, a dialog appears and announces it is the "more content menu." Then I have to arrow into it to hear the accessible description. As developers have come to rely on `aria-describedby` to convey instructions and error messages for form fields, given users have come to expect that for years with VoiceOver, and given no other browser behaves this way, I expect a lot of frustration from end users. This is one example (shared in the issue below) that demonstrates a common pattern: https://cdpn.io/pen/debug/poqQRQa/b71a4e4bdedd09281a6b5380f2014483 There is a related issue about `aria-description` announcing in this way (though it has a recent comment flagging this `aria-describedby` bug): https://bugs.webkit.org/show_bug.cgi?id=260835 A resolved bug to reconcile `aria-describedby` and `aria-description` in WebKit, but I suspect they were both mapped to AXCustomContent instead of AXHelp or perhaps the priority was unset from AXCustomContentImportanceHigh (I am clearly speculating): https://bugs.webkit.org/show_bug.cgi?id=255812
<rdar://problem/116683729>
Confirmed this also happens in Safari Technology Preview 180.
Associating content with `aria-describedby` in this way is also an important part of achieving an accessible "tooltip" pattern, as seen in https://zoebijl.github.io/apg-tooltip/ and is leveraged in both of these use cases (as well as other less common ones) across the Spectrum Web Components library at Adobe. As we're actively working today to bring products like Photoshop, Express, and more to Safari in our move to serve more visitors where they already are, API inconsistencies like this that prevent us from accurately serving those visitors will slow the process.
Announcement is working only for inputs with radio, checkbox, submit, reset, button, file, or range type. Otherwise, the bug is present as Adrian described. The same bug is happening to `<a>` element.
Related to bug 255812
I made a test page: https://cdpn.io/aardrian/debug/PoXVWpv * Text field requires additional series of interactions. * Select menu announces accDesc preceded by "description". * Checkbox announces accDesc preceded by "description". * Radio button announces accDesc preceded by "description". * Text area requires additional series of interactions. * Button announces accDesc preceded by "description". * Video offers nothing (Chrome/JAWS and Firefox/NVDA do not expose it). * Details/summary announces accDesc preceded by "description". * Date input offers nothing (Chrome/JAWS and Firefox/NVDA expose it). * Reset input announces accDesc preceded by "description". * Submit input announces accDesc preceded by "description". * Link requires additional series of interactions. These examples are not exhaustive.
I get the same behaviour in Ventura 13.6 in both Chrome and Safari: Chrome Version 117.0.5938.149 (Official Build) (arm64) Safari Version 17.0 (18616.1.27.111.22, 18616) However, it does not happen in Firefox 118.0.1 (64-bit).
Noting in this specific bug a potential culprit that Adrian called out in (260835): https://developer.apple.com/documentation/safari-release-notes/safari-17-release-notes - Fixed aria-describedby to be equivalent to aria-description and override it when both are present. (108386295)
While this bug is about Safari/VO on macOS, I realize I never included how this differs from Safari/VO on iPadOS. Using the example I made in my last comment, with Safari 17 / VO / iPadOS 17 each of my tests works (although the pre-pended "description" is noise IMO): * Text field announces accDesc preceded by "description". * Select menu announces accDesc preceded by "description". * Checkbox announces accDesc preceded by "description". * Radio button announces accDesc preceded by "description". * Text area announces accDesc preceded by "description". * Button announces accDesc preceded by "description". * Video announces accDesc preceded by "description". * Details/summary announces accDesc preceded by "description". * Date input announces accDesc preceded by "description". * Reset input announces accDesc preceded by "description". * Submit input announces accDesc preceded by "description". * Link announces accDesc preceded by "description". Given this and the Chrome behavior as reported by Vegard, I am more confident this is an AAPI mapping issue related to AXCustomContent, AXHelp, and/or AXCustomContentImportanceHigh. I look forward to finding out what the culprit is because it is fun for me to be wrong publicly.
Also, do we need "description" this just adds verbosity. I can't find a way to turn that off.
Created attachment 468227 [details] Safari 17 navigating a button and link via read-all, tabbing, and using virtual cursor, to expose the accessible description. I made a video to compare the difference in accDesc exposure between buttons and links. The behavior demonstrated with the link is similar to how it behaves with a text field (and other fields I cited). This is for devs visiting the issue who are not Mac users but who have heard about this and don't understand quite what it means.
> Given this and the Chrome behavior as reported by Vegard, I am more confident this is an AAPI mapping issue [...] I look forward to finding out what the culprit is because it is fun for me to be wrong publicly. ;) Not an AAPI mapping issue. The iOS behavior is intended, but the team is considering the concern you raised about "description" being overly verbose. The Mac VoiceOver behavior is intended to be amended to match the intended API. The Mac VO team is aware of the discrepancy. IIRC, Chrome works b/c Aaron rolled back the API change in Chrome awaiting the Mac VO change. Thanks for the detailed bug report.
I can confirm it is fun for me to be wrong publicly. > The iOS behavior is intended, but the team is considering the concern you raised about "description" being overly verbose. Is there any insight into why that was added? User request? Testing outcomes? Accidental? > IIRC, Chrome works b/c Aaron rolled back the API change in Chrome awaiting the Mac VO change. Crap. I even knew that was in there but didn't know that's why it went away. Thanks for the corrections.
> Is there any insight into [the reason VO speaks "description"]? It's the localized user string label for the type of custom content, in the same way you could have a "flower" label for custom content in a plant nursery app. WebKit sends the localized label "description" and value ("e.g. the attribute values or sub-DOM contents contributing to the description") as per the API. https://developer.apple.com/documentation/accessibility/axcustomcontent
In other words, it's a user-presented string, used for the rotor label.
Animated thumbs-up emoji. That is useful, but does not tell me why it was added/changed from existing behavior, just how it maps and is exposed.
> That is useful, but does not tell me why it was added/changed from existing behavior, just how it maps and is exposed. Ah, you want the long version... When will we next be in the same zip code? This is tied to a fundamental UI difference between screen readers and platforms. IMO, SR UI differences are broader than most sighted people realize... Using Mac/Windows/XWindows(Linux) as a metaphor, the main details of sighted GUI interaction patterns stabilized in the 1980s... App windows, menus, toolbars, have differences but if you have experience with one platform, the bones of the interface are similar on all, albeit with a bunch of little details that are different. Cmd vs Ctrl being one of many. On top of all those little differences in the OS details, the SRs are fundamentally different in too many ways to go into save one: Accessibility Extended Description (that is, not the name/label, and not the contents, but some other thing that is accessed on demand) was a Windows screen reader concept. VoiceOver has other concepts that NVDA/JAWS don't have, but aria-describedby (and more recently aria-description) was effectively a Windows API port into the Web Platform. WebKit used to expose this as the help text (also used for tooltips when the tooltips aren't used for name/label) but there were always edges cases like, what happens when two (or more) things from a Windows-concept-converted-to-Web need to squeeze into the same property in the macOS Accessibility API (AX API)... Then there are new mechanisms that came from ARIA where there was no AAM on any platform (IIRC, aria-errortext was one of these)... On top of that, SRs that ship on multiple platforms and across UI frameworks (like iOS VO on UIKit/SwiftUI/Web, and Mac VO on AppKit/SwiftUI/Web) should ideally be framework-neutral. As much as possible, the AT and API should work the same way whether the app view is native, web, etc. AXCustomContent is one of many API updates that allows more flexibility over time. So long story short: "why it […] changed" is because that it used to be exposed through a more rigid API, and WebKit now exposes it through the newer API.
Hi All, I just tested as of 11/3/2023: On <button> elements, it partially works. The aria-describedby announces, but then says "More content available" unnecessarily" On <input> fields, the aria-describdby does not work at all.
Adding my +1 to the view that the "description" prefix should not be announced. I think it adds unwarranted verbosity, and is essentially redundant. It's not necessarily even applicable, since accessible descriptions are not always used to describe content per se, they're often used to give interaction hints, like "To select items press Space". That hint is not really a description of the content, and to my mind, prefixing its announcement with "description" confuses its purpose. I've also observed that the prefix is still announced even if the description itself contains no speakable text. For example, if the element referenced by aria-describedby contains nothing but white-space characters, the "description" prefix is still spoken even though nothing comes after it.
+1 for removing the “description” announcement when announcing an items description content. It could be especially tedious for already-wordy announcements for things like toggle buttons, checkboxes, etc.
Aria-describedby is still broken. It's been broken since March 2023. About to be a year. This issue needs to be escalated.
Aria-describedby still not working for <input> type text as of March 11, 2024 ( Safari 17.3.1 on MacOS 14.3.1. This issue needs to be escalated. Just a clarification: aria-describedby is used for more than descriptions in rotor labels. It is also used for user-feedback in form validation, allowing VO/assistive technology users to pinpoint invalid inputs in a form. For example, if the input entered in a text field doesn't match a given criteria, we put error strings inside an aria-describedby target element related to the input field, so it can be announced promptly, an equivalent experience to sighted users. ## Initial state <input aria-label="First Name" type="text" aria-describedby="input_first_name_helper"> <div id="input_first_name_helper" aria-live="assertive"></div> ## Error state <input aria-label="First Name" type="text" aria-describedby="input_first_name_helper"> <div id="input_first_name_helper" aria-live="assertive">Error description placeholder</div>
The issue appears to be fixed? `aria-describedby` is reading out the text for me on Mac 14.4.1 and Safari 17.4.1, but I haven't found anything explicit in the patch notes. Can anyone confirm?
Yes using VoiceOver with Safari 17.4.1 on macOS 14.4.1, on Adrian's test page (https://cdpn.io/aardrian/debug/PoXVWpv), all the elements have their descriptions read after a slight pause except for the <video> element (virtual cursor moves to its Play button). No additional interactions are required and the word "description" does not preceed the descriptions. Using Read All on the page, the descriptions are included after the element names. On iOS 17.4.1, the word "description" still preceeds the descriptions. https://bugs.webkit.org/show_bug.cgi?id=262895#c9