Accessor for AccessibleNode

[CountOrlok]

According to the spec, AccessibleNode is attached to the Node interface of the DOM, but I'm not sure if it's really a good idea to hook into this interface. I mean, wouldn't it be more appropriate to augment the Element interface instead?

The prose reads as follows:

The accessibleNode attribute returns the accessible node associated with this DOM node. It always returns a valid object if the browser supports the AOM.

It should be mentioned, that since nearly all types of objects defined in the DOM inherit from the Node interface, the accessibleNode attribute would be exposed not only to Element nodes, but also to Attribute or Text nodes, — just to name a few.

So consider the following code:

Node.prototype.accessibleNode = {type: 'AccessibleNode'};

const comment = document.createComment('text');

console.log(comment.accessibleNode.type);  // AccessibleNode

Because Comment nodes inherit from Node, the accessibleNode attribute can be addressed. The same applies to other objects, like Documents for example:

console.log(typeof document.accessibleNode); // object

Note, that in HTML, the document role is implicitly mapped to the body element.

The accessibility tree is no exact representation of the DOM it is derived from, that is, only a subset of objects which inherit from Node are actually represented by accessible objects.

Consequently, the AccessibleNode interface is designed to represent certain properties of an element that should be exposed to assistive technologies via the platform accessibility API.

So, provided that I didn't miss a crucial point here, I think it'd be better to add the accessibleNode attribute to Element instead of Node.

From #61:

We have chosen the name AccessibleNode for the class representing one node in the accessibility tree as exposed by the Accessibility Object Model, and accessibleNode as the accessor for the accessible node from a DOM element.

DOM element. ;-)

[minorninth]

Totally agreed about DOM Node -> Element. I think I addressed this in this PR, let me know if I missed anything:

https://github.com/WICG/aom/pull/61/files

[cookiecrook]

It was called AccessibleNode and extended Node b/c UAs need this on both element and text nodes, too. Not attrs though.

It might be possible to split AccessibleNode into separate AccessibleElement and AccessibleTextNode interfaces. Is that desirable?

[CountOrlok]

Well, when I wrote the original issue, I assumed that the current interface design would be more or less carved in stone, and under this premise, extending Element instead of Node for the accessor seemed the better approach. But that doesn't mean I consider the current solution to be optimal.

I think a better solution would be to first define a generic AccessibleNode interface:

interface AccessibleNode {
  // attributes and methods common to all accessible nodes
}

There'd be no need to hook into the DOM for this interface, since there are no raw nodes. Then, in a second step, we can define interfaces for specific node types. For now, elements and text nodes.

interface AccessibleElement : AccessibleNode {
  // attributes and methods specific to elements
}

interface AccessibleText : AccessibleNode {
  // attributes and methods specific to text nodes
}

These interfaces are accessed via attributes on their corresponding DOM interfaces:

partial interface Element {
  readonly attribute AccessibleElement accessibleElement;
}

partial interface Text {
  readonly attribute AccessibleText accessibleText;
}

This solution obviously resembles the structure of the DOM, but I think that's actually a good thing, since there is no need to reinvent the wheel and authors are used to work with that structure. In addition, by splitting interfaces the AOM becomes more modular, with all the positive effects associated with it.

[minorninth]

What's the purpose of AccessibleText? You can't set any accessibility properties on text nodes via ARIA, and it's not clear if it'd make sense to let authors set accessibility properties on them with the AOM anyway. Anything you'd want to achieve by doing so you could do instead just by changing its parent element.

The original reason to allow access to a Node's AccessibleNode was because the Node is part of the accessibility tree and it makes sense to be able to include those nodes when walking the computed tree.

But we decided now to make Element.accessibleNode only about modifying the accessibility tree for the DOM and creating virtual sub-trees, then in Phase 4 we'll add a separate async mechanism to explore the computed tree (which would include text nodes). So I don't see the need to do anything differently than what's in the spec now for phases 1 - 3.

[cookiecrook]

@minorninth wrote:

…in Phase 4 we'll add a separate async mechanism to explore the computed tree (which would include text nodes).

Okay.

[CountOrlok]

I don't see a current use case for AccessibleText either, and if no one else comes up with a reason why such a separate interface should be included, it should of cause be omitted.

Now, what I asked myself is whether we can rule out any future need for more than a single type of accessibility nodes, whether we can be sure that there will only ever be a mapping of DOM Elements to AOM Nodes.

If so, then there is no reason to change anything.

But suppose that sometime in the future there was a legitimate interest in adding a distinct interface, then it would probably be advantageous if the AccessibleNode interface was generic and not already used to represent Elements.

That's why I thought it would be better to delegate properties that could be used in other contexts, like the methods appendChild or removeChild which are intended to be used with Virtual Accessibility Nodes, to a generic AccessibleNode interface, from which AccessibleElement would inherit.

I felt like this solution would be more future proof, but of cause, my concerns could be unfounded.