Inconsistent use of "group" role

[WilcoFiers]

I was working on dequelabs/axe-core#2897, when I fell down the group-role rabbit hole. It is pretty odd how in consistent it is, which makes using group unpredictable.

Would it be possible to get consistent rules on how and where group is used? The most recent draft clears up a few things with the "contained by" / "containing" wording, but there is still a fair bit of inconsistency in the use of group, which makes it difficult to use.

• list used to allow group. It was removed, because apparently list > group > listitem does not work. list > listitem > group > listitem does seem to work (according to Use of group within list is unclear #1011), and seems to work in the exact same way that group > treeitem works which is allowed.

• menu allows group as part of menu, but not as part of menuitem. That's the exact opposite of what you're supposed to do with group on tree.

• tablist and associationlist do not seem to allow group. Which is also fairly unintuitive, especially so since dl in HTML does allow grouping through the use of dl > div > dt/dd. If there's any role for which having a group makes sense its dl.

[scottaohara]

testing list > listitem > group > listitem, if that worked (and didn't just expose single "lists" due to the orphaned list items) it no longer appears to (firefox, chrome on windows with jaws)

re: grouping of dt/dd elements - 'yes' that is something the HTML spec allows with divs to allow for visual styling purposes. But that's not the same as allowing dl > group.

I don't have commentary on the other points, other than they're different widgets, so different allowances don't seem too out of left field to me? I rue the day I would want a group in a tablist though. :)

[WilcoFiers]

I'm sure there are reasons for each of them being different. Really what I'm asking is are those reasons good enough for each type of list to have a different relationship to the group role. I didn't know about this until last week, and I'm far better informed about the various quirks of ARIA then most devs are.

It seems a little risky to trust that every time someone sees fit to use group, to expect them to check the spec if they correctly remembered if the list they want to use it for allows it, and if so if it has to be in the item or in the list. It'd be good if someone could just learn that groups go in lists and can be wrapped around items, and if you want to nest things you need to reuse the list role inside an item.

[jnurthen]

@WilcoFiers assuming it can't be consistent due to the fact that it has to work differently in different contexts (which seems to be the case from the discussion) - how could we resolve this:

• more explanations and examples?
• having more specific roles for certain cases i.e. listgroup, treegroup etc (don't fixate on the names please)
• something else?

[WilcoFiers]

@jnurthen I thought I had figured it out and pretty much had posted to close the issue, then I looked a second time and now I think I'm even more confused than ever. Can you tell me which of these is/should be valid?

A. tree > group > treeitem
B. tree > treeitem > group > treeitem

If I look at the required children for tree it says that tree is allowed a group > treeitem as a child. That tells me A is valid, not sure about B. If I then look at the allowed parent role for treeitem it tells me that only tree or treeitem > group is allowed,. I.e. tree > group is not allowed. So B is valid and A is invalid.

Unless I'm misreading this, the required child roles for tree contradicts the required parent roles for treeitem. In APG option B is used for trees. But then option A is used for menu.

I think option A is the way every other group in ARIA works now. Grid, menu, table, listbox, etc. all have the group as a child of the container. None of them accept a group inside the item. I think the solution to this is to either prohibit, or to deprecate treeitem > group > treeitem, and to move this to tree > group > group ... > treeitem.

[JAWS-test]

Yes, the definitions in ARIA 1.3 for tree and treeitem contradict each other. In ARIA 1.2 it is still clear: only variant A is correct. However, I think that variant B should be correct - based on nested lists in HTML (<ul>, <li>).

[stes-acc]

Also, it should be explicitely clarified again why group role is prohibited (deprecated?) now in ARIA 1.2 as a child of list role. My devs absolutely don't get that. Concept-wise, it should be similar. And yes, I know that for role listbox, group is allowed as child for optgroup parity.

[WilcoFiers]

However, I think that variant B should be correct - based on nested lists in HTML (<ul>, <li>).

I don't think a nested list is the same as a group of items. If you needed to put a tree inside another tree for some reason, I think tree > treeitem > tree > treeitem would be a reasonable way to do it, just like with lists. That doesn't necessarily mean group needs to be inside the treeitem though. Every other use of a group puts it in the container, not the item. Doing that differently with treeitem seems unnecessarily confusing. Here's a full list of the current required parent roles that include some group. Treeitem Is really the odd one out here:

menu > group > menuitem
menubar > group > menuitem
menu > group > menuitemcheckbox
menubar > group > menuitemcheckbox
menu > group > menuitemradio
menubar > group > menuitemradio
listbox > group > option
grid > rowgroup > row
table > rowgroup > row
treegrid > rowgroup > row
tree > treeitem > group > treeitem

My big request here would be not to allow group as a child of treeitem, but to require it as a child of tree. There are definitely more things that can be done for consistency. Ideally all list-like roles would support both group and separator (including associationlist, list, tab). But if we could just get group to work the same in tree as it does everywhere else, that would be a big improvement.

[JAWS-test]

@WilcoFiers I don't care which path is taken. The important thing would be to eliminate the inconsistency. Please note, however, that in my opinion none of your examples can be compared with tree, because, for example, a group is not needed in a menu at all, but the nesting in the menu is done in a different way. In this respect, tree is a special case. Theoretically, tree could also work without a group (like menu, nested HTML lists or via aria-level)
But perhaps the solution should be to opt for what is already best supported by browsers and AT.