Hierarchy of treeitems per aria level only?

[JAWS-test]

Description of bug or feature request

treeitem:

An expandable collection of treeitem elements are enclosed in an element with the group role.

In this case, the hierarchy of the treeitems results from the hierarchy of the groups.

In addition, aria-level can be used with the treeitem.

Two problems arise from this:

• What if the hierarchy of the groups contradicts with the hierarchy in aria-level. Which hierarchy wins? This is only explained in Core AAM, but a corresponding reference in the ARIA specification is missing.
• Why should groups be used when aria-level is used. Wouldn't it be sufficient to omit group if aria-level is used?

My suggestion:

The hierarchy of treeitems is mapped either via proper nesting in groups (role=group) or via aria-level.

Will this require a change to CORE-AAM?

I do not think so

Will this require a change to the ARIA authoring guide?

Not necessarily, but the aria-level example could be modified to remove the hierarchy by group

[MarioBatusic]

I don't really undestand the conflict. If you put an

aria-level** on an

treeitem

element, you can simply change the implicit level given by the natural group depth. The group role in ARIA 1.3 definition is not allowed itself to use aria-level.

[JAWS-test]

@MarioBatusic

The ARIA specification does not state that there are 2 methods to specify the hierarchy: with aria-level and with group. This is important for tree structures.

Furthermore, the ARIA specification always requires the use of group, even if aria-level is available. I think this is unnecessary.

[JAWS-test]

Discussed at https://www.w3.org/2023/10/19-aria-minutes.html#t01

[spectranaut]

Discussed in today's ARIA WG meeting: https://www.w3.org/2023/11/30-aria-minutes.html#t08