"ARIA required context role" (ff89c9): resolve TF feedback

[Jym77]

As per w3c/wcag-act#507
This mostly inlines our definition of "owned by" into "child in the accessibility tree" to avoid the confusion with the ARIA definition. Notes are added to the background to explain a bit the reasoning behind that choice.

Note that the definition is contested inside ARIA: w3c/aria#748 which is a good reason to not use it 😀

Closes issue(s):

• N/A

Need for Final Call:
This will require a 1 week Final Call (technically only editorial, but changes structure quite a bit)

---

Pull Request Etiquette

When creating PR:

• Make sure you're requesting to pull a branch (right side) to the develop branch (left side).
• Make sure you do not remove the "How to Review and Approve" section in your pull request description

After creating PR:

• Add yourself (and co-authors) as "Assignees" for PR.
• Add label to indicate if it's a Rule, Definition or Chore.
• Link the PR to any issue it solves. This will be done automatically by referencing the issue at the top of this comment in the indicated place.
• Optionally request feedback from anyone in particular by assigning them as "Reviewers".

When merging a PR:

• Close any issue that the PR resolves. This will happen automatically upon merging if the PR was correctly linked to the issue, e.g. by referencing the issue at the top of this comment.

How to Review And Approve

• Go to the “Files changed” tab
• Here you will have the option to leave comments on different lines.
• Once the review is completed, find the “Review changes” button in the top right, select “Approve” (if you are really confident in the rule) or "Request changes" and click “Submit review”.
• Make sure to also review the proposed Final Call period. In case of disagreement, the longer period wins.

[ajanec01]

Description for passed example 3 seems incorrect to me. Happy to approve otherwise.

Changes accepted.

[ajanec01]

Shouldn't we delete the sentence where we are saying that this rule mimics the HTML content model? Asking because the definition of the content model is suggesting that it's both children and descendants of the element/ test target.

It's contradictory to the beginning of the paragraph where we insist that this rule is restricted to direct parent-child relation.

[carlosapaduarte]

I agree with Aron's suggestion

[WilcoFiers]

I can go either way on this.

[Jym77]

Actually, it depends where we look 🤯
The link used here indeed says

A normative description of what content must be included as children and descendants of the element.

but a couple of line below we have 3.2.5 Content models stating

Each element defined in this specification has a content model: a description of the element's expected contents. An HTML element must have contents that match the requirements described in the element's content model. The contents of an element are its children in the DOM.

🤷

---

As far as I remember, HTML content model only refers to children, not further descendants (despite what the def says).

---

Additionally, the idea is not just to consider a single level in the tree (e.g., the rule allows the table > rowgroup > row chain which is 2 levels) but more than the chain have to be considered between parent/children and not ancestors/descendant.

Using the ARIA def of "owned element", something like table > rowgroup > navigation > row would be allowed because the row is "owned by" the rowgroup (as a descendant) but is not a "child in the accessiblity tree".

So the difference is not about only looking at children, but about looking one step at a time and not skipping any.

The reason why we do this stepwise checks (disregarding ARIA specs) is that the content model is doing likewise. That is <table><tbody><nav><tr> is not OK because <nav> is not allowed in a <tbody>. The content model is only looking one step at a time, and individual elements' content model only mention children, but builds up a model that restrict descendants further away.

Essentially, performing the same checks on implicit roles (only) should flag violations of the content model (not all of them, but some of them).

---

So, this is what I was trying to say there…

• We stray away from ARIA def.
• We do so because we take inspiration from content model.

I'm afraid that keeping only the first part (the action) without the second (its justification) could lead to much confusion ("why are you not following ARIA specs?")

Not sure how to rephrase it to convey that information… I'll let it simmer a bit in case any of you has a brillant idea 😁
Easy fix might just be to switch the link and use the other one that does not mention descendants…

[carlosapaduarte]

I understand, and agre, with your reasoning.
Unfortunately, I don't have a better idea than what you suggested (i.e. change the link target).

[carlosapaduarte]

I agree with Aron's suggestion

[WilcoFiers]

I agree with much of what Carlos has said.

[WilcoFiers]

I can go either way on this.

Further discussion

[Jym77]

Call for review ends on June 17th.

[Jym77]

Call for review has ended. Merging.