Why is separator allowed between menuitem, but no other "item" roles?

[WilcoFiers]

We got a question on axe-core asking why separator wasn't allowed on between options of a listbox (dequelabs/axe-core#3938). I think the obvious answer there is it would throw the position count of the options off, as in if I had two options with a separator between them, option two would be treated as three of three.

There's a suggestion in aria-posinset that separators shouldn't be counted when they're part of a menu, which makes sense. Those aren't actual menu items. But then if you test how position counting works when posinset isn't used, screen readers do seem to count the separators. There's no difference that I've seen between how separators work between menuitems, and between options. I'm not sure there is any difference for other item-roles like listitem, treeitem, or tab either.

There doesn't seem to be a reason for having separators in menus, but not in other things. Which makes me wonder if either using separators between menuitems should either be deprecated, or if it should be allowed much more broadly.

[scottaohara]

@WilcoFiers as you may recall, I did provide some commentary / results on how injecting a separator into a list > listitems would behave - #1844 (comment)

but yes, generally agree that id' be nice to get into more detail on why menuitems with intervening separators are ok, but other list-esque groupings don't presently allow this, and if maybe they should (because then if they do allow it, inconsistencies or broken behavior could be fixed up, instead of blamed on invalid code).

[WilcoFiers]

HTML 5 has recently updated to allow hr elements inside select. Adrian wrote something up about that. It would make sense for ARIA to similarly allow separators inside listboxes, so that valid HTML stays valid ARIA.

[pkra]

Cf. also the (still ongoing) discussion in w3c/html-aam#504