Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prohibit presentation / none on where it causes conflict resolution #1494

Merged
merged 2 commits into from
May 2, 2024

Conversation

WilcoFiers
Copy link
Contributor

@WilcoFiers WilcoFiers commented Jun 1, 2021

Related to #1288


Preview | Diff


Preview | Diff

@joanmarie
Copy link
Contributor

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?

@WilcoFiers
Copy link
Contributor Author

@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?

@joanmarie
Copy link
Contributor

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? 😁

@WilcoFiers
Copy link
Contributor Author

@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.

@jnurthen jnurthen requested a review from scottaohara July 1, 2021 17:38
@jnurthen jnurthen added this to the ARIA 1.3 milestone Aug 19, 2021
@jnurthen jnurthen removed the request for review from scottaohara August 19, 2021 17:43
@pkra pkra added the Agenda label Apr 29, 2022
@scottaohara scottaohara self-requested a review May 5, 2022 17:47
@jnurthen jnurthen self-requested a review May 5, 2022 17:47
@jnurthen jnurthen added clarification clarifying or correcting language that is either confusing, misleading or under-specified and removed Agenda labels Aug 2, 2022
index.html Outdated Show resolved Hide resolved
@spectranaut
Copy link
Contributor

Follow up issue: #2126

@spectranaut
Copy link
Contributor

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

@pkra
Copy link
Member

pkra commented Feb 23, 2024

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

Copy link
Contributor

@MelSumner MelSumner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm suggesting the language change included in one of Joanie's comments, but I don't think it's a blocker.

index.html Show resolved Hide resolved
@jnurthen jnurthen merged commit 9eac4d9 into w3c:main May 2, 2024
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Agenda-Editors clarification clarifying or correcting language that is either confusing, misleading or under-specified
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants