as mentioned during triage - this is a symptom of a larger problem, that there is an assumption that if roles are not identified as "allowed" or "required" by the ARIA spec - that therefore anything else must be invalid. And this is an example of that over simplification.

So, what we really need to think about is do we need to define content models for the different roles (similar to HTML element's content models). Or do we need to identify specifical "not allowed" roles/elements for specific roles - where if a role is not listed, then it should be considered "allowed".

or: [ insert other idea(s) here ]

linking #2101

though that's titled 'parsing', but this isn't about parsing (if we're thinking HTML parser) but again the allowed content models for roles that wouldn't potentially need to have UA repairs or just 'broken' / 'awkward' experiences if authors did not follow the potential content models

In case we define ARIA roles for existing HTML elements, I think we should respect HTML content models for child elements - roles.

If we define NEW roles in order to extend the semantics, roles that are not doubles for HTML elements, then the question is more complicated. What should we do in these cases?

Minutes from today's meeting: https://www.w3.org/2024/06/13-aria-minutes.html#t08