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 about accessibility children definition (2nd exclusion point) #2021

Closed
giacomo-petri opened this issue Aug 30, 2023 · 4 comments · Fixed by #2027
Closed

Clarification about accessibility children definition (2nd exclusion point) #2021

giacomo-petri opened this issue Aug 30, 2023 · 4 comments · Fixed by #2027
Assignees
Milestone

Comments

@giacomo-petri
Copy link
Contributor

Concern description:

In the process of reviewing the definition of "accessibility children," I undertook a comparison with the definition of "accessibility parent". While the outlined points are consistent for both concepts, there are disparities in the exclusions.

The second exclusion for "accessibility children" is somewhat intricate to me. We define "accessibility children" as:

  • The DOM children of the element.
  • All DOM descendants of the element with only elements of role generic or none intervening.
  • All DOM elements specified via an aria-owns relationship to the element.
  • All DOM descendants of an element with role generic or none specified via aria-owns with only elements of role generic or none intervening.

However, we then proceed to exclude:

This exclusion seems partially in contrast with points #3 and #4 of the definition above. Consider the following example:

<div role="list">
  <div role="listitem" aria-hidden="true">Excluded element</div>
  <div role="listitem" id="reparented">Reparented element</div>
</div>
<div aria-owns="reparented" role="list"></div>

According to the current definition, and please correct me if I'm mistaken, we seem to assert that the reparented list item, which, in reality, is an accessibility child of the second list with aria-owns="reparented," is an exclusion and not considered an "accessibility child" of it.

In my view, a potential resolution could involve rewording the definition to provide a sequenced set of steps to determine what qualifies as an accessibility child. This would ensure that the aria-owns relationship takes precedence over the DOM structure. For instance:

  1. If the DOM element is referenced by an aria-owns attribute, then the element is an accessibility child of the owner element (I know I'm simplifying but it's just to propose an idea);
  2. Otherwise, if ...

Link to documentation:
https://w3c.github.io/aria/#dfn-accessibility-child

@pkra pkra added this to the ARIA 1.3 milestone Sep 2, 2023
@spectranaut
Copy link
Contributor

spectranaut commented Sep 4, 2023

Ah interesting @giacomo-petri -- we did at one point consider having an algorithm (to be honest I was for it and others were against it, originally..). However, it took a lot of work of the working group to agree with the definition as is, so I don't think it would be possible to do a whole re-write now. But lets see if we can make some smaller change to help with your point of confusion.

For the line you quoted:
| All DOM elements whose corresponding accessible object have been reparented in the accessibility tree via aria-owns

I see how the language is not quite specific enough. What we meant was excluding all DOM elements that have been reparented AWAY from the element for which you are trying to find all the "accessibility children". So you are right that it does not apply to the second list element in your example. This bullet only apply to the first list element, because one of the direct DOM descendants of the first list element have been reparented to the second list element. In the case of the second list element, no DOM descendants of that list have been reparented via aria-owns (trivially, because it has no DOM descendants).

Unfortunately, I'm struggling how to make this more clear in this bullet point without it getting overwhelmingly wordy. Do you have a suggestion for writing that one particular bullet to make it more clear?

Maybe it would be clear enough to update this example so that the last div is a listitem, and expand the sentence before to: "In the following example, the first list element has no accessibility children, where as the second list has one accessibility child, the listitem with role reparented".

@giacomo-petri
Copy link
Contributor Author

Maybe it would be clear enough to update this example so that the last div is a listitem, and expand the sentence before to: "In the following example, the first list element has no accessibility children, where as the second list has one accessibility child, the listitem with role reparented".

This will help a lot!

<div role="list">
  <div role="listitem" aria-hidden="true">Excluded element</div>
  <div role="listitem" id="reparented">Reparented element</div>
</div>
<div role="list" aria-owns="reparented"></div>


I want to avoid causing more harm than good, but it might also be worth considering a replacement for:

All DOM elements whose corresponding accessible object have been reparented in the accessibility tree via aria-owns.

with

All DOM elements whose corresponding accessible object have been reparented in the accessibility tree via aria-owns by an element that is not the accessibility parent.

Including "by an element that is not the accessibility parent" should provide consistency with the updated example above by excluding the element responsible for reparenting the specific DOM element.

Does it make sense?

I'm happy to open a PR if we decide to move forward with it.

@spectranaut
Copy link
Contributor

spectranaut commented Sep 5, 2023

Ok great! If you want to open a PR to update that example, that would be great.

As for the text:

All DOM elements whose corresponding accessible object have been reparented in the accessibility tree via aria-owns by an element that is not the accessibility parent.

Personally I do find "to an element that is not the accessibility parent" a bit unclear... because we haven't used "accessibility parent" in the definition above. And the new element is an accessibility parent. I was originally thinking of adding "on a different element" but that is also no clear, as we use "element" so many times in the definition above.

This is an example of a solution which I think is too wordy and would potentially make it hard to understand:

All DOM elements whose corresponding accessible object have been reparented in the accessibility tree via aria-owns on an element that is not the original DOM element or the original DOM element's generic DOM children.

But ideally, when reading the spec with fresh eyes, I don't think it makes sense to exclude literally everything in the "exclusion" section that you previously included in the second two bullets of the "inclusion" section, which was your original confusion, I think... So maybe it will be clear enough by the example alone?

@giacomo-petri
Copy link
Contributor Author

I apologise for not being clear enough.

In the context of the provided statement:

All DOM elements whose corresponding accessible object have been reparented in the accessibility tree via aria-owns by an element that is not the accessibility parent.

the intent was to link the term "accessibility parent" to its definition (https://w3c.github.io/aria/#dfn-accessibility-parent).

So looking at the example

<div role="list">
  <div role="listitem" aria-hidden="true">Excluded element</div>
  <div role="listitem" id="reparented">Reparented element</div>
</div>
<div aria-owns="reparented"></div>

in the first list, the second list item is reparented by an element that is not the accessibility parent, thereby making it an exclusion for the first DOM list element. In contrast, in the second list, the reparented list item has indeed been reparented by its accessibility parent, indicating that it is not considered an exclusion.

However, I acknowledge that while writing the above, there are too much complexities in the interpretation of "by an element that is not the accessibility parent."

Therefore, I am fully supportive of making improvements solely to the example (creating PR).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants