If the current statement were not there there would be impact on the following role

• combobox would also allow searchbox, treegrid and alertdialog as children
• list,menu,menubar, tree would also allow intemediate nodes of anything which is a subclass of group (row,toolbar,select(abstract) and by extension all form fields which subclass select)
• listbox would allow treeitem children
• radiogroup would allow menuitemradio children

My conclusion for this is that we cannot allow subclasses to fulfill the required owned element requirement.

A further thought is that perhaps we could allow subclass children to fulfill required owned element requirement iff they ONLY subclass a single role.
If this were the rule then the only impacts would be the following

• combobox would also allow searchbox children
• list,menu,menubar, tree would also allow intemediate nodes of toolbar

So we could potentially resolve this issue by modifying the inheritance for toolbar and searchbox AND modify the note to allow subclass roles to fulfill the requirement so long as they only subclass a single role.

If I understand you correctly, I don't think this is a good idea.

1. We periodically mess with the subclasses. What if we make this change and then decide to add multiple inheritance to a particular role? By side effect, we'd be changing the valid required owned elements. This seems potentially breaky.

2. It also seems potentially hacky. Let's say that, for some reason which has nothing to do with the problem at hand, we decide that treeitem should no longer subclass option. Now it only (immediately) subclasses a single role. Wouldn't that make treeitem a valid owned element for list??

3. It also strikes me as a bit confusing. What's so special about only having a single (immediate) superclass?

1. Yep
2. Yep
3. Single superclass seems like it should map to a very similar platform role. Multiple superclasses makes that much less likely. But Yep - agree it is confusing.

I'm just really trying to look at all the possible options we have on the table. Happy to reject any of them.

I'm just really trying to look at all the possible options we have on the table.

For the sake of completeness, here are a couple other options:

• allow subclass children only if they're defined in extension specs
• define a new kind of relationship in 5.1 "Relationships Between Concepts", for instance a "specialized subclass role", which would represent the roles that are subclasses and could be used wherever their superclass is allowed.

My take:

• I don't like the first option, as it's not super resilient and kinda introduce a dependence on spec editing and organization (what if some extension roles become integrated in the core spec at some point?).
• the second option w/b worth being further explored.

@rdeltour this topic came up on the last telco, see https://www.w3.org/2019/10/03-aria-minutes.html#item06

This issue was discussed in a meeting.

• No actions or resolutions