Thanks for doing this!

Some general thoughts:

1. I think that anything we want authors to be aware of shouldn't be down in the conflict resolution section; it should be with the associated state/property/role.
2. Anything we want authors to do should not require reading the conflict resolution section. I had to read it yesterday for a different issue. It's rather cumbersome content in parts.
3. I'm curious as to why you decided to prohibit the use of the role rather than prohibit the use of properties on that role. If, for instance aria-label is prohibited on presentation/none, why not also prohibit aria-description?

@joanmarie I'll look into moving the requirement to a different place. Would you prefer putting it in the description of the presentation role? I wanted to keep it close to the list of scenarios where presentation needs to get ignored. There is no name for this list of items that cause conflict, making it difficult to reference. Do you have any suggestions on how best to do this?

As for why I'm suggesting to prohibit the role. The way I figure it, the ARIA spec can only prohibit using things that are in ARIA. It seems strange for ARIA to have a requirement that says authors must ensure elements with a presentation role are not focusable or otherwise interactive. I don't think we can even guarantee that's always possible. Is there some way to put role=none on a summary element and have it not cause conflict?

Note that my replies are as me as an individual; I think the WG should discuss/review your PR as others might disagree with me and like your PR as-is. In the meantime, my answers:

@joanmarie I'll look into moving the requirement to a different place. Would you prefer putting it in the description of the presentation role?

Yes.

I wanted to keep it close to the list of scenarios where presentation needs to get ignored. There is no name for this list of items that cause conflict, making it difficult to reference. Do you have any suggestions on how best to do this?

I would argue that we don't even have a (concrete) list, let alone a named one. 🙂 We have three bullets which describe stuff. For instance, in the third bullet it mentions global states and properties trumping presentation. But it doesn't list those global states and properties. So authors need to then go find a list. I think we should have a list of specific properties we don't want authors to use on something where they have also used role="presentation". And I think we can do that via the characteristics table. See below.

That said, could you just tweak your existing language a tad, like:

"Authors MUST NOT use presentation and none on elements where users agents will ignore that role as described in Presentational Roles Conflict Resolution."

As for why I'm suggesting to prohibit the role. The way I figure it, the ARIA spec can only prohibit using things that are in ARIA.

Ohhhh. Yeah, that's a good point. 😃 Ok, what about a mixed approach:

1. In the characteristics table under presentation, move anything which would trump presentation from "Inherited States and Properties" to "Prohibited States and Properties". This would make it easier to find by authors and also not require them to figure out what is a global property.
2. In the description of presentation, maybe right above "For any element with a role of presentation and which is not focusable, the user agent MUST NOT expose the implicit native semantics of the element....", insert a new paragraph which states "Authors MUST NOT use presentation and none on an element which is focusable or otherwise interactive." (Wordsmith as you see fit.)

I'm not yet sure if we should consider doing something about the middle conflict-resolution bullet about required owned elements. But I'm leaning towards no. For instance, it's already an author error for an explicit listitem to not be inside a list.

It seems strange for ARIA to have a requirement that says authors must ensure elements with a presentation role are not focusable or otherwise interactive.

Does the mixed approach above address your concern?

I don't think we can even guarantee that's always possible. Is there some way to put role=none on a summary element and have it not cause conflict?

Is there a use case for that? Or is it merely a challenge? 😁

@joanmarie I've kind of been putting this off. It is rather daunting to make changes in this file. Adding in a line here or there I can manage, but I don't think I can make larger changes like what you're suggesting without it taking me half a day of work. If there's a better way to do this, please let me know. If not, I'd prefer to leave this up to someone who's comfortable working in this file.

Follow up issue: #2126

@Jaunita-George @MelSumner or @pkra, can one of you take a look so we can get this merged?

@spectranaut I had meant to talk about this at the (canceled) editors call this week since Joanie had suggested a lot of additional work.