Bug 266456
| Summary: | AX: Change to element's aria-describedby value doesn't update its announced description | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Darin Senneff <darin.senneff> |
| Component: | Accessibility | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | andresg_22, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 17 | ||
| Hardware: | iPhone / iPad | ||
| OS: | iOS 17 | ||
Darin Senneff
When using iOS Safari + VoiceOver (17.2): if an item has a description set via the 'aria-describedby' attribute, and then the value of 'aria-describedby' changes, the item's announced description doesn't update.
Steps to reproduce:
1. Visit test link in iOS Safari with VoiceOver: https://codepen.io/dsenneff/pen/xxMoReR/b0a1de7d369927086875385bbe2139cd?editors=1010
2. Navigate to the 'apple' button and hear the announcement: 'apple, description fruit'. Observe in devtools that the item's 'aria-describedby' value points to the 'fruit' element.
3. Activate the button, which swaps its 'aria-describedby' value. Observe in devtools that the item's 'aria-describedby' value does change to point to the 'vegetable' element.
4. Navigate away from the button, then back to it and hear the original announcement: 'apple, description fruit'
The button's announcement should change to reflect the updated description, 'apple, description vegetable', but it does not.
Other browser + screen reader combinations do update the element's description, including MacOS Safari + VoiceOver.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/119703619>
Darin Senneff
Issue still present in iOS 18's developer beta #2, despite the iOS 18 beta's release notes including the following text:
"Fixed updating 'aria-describedby' text after the targeted element changes its subtree."
-Source: https://webkit.org/blog/15443/news-from-wwdc24-webkit-in-safari-18-beta/#bug-fixes-and-more
Safari + VoiceOver's handling of accessible descriptions continues to be a huge support gap. Oftentimes, an accessible description is used to provide error or status messages, or instructions, which may change after initial page load. Being unable to rely on this consistently means developers can't reliably provide certain information to screen reader users in Safari browsers.