Description: iOS VO+Safari does not read <summary> role or state. Only the text within <summary></summary> is read with no indication of interactivity. Desktop VO+Safari works as expected. Frequency: Always, using multiple code samples. Steps to reproduce/Results: 1. Load any web page using <details><summary> including but not limited to https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_details 2. Swipe through the page until the cursor lands on the <summary> content 3. The text content is read, but no interactivity indication of “summary”(as desktop VO reads it) or “button” (as some other SRs read it), and no indication of “expanded”/“collapsed" Hardware/software used: Reproduced on an iPad (9th gen) running iOS 16.3.1 and an iPhone SE (2020) running iOS 16.4.1(a) Additional notes: • This issue is reflected in this 3rd-party testing grid https://a11ysupport.io/tests/tech__html__details-summary#sr-feature-index-2 • Partial workaround by adding role=“button” to <summary> does result in iOS reading the element as a button. However, also adding aria-expanded does not result in the state being read.
<rdar://problem/109684906>
Out of curiosity, just tested in iOS 15.7.3 on an iPhone SE with the same results, so not a regression issue it seems.
I'm experiencing this same details and summary issue with Safari/VO on my iOS 15 and 16 devices. From my own memories and the content of these articles, I'm pretty sure that the expanded/collapsed state _was_ announced in earlier versions of iOS (11 and 12): https://www.scottohara.me/blog/2018/09/03/details-and-summary.html https://www.hassellinclusion.com/blog/accessible-accordions-part-2-using-details-summary/ This is the only major browser and screen reader combo for which details/summary don't announce state properly (anymore), so it would be great to have this fixed. iOS has never announced (and still doesn't announce) the summary's default role, which would also be nice.
Created attachment 467495 [details] Patch
Comment on attachment 467495 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=467495&action=review > Tools/WebKitTestRunner/InjectedBundle/AccessibilityUIElement.cpp:97 > +bool AccessibilityUIElement::supportsAriaExpanded() const { return false; } this is not just Aria expanded right? maybe just rename to supportsExpanded
Comment on attachment 467495 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=467495&action=review >> Tools/WebKitTestRunner/InjectedBundle/AccessibilityUIElement.cpp:97 >> +bool AccessibilityUIElement::supportsAriaExpanded() const { return false; } > > this is not just Aria expanded right? maybe just rename to supportsExpanded I was initially doing it for consistency with our AX wrapper (which has the method accessibilitySupportsARIAExpanded), but you are right that this is more than aria. I will rename that!
(In reply to Joshua Hoffman from comment #6) > Comment on attachment 467495 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=467495&action=review > > >> Tools/WebKitTestRunner/InjectedBundle/AccessibilityUIElement.cpp:97 > >> +bool AccessibilityUIElement::supportsAriaExpanded() const { return false; } > > > > this is not just Aria expanded right? maybe just rename to supportsExpanded > > I was initially doing it for consistency with our AX wrapper (which has the > method accessibilitySupportsARIAExpanded), but you are right that this is > more than aria. I will rename that! Yea true, tough to change that one now, but I guess everything else can drop the ARIA
Created attachment 467496 [details] Patch
Committed 267635@main (2bd294b77186): <https://commits.webkit.org/267635@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 467496 [details].
*** Bug 260911 has been marked as a duplicate of this bug. ***