AX: Consider re-implementing aria-owns to reorder the accessibility tree (to match Gecko and the more recent implementation of Chromium)

• Component: Accessibility
• Status: RESOLVED DUPLICATE

[James Craig]

AX: Consider re-implementing aria-owns to reorder the accessibility tree (to match Gecko and the more recent implementation of Chromium)

Currently in WebKit, aria-owns maps to AXOwns, and conveys that reference through the accessibility API. IIRC, this was the original expectation of the ARIA group in ~2010 when the aria-owns implementation occurred in WebKit/Chromium (before Chrome forked from WebKit in 2013).

Since that time, Gecko/Firefox) and Chromium have both changed their implementation so that aria-owns allows authors to remap the accessibility tree. 

IIRC, this aria-owns implementation change in Chromium also happened *after* another major architecture change in Chromium, to base the AX tree off the DOM tree (like Gecko) rather than off the Render Tree (like WebKit).

In recent discussions with the ARIA Working Group, it's clear there is wide support for allowing aria-owns to be used to reorder the browser accessibility tree, as well as some anecdotal evidence that some of the original authors intended it to be used this way (pre-2010). 

The ARIA Working Group is therefore seeking a WebKit investigation of the implementation feasibility of this mapping change in WebKit. Personally, I expect this to be possible, but a significant amount of work. We may also want to consider other changes to WebCore/Accessibility at the same time, such as matching the Chromium/Gecko behavior to base the Accessibility tree off the DOM tree.

[Radar WebKit Bug Importer]

<rdar://problem/95314618>

[James Craig]

Possible open question: 

Any "owned" elements would appear as a AX siblings to any DOM element descendants. I'm not sure the order; but I expect the "owned" elements would probably appended to the end of the DOM descendant list from the parent. This may be an open question, or it may be already addressed by an ARIA test case. 

Like this I think:

```
tablist aria-owns=tab3
 - dom tab1
 - dom tab2 

div id=tab3 
```

In other words, the div is not a dom descendant of tablist, but it is exposed as AX child of tablist, as an appended ax sibling of tab and tab2.

[James Craig]

Possible open question: I assume the original DOM location of the element should be removed from the AX tree, including all of that Owned element's descendant tree... Effecting cutting the branch off entirely and grafting it on in its new owned location. Is this correct?

[James Craig]

Possible open question: Is there an aria-owns mapping algorithm or wiki type list of expected behaviors for owns authoring errors like:

- looping (x owns y, y owns x)
- DOM ancestors owned by a descendant
- visible, rendered element owned by a hidden one
- etc. 

If this resource does not yet exist, perhaps it should.

[James Craig]

Aaron et al, would you expect reordering to work by adding an owned reference to an existing child node? effectively pulling out of the list and re-adding it?

```
tablist aria-owns=tab3 tab4 tab5
 - dom tab1
 - dom tab2 
 - dom tab5 

div id=tab3 
div id=tab4
```

or would this reverse the order?
```
tablist aria-owns=tab1 tab2 tab3
 - dom tab3
 - dom tab2 
 - dom tab1 
```

[Brennan Young]

Strong approval for making this happen. 

A possible side effect of basing the AX tree off the DOM tree will be that Webkit will have fewer quirks in relation to Gecko/Chromium. (Wishful thinking?).

I also assume that the original DOM location should be removed from the AX tree. I can't see any reason why the original location should be maintained, especially as the DOM reference will remain for cases that need it (e.g. CSS cascade).

Regarding the question of order/sequence. As an author, I would expect that aria-owns would cause the node to be appended to the end of the 'owner', and this would certainly be a viable mechanism for reordering (similar to appendChild in DOM). 

Not really sure how reordering might work otherwise.

The reverse order thing might have a use case that eludes me, but it seems counterintuitive.

[Aaron Leventhal]

I 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. It's true that we have spent a fair amount of time on them, so hopefully the above document will save you some of the pain we experienced.

[Aaron Leventhal]

Also, if the above doc does not answer some of the questions you have, please do comment in the doc and I will update it. Note that you can load up any html file in Chrome and view the AX tree via chrome://accessibility.

[chris fleizach]

*** This bug has been marked as a duplicate of bug 223798 ***