AX: Re-implement aria-owns to reorder the accessibility tree (spec was changed to match Gecko and the more recent implementation of Chromium)

• Component: Accessibility
• Status: NEW ---

[Ben Cronin]

Created attachment 424352 [details]
Repro case for readout for DOM-structured list vs. aria-owned list

NOTE: This is a possible duplicate of https://bugs.webkit.org/show_bug.cgi?id=151498, but I wanted to emphasize the fact that there seems to be a broader problem with `aria-owns`.

For example, I would expect these two structures to be treated the same (also see attached html file for a slightly more detailed example).

(1) List with item as DOM child:

<ul>
  <li>List item</li>
</ul>

(2) List with aria-owned item:

<li id="list-item">List item</li>
<ul aria-owns="list-item"/>

In case (1), when navigating to the list item, I initially hear "list one item" to indicate that the item belongs to a list (and from there I can navigate into the actual list item).

In case (2), I just hear "bullet List item," with no mention that the item should semantically be treated as part of a list.

I believe the two cases should behave the same, which is how it works in Chrome (I tested Safari 14 vs. Chrome 89, but the discrepancy has been present in past versions as well). It also seems this is not confined to lists/list items (i.e., I have not heard any other aria-owns relationships communicated by VoiceOver in Safari, either).

Reference: https://www.w3.org/TR/2017/REC-wai-aria-1.1-20171214/#aria-owns

[Radar WebKit Bug Importer]

<rdar://problem/75885927>

[Scott]

+1 requesting the aria-owns attribute be implemented by Webkit.  

This feature would be quite important in the construction of tab widgets that change to accordion patterns at different viewports.  Without aria-owns, which would allow for a single markup pattern to be used, the DOM would have to be updated to meet the expectations for each pattern.  For instance, https://tabpanelwidget.com uses aria-owns correctly to associate the tabs with the tablist.  

There are many other examples I've come across recently where support for aria-owns would improve the accessibility for users of Webkit+VoiceOver, but presently the best advice to give them is to use another browser.

[Thierry]

Waiting for this issue to be fixed so we can put https://tabpanelwidget.com/ back online.

[Brennan Young]

+1 request for a fix.

I bring a new use case, so far unmentioned.
There is currently no support for PDF/UA tags in webkit browsers.

PDF.js (which renders PDF files in a canvas) relies on aria-owns to construct an accessibility tree based on PDF/UA tags. https://github.com/mozilla/pdf.js

This issue with aria-owns prevents PDF.js from being a viable workaround.

Those who intend to present tagged PDF via VoiceOver, must currently do so via a non-webkit browser.

[James Craig]

possibly forward dupe to bug 241694

[Sommer Panage]

Dupe seems accurate - we're encountering this in our Quip (now part of Slack) lists; prevents Quip from being able to communicate list structure in view-only mode.

[chris fleizach]

*** Bug 241694 has been marked as a duplicate of this bug. ***

[James Craig]

Since WebKit bug 241694 was duped to this one, I want to make sure the useful bits of that thread aren't lost in the duping... In particular:

Aaron wrote up a doc describing how Blink implements aria-owns:
https://docs.google.com/document/d/1jhztcbvUWS4_QGtKmWMxVBLnMkl5ZAAqRCVTcLfdl4o/edit#

James Teh from Mozilla mentioned that he thinks Blink handles more of the obscure problematic cases. Blink engineers spent a fair amount of time on them, so hopefully the above document will save you some of the pain we experienced.

Above doc covers a lot of the edge case questions discussed in WebKit bug 241694 and <rdar://95314618>

[James Craig]

ARIA Chairs are asking for a status update or estimate on this one, if you have it.