Accessibility Parent/Child follow ups

[smhigley]

Follow up from F2F meeting discussion: https://www.w3.org/2023/05/04-aria-minutes#t01

1. Add clarification on "intervening" or revisit the word
2. Editorial: turn definition into bulleted list
3. Editorial: add note that accessibility child/parent is not the same as the browser/platform accessibility tree parent/child
4. Figure out where examples should go relative to the definition (i.e. that the definition would benefit by being adjacent to HTML example snippets)
5. Add "Accessibility descendant" definition & use in place of unclear use of descendant (Unclear use of the term "descendant" #1150)
6. Review/remove remaining use of owned/owning elements (Inconsistent use of "owned by" #1161)
7. Follow up on Clarify the implications and limitations of aria-owns #1817

[spectranaut]

two more:

8. I think also in the definition of "accessibility parent" we should make clear it is an "exclusive or". That is sort of over lapping with Clarify the implications and limitations of aria-owns #1817 like you said in the F2F @smhigley, but I still think that the fact that "child" is all of the things and "parent" is one thing should be made clear.
9. @cyns mentioned that we might need to think about shadow doms in our definition of accessibility parent/child or other relational terms. Here is a modification that was made to accname for this purpose: Add steps for shadow roots and slots accname#167

[spectranaut]

Also I'm going to take a stab at 5. accessibility parent, because that will unblock 6.!

But the rest of these are up for grabs. Are there any in particular you wanted to work on, Sarah, or should we add the agenda tag and try to recruit someone new to pick up some of these tasks?