Mismatch between acessibility tree inclusion criteria and implementations

[Epigenetic]

Describe your concern

The criteria for tree inclusion indicates that only elements with explicit roles (and maybe explicit WAI-ARIA attributes? language is a bit ambiguous here) are included in the accessibility tree. However, this does not seem true (or desirable) in practice. For example in Chrome and Firefox, button elements are always exposed with their implicit role if no role is set. The only other criterion here that would seem like it would apply is that focused elements are exposed, but again both browsers expose the element without focus being on it. But, in Chrome, not all elements with implicit roles are exposed, for example divs with no roles are not exposed in the tree, whereas in Firefox, such elements seem to always be exposed.

Link to the version of the specification or documentation you were looking at at.

Link to documentation: https://www.w3.org/TR/wai-aria-1.2/#tree_inclusion

Does the issue exists in the editors draft (the editors draft is the most recent draft of the specification)?
Yes

[JAWS-test]

Probably the sentence should say: explicit or implicit role

[cookiecrook]

@Epigenetic wrote:

The criteria for tree inclusion indicates that only elements with explicit roles […] are included in the accessibility tree.

I don't think the above statement is accurate.

The requirement is that "user agents must provide an accessible object […] for DOM elements that meet any of the following criteria:" There are more criteria than the one bullet listed in this issue, and there is nothing stating that UAs must ONLY provide accessible representations for these specific elements. They are welcome to provide more, and they do, according to each host implementation mapping... HTML-AAM for example.

But, in Chrome, not all elements with implicit roles are exposed, for example divs with no roles are not exposed in the tree, whereas in Firefox, such elements seem to always be exposed.

This is open as an implementation detail for the time being. I suggest you follow web-platform-tests/interop#211 for more on accessibility-based interop testing.

@JAWS-test wrote:

Probably the sentence should say: explicit or implicit role

I think the other use cases that MUST be exposed are already covered by the other bullets, and I would object to an addition that any implicit role MUST be exposed... Layout tables are a good examples of implicit roles that are not exposed by any implementation.

@Epigenetic If you think there is more that should be included in ARIA specifically, please re-open and clarify, ideally with a specific change suggestion.

[Epigenetic]

@cookiecrook Thanks for the detailed answer. Based on your response I think it would make sense to add to ARIA language indicating that this is not the complete or exclusive list of reasons. That could jut be saying something like "user agents MAY provide an accessible object in the accessibility tree for DOM elements for DOM elements if none of the above criteria are met" or listing the cases in which an element may be exposed. I'm not aware of a discrete list of such reasons, however, so I would lean to the first option from what I know currently.

It does not look like I have permissions to reopen the issue in the repository, so just replying for now.

[JAWS-test]

@cookiecrook

I think the other use cases that MUST be exposed are already covered by the other bullets, and I would object to an addition that any implicit role MUST be exposed...

What about the HTML element <main>? It is supposed to be submitted to the API, but to my knowledge all the bullets in the list do not apply to <main>. This is true for many other HTML elements as well.

I think all implicit roles need to be transmitted. This is clearly covered in HTML AAM for HTML (https://www.w3.org/TR/html-aam-1.0/). Other markup languages have analogous rules (e.g. SVG).

And if we look in HTML AAM, we see that there are also quite a few elements that have no implicit role (i.e. no ARIA mapping), but are still submitted to the API, differently depending on the operating system

[cookiecrook]

What about the HTML element <main>?

As you later mentioned, HTML-AAM outlines the way browsers expose main and other HTML elements. So what’s the problem?

Among other things, that spec contains lots of HTML special cases about when the implicit roles should not be exposed. IMO, trying to duplicate that list of host language specific special cases in Core-AAM would be ill-advised. That’s why the other specs exist, yet even those are incomplete, as they don’t include explicit rules like whether a table is a data table. Those heuristic variations are, so far, left to the implementations.

[cookiecrook]

Reopening based on @Epigenetic’s last comment. WG should consider a MAY or a note that makes it clear: ~”these must be exposed, but that doesn’t mean they are the only elements that may be exposed.”

[JAWS-test]

As you later mentioned, HTML-AAM outlines the way browsers expose main and other HTML elements. So what’s the problem?

The problem is that the ARIA specification pretends that the other specifications do not exist, or even worse: what is regulated in the others is not valid, in that the ARIA specification says at this point, that only elements with an explicit role are passed to the API. At least the misunderstanding can arise, since it is not clear whether the explanations only refer to ARIA or also to other markup languages ​​(such as HTML and SVG). A clear formulation should therefore be found without having to mention the rules of HTML and SVG - it is sufficient if it is mentioned that the other languages ​​have their own rules that also apply.