Are the tree examples using groups wrong?

[WilcoFiers]

The navigation treeview and file directory treeview examples put the group role of the nested control inside the treeitem. Looking at the ARIA spec, especially the editors draft which is now clearer with its required parent roles, this looks incorrect to me. I think groups need to be siblings to the item the expand into, not descendants, just like they do on menus:

// How APG does trees, this seems invalid ARIA:
tree > treeitem > group > treeitem > group > treeitem

// What I think ARIA 1.3 editors draft requires:
tree > group > group > treeitem

// how APG groups menus
menu > group > group > menuitem 

[WilcoFiers]

My apologies. I think I might have gotten this wrong? The editors draft says that tree is allowed treeitem or group > treeitem as children, which suggests groups can be in trees. And then treeitem says its parent has to be tree or treeitem > group which suggests treeitem can not be in a group that's a direct child of a tree.

[mcking65]

The treeitem role says:

A treeitem element can contain a sub-level group of elements that can be expanded or collapsed. An expandable collection of treeitem elements are enclosed in an element with the group role.

Authors MUST ensure elements with role treeitem are accessibility children of an element with role tree or an element with role group that is the accessibility child of an element with role treeitem.

I believe the spec is confusing because the tree role definition in the editor's draft does allow for group as a child of tree. I think that is an error. I am fairly sure there isn't a use case for group as an accessibility child of tree. I explained in this comment on ARIA 2014 and submitted w3c/aria#2094 to resolve the issue.

[mcking65]

@WilcoFiers OK to close this?