Consider accessibilityparent/accessibilitychildren in webdriver

[cookiecrook]

Breaking this one out from #3 and #6.

Even though most acknowledge accessibility tree synchronicity may not be achievable/desirable in the short term, I think most are in agreement that computed accessors like accessibilityparent and accessibilitychildren may be useful sooner b/c they would make the tree differences more apparent.

A few examples where I expect the DOM-first (Gecko) vs Render-first (WebKit) trees to be different are:

• interactive but mock object children like scrollbars in views with overflow:scroll;
• generated content like ::before and ::after psuedos, including implicit bullets on lists
• positioning containers or ancestry on absolutely positioned views, such as table headers on a "scrolling" table widget.
• more

having accessibilityparent and accessibilitychildren could allow us to catalog the differences and prioritize any potential alignment in future investigations or focus areas.

[cookiecrook]

Node may be a good return type, rather than Element... but what to return when the implementation contains an intermediate render object, like a scroll view in between an overflow:scroll; div and its DOM children? Do we need a different return type, or should the implementations normalize out those differences and promote the children of the intermediary render objects?

[cookiecrook]

Another idea that came up in discussion was a a new AccessibilityNode type, which would be accessed as a property of DOMNode, and could either be:

• null (if there was no backing accessibility node for the DOMNode),
• a container for all the other accessibility properties, including parent and children. (Think AOM Use Case 5)

[zcorpan]

A new type sounds reasonable to me. An AccessibilityNode instance can have a property pointing back to the element, or null if there's no element.

[gsnedders]

The design of this should happen in some other, chartered WG with an IPR policy.

[cookiecrook]

Yes, that discussion originally happened in the linked WICG incubator.

[cookiecrook]

As with #6, agenda should be to discuss which group should own what will likely result in some spec change... WICG AOM seems like the obvious starting point, even if potential changes end up in BTT WG WebDriver, WHATWG TestUtils, or some new ARIA WG deliverable.

[cookiecrook]

Group agreed to pass this over to AOM. I will file an issue there and then close.

[cookiecrook]

• Computing the Accessible Backing Node, or a similar test-only interface WICG/aom#197