Should getComputedAccessibleNode() take a node, instead of an element?

[aleventhal]

1. An AX tree can contain accessible nodes that are backed by the document, or a text node, neither of which are elements.
2. It's possible to reach one of these nodes via parent, firstChild, nextSibling, etc.
3. The explainer at https://wicg.github.io/aom/explainer.html is inconsistent, containing references both to getComputedAccessibleNode(node) and getComputedAccessibleNode(Element el)

I suggest that it should be possible to pass a node to getComputedAccessibleNode().

[aleventhal]

Assuming we do this, we need a special role string for text.
I don't think it should be possible to assign an element with a role of text via role="text", but should be possible to create a virtual node with a role of "text".

@asurkov WDYT?

[cookiecrook]

There's some baggage related to the "text" role, as previously implemented by WebKit, and then removed from the the spec drafts later. WebKit didn't remove support for the old role, but b/c of the baggage and webcompat issue, I'd prefer we avoid making an "text" role, regardless of whether it's abstract or concrete. cc @joanmarie

I also recall there was consensus to not work on the computed tree for the time being. Has that changed?

[asurkov]

I think either of ways is a livable thing:

• If we expose an accessible object for non element DOM nodes, like text node or document node, then it keeps us closer to DOM concepts, which makes it natural for web developers and provides a shallow learning curve. I suppose we could use text_leaf/static_text role or so for DOM text node accessibles (something from MSAA world which used to rely on text nodes) and also make it provide rendered text.
• On the other hand, accessibility APIs like IA2 were living just fine with no text accessibles by operating with hypertext/hyperlink concepts. Iirc NSAccessibility doesn't have accessible objects for text nodes either. So I suppose AOM could be designed that way as well. If AOM provided a text interface, then it'd be also an option. It certainly should be good for testing.

[aleventhal]

There's some baggage related to the "text" role, as previously implemented by WebKit, and then removed from the the spec drafts later. WebKit didn't remove support for the old role, but b/c of the baggage and webcompat issue, I'd prefer we avoid making an "text" role, regardless of whether it's abstract or concrete. cc @joanmarie

We could also have it have an undefined role, e.g. ax_node.role === undefined.

I also recall there was consensus to not work on the computed tree for the time being. Has that changed?

Probably not. I'm just trying to fix a crash that occurs in our current implementation, which is behind a flag. The crash occurs because nextSibling matches text nodes.

I'm not really too excited about this API unless there are consumers banging down our door for it.

If we don't want to change the IDL, I'm happy to find another solution.