<summary> elements within <details> elements are not included in VoiceOver's Form Controls web rotor. VoiceOver's "Find the next control" command, VO-Command-J, also doesn't find <summary> elements. Example: https://cdpn.io/pen/debug/LYqYRMx I can reproduce the problem in Safari 17.0 and Technology Preview 181, on macOS 14.0 and 13.6. I can also reproduce the problem in Safari 16.5 on macOS 12.6 and in Safari on iOS 17.0.3 (if Form Controls is chosen in its web rotor, swiping down doesn't focus <summary> elements).
<rdar://problem/117308226>
Created attachment 468299 [details] Patch
Committed 269643@main (c69c97c046fd): <https://commits.webkit.org/269643@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 468299 [details].
I can still reproduce this problem in 269643@main. However, I can't reproduce the other bug I filed (https://bugs.webkit.org/show_bug.cgi?id=263498) using 269643@main.
(In reply to Curtis Wilcox from comment #4) > I can still reproduce this problem in 269643@main. > > However, I can't reproduce the other bug I filed > (https://bugs.webkit.org/show_bug.cgi?id=263498) using 269643@main. Hey Curtis. What about after https://commits.webkit.org/269688@main / https://bugs.webkit.org/show_bug.cgi?id=263534? With that change, I see summary elements in the Form Controls rotor, and can navigate between them with VO-Command-J. Regarding https://bugs.webkit.org/show_bug.cgi?id=263498. I need to investigate some more, but I think what's happening is that when the open attribute is toggled, the summary (and / or details) is rapidly removed and re-added from the WebKit AX tree due to some equivalent change in the DOM, which interrupts VoiceOver's announcement. WebKit might need to be smarter and try to prevent the platform AX object from being destroyed and re-created, instead swapping out the underlying core accessibility object. But again, would need to dig deeper to be sure. In any case, I think the behavior will be flakey depending on timing until we do something to address it.
I tried builds 269688@main and 269781@main and could reproduce the problem in both.
BTW, this is actually a dup of https://bugs.webkit.org/show_bug.cgi?id=211284
*** Bug 211284 has been marked as a duplicate of this bug. ***