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

Clarification of distinctions between "contains" and "owned by" concerning roles of list/listitem and associationlist/associationlistitemkey/associationlistitemvalue. #2007

Open
giacomo-petri opened this issue Aug 18, 2023 · 9 comments
Assignees
Labels
clarification clarifying or correcting language that is either confusing, misleading or under-specified Role Content Model
Milestone

Comments

@giacomo-petri
Copy link
Contributor

Question:
In relation to element roles such as, though not exclusively, "list/listitem," "grid/row/gridcell," and "table/row/cell," the specifications state:

Authors MUST ensure elements with role $child_role are contained in, or owned by, an element with the role $parent_role.

However, this rule does not hold true for the triad "associationlist/associationlistitemkey/associationlistitemvalue." Is there a specific rationale behind the acceptance of only the "contained in" relationship, rather than incorporating the "owned by" relationship (potentially using aria-owns)?
I acknowledge the intricate nature of relationships that hinge on the sequence of elements, yet this also pertains to table/grid structures.


WAI-ARIA version:
https://w3c.github.io/aria


Link to documentation:

@spectranaut
Copy link
Contributor

Crazy timing @giacomo-petri -- I think I just opened a PR that resolves your concerns, can you look at: #2010

@spectranaut
Copy link
Contributor

spectranaut commented Aug 24, 2023

I think I wrote too soon, actually, I see my PR might not totally resolve your concerns, but, we have been working on the confusing language related to required relationships between elements with certain roles. I think the requirements for associationlist and the other roles you mentioned are the same, but the language was perhaps not clear. "associationlist" does have the "required accessibility children" just like list and the other roles you mentioned, can you review the section of "required accessibility children" and the definition for "accessibility children", and let me know if your concern remains? Or let me know if I misunderstood your concern.

@giacomo-petri
Copy link
Contributor Author

Absolutely, I see the point.

The clarification provided by the definition of "accessibility children" addresses my concern, and the newly proposed #2010 amendment certainly brings clarity to the matter.

However, I do have a reservation regarding the statement concerning the "associationlistitemkey" role. This statement reads:

A single key item in an association list.

Author requirements for elements whose role is associationlistitemkey:

and in particular, it specifically states:

MUST be contained in an element whose role is associationlist.

Contrastingly, for other roles such as the "listitem" role, the specification reads:

Authors MUST ensure elements whose role is listitem are contained in, or owned by, an element whose role is list.

Considering the consistency introduced by your new pull request (#2010), I would suggest applying this new terminology to the "associationlistitemkey" and "associationlistitemvalue" roles as well:

<p>Authors MUST ensure [=elements=] whose <a>role</a> is <code>associationlistitemkey</code> are <a>accessibility children</a> of an <a>element</a> whose <a>role</a> is <rref>associationlist</rref>.</p>

This applies to associationlist and associationlistitemvalue roles as well (of course using appropriate relationship terminology).

This would ensure uniformity and alignment with the evolving standards introduced by PR #2010.

@pkra
Copy link
Member

pkra commented Aug 29, 2023

I like the suggested clarification. I expect we have a lot of opportunities to clarify things like this after #2010 lands.

@pkra
Copy link
Member

pkra commented Aug 29, 2023

@giacomo-petri might you be willing to make a PR after #2010 lands?

@giacomo-petri
Copy link
Contributor Author

Absolutely

@pkra pkra added the clarification clarifying or correcting language that is either confusing, misleading or under-specified label Aug 29, 2023
@pkra pkra added this to the ARIA 1.3 milestone Aug 29, 2023
@scottaohara
Copy link
Member

tagging this as role content model - though maybe it's only tangentially related?

@giacomo-petri
Copy link
Contributor Author

I missed it because it wasn't assigned to me. Now that it is, I'll handle it! 😄

@giacomo-petri giacomo-petri self-assigned this Jun 7, 2024
@giacomo-petri
Copy link
Contributor Author

giacomo-petri commented Jun 7, 2024

With this commit, the roles associationlist, associationlistitemkey, and associationlistitemvalue have been removed from the specifications.

All other "owned by" and "contained in" relationships have been appropriately updated to the new "accessibility children" and "accessibility parent" terminology, except for the role caption.

The current specification states:

...

  • The caption is the first non-generic descendant of a grid, group, radiogroup, table, or treegrid.
    ...

This translates to "The caption is the first accessibility child of a grid, group, radiogroup, table, or treegrid." However, the existing wording is very clear, and we might want to consider retaining it as is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification clarifying or correcting language that is either confusing, misleading or under-specified Role Content Model
Projects
None yet
Development

No branches or pull requests

4 participants