Review and either confirm, remove, or fix "recursive/traversal" tests in ./accname/name/comp_name_from_content.html due to outstanding AccName issues

[cookiecrook]

The following ambiguities in AccName were discovered while writing WPT tests for the (misnomer) "recursion" portions of "name from content." After some healthy discussion, the following issues are still unresolved:

1. This use of the term "recursion" is not actually referring to recursion... so that portion of the AccName algo should be renamed.
2. There is still a conflict in AccName regarding aria-label and traversal on generics.
3. The parent issue of both of these is also related to traversal discrepancies.

I am adding this tracker because the above issues have not yet been resolved in AccName. Due to this, the Interop Accessibility contributors should carefully re-review the source of the AccName traversal tests (lines 210–253), and potentially remove, resolve, or move them to a tentative file if needed. I have a sneaking suspicion that a bogus test may remain here in Interop 2024.

[cookiecrook]

FYI @nmlapre @twilco

[cookiecrook]

FYI @MelSumner @accdc

[cookiecrook]

@smhigley wrote:

FWIW our production code [FluentUI] relies heavily in various places on not daisy-chaining aria-labelledby (i.e. it relies on the spec describing the behavior @accdc wrote, and the current browser behavior)

Will you help review the source of the AccName traversal tests (lines 210–253) and make sure you don't notice anything unexpected?

[accdc]

Thanks for pinging me about this, it’s difficult at times to keep track of everything.

“This use of the term "recursion" is not actually referring to recursion... so that portion of the AccName algo should be renamed.”

I’m not sure how this should be renamed. My understanding is that name from content causes the current node to traverse within the container that supports name from content. If I’m misunderstanding, please let me know. Also, if you have a recommended wording that would be clearer, please let me know.

“There is still a conflict in AccName regarding aria-label and traversal on generics.”

I’m not sure where the conflict is within AccName for this. The AccName spec doesn’t specify that generic roles should not be processed when being traversed, only that the “current node” should be processed when running through child nodes.

Personally I don’t recommend adding more complexity to the process by singling out specific roles as not being valid for naming. Even the use of role=”none” on an element isn’t sufficient to prevent a name from being exposed when using aria-label.

In the case of an average developer, most will never know which elements are implicitly generic and why in accordance with the ARIA spec, and this will only lead to more confusion and unreliable naming practices across the web.

Also, prior to the addition of the generic role, the use of aria-label on a div or span was an excepted and supported practice, so doing this will retroactively break all such implementations everywhere across the web if this is done.

To be clear, I’m not saying that a basic div or span should be namable by themselves. I am only saying that when a div or span is encountered when compiling the accessible name of an ancestor role, such as a heading or link or button or anything else, it should return the value of aria-label if found just like it does with all other roles that are not widgets with values.

“The parent issue of both of these is also related to traversal discrepancies.”

Apologies, it’s been a long day, can you clarify this one?

Thanks,
Bryan

[cookiecrook]

I’m not sure how this should be renamed. My understanding is that name from content causes the current node to traverse within the container that supports name from content.

I think the term "traversal" is fine... "recursion" is not because it does not recursively traverse.

[nmlapre]

By my reading of the current spec, the last two tests here have incorrect expectations. The disagreement lies in the applicability of the spec note "Each node in the subtree is consulted only once." That's an unambiguous sentence, and it sits in the Name From Content section. I think a reasonable interpretation is that, since we already consulted a node via an aria-labelledby traversal, we shouldn't consult it again. Those last two tests consult the same node twice.

Notably, consulting only once is the expectation of the second test in this group. We consult nested_image_label2 during the aria-labelledby traversal, but don't consult it again when it comes up in a Name From Content traversal later. I think this stands in conflict with the last two tests, which expect that we would consult the already-consulted node again.

I do think the spec could be clearer, and I don't know that my interpretation of it is actually what's reasonable UA behavior from an author perspective. Regardless, if we take it as written, I think we should adjust the expectations of the last two tests to avoid the double-consulting, or move them to tentative files. I think the other tests are correct.

Below, I've included my step-by-step breakdown of following the Acc Name spec for each test. Please do correct me if I'm getting something wrong here.

1. heading with nested link with nested image using aria-labelledby

<h3 data-expectedlabel="heading image heading" data-testname="heading name from content for each child including nested link using aria-labelledby with nested image" class="ex">
  heading
  <a href="#" aria-labelledby="nested_image_label1">
    ignored link text
    <img id="nested_image_label1" alt="image" src="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==">
    ignored link text
  </a>
  heading
</h3>

1. h3 uses Name From Content to determine its name.
2. Consult 1st h3 child: text node. Append "heading" to the accumulated text.
3. Consult 2nd h3 child: a. Follow aria-labelledby reference to nested_image_label1.
4. Use nested_image_label1's Host Language Label (alt): name is "image". This is the text for the entire a child of the h3, so we do not look through that child further.
5. Accumulated text is now "heading image".
6. Consult 2nd h3 child: text node. Append "heading" to the accumulated text.
7. Result is "heading image heading".

2. heading with two nested links referencing image using aria-labelledby

<h3 data-expectedlabel="image link2 link3" data-testname="heading name from content for each child including two nested links using aria-labelledby with nested image" class="ex">
  <a href="#" aria-labelledby="nested_image_label2">
    link1
  </a>
  <a href="#" data-expectedlabel="link2 image link3" data-testname="link name from content for each child including nested image (referenced elsewhere via labelledby)" class="ex">
    link2
    <img id="nested_image_label2" alt="image" src="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==">
    link3
  </a>
</h3>

computing name of h3

1. h3 uses Name From Content to determine its name.
2. Consult 1st h3 child: a, labelled by nested_image_label2.
3. Use nested_image_label2's Host Language Label (alt): name is "image". This is the text for the entire a child of the h3, so we do not look through that child further.
4. Consult 2nd h3 child: a. Has link role, so use Name From Content to determine its name.
5. Consult 1st a child: text node. Append "link2" to the accumulated text ("image link2").
6. Skip 2nd a child nested_image_label2 because "Each node in the subtree is consulted only once" and we already consulted it earlier in this h3 Name From Content traversal.
7. Consult 3rd a child: text node. Append "link3" to the accumulated text ("image link2 link3").
8. Result is "image link2 link3".

computing name of a

1. a has link role, so use Name From Content to determine its name.
2. Consult 1st a child: text node. Append "link2" to the accumulated text ("link2").
3. Consult 2nd a child: nested_image_label2. Append Host Language Label (alt): name is "image", accumulated text is "link2 image".
4. Consult 3rd a child: text node. Append "link3" to the accumulated text ("link2 image link3").
5. Result is "link2 image link3".

3. heading with link referencing image using aria-labelledby, that in turn references text element via aria-labelledby

<h3 data-expectedlabel="image link" data-testname="heading with link referencing image using aria-labelledby, that in turn references text element via aria-labelledby" class="ex">
  <a href="#" aria-labelledby="nested_image_label3">
    <span class="note" id="crossref_link">link</span>
  </a>
  <img id="nested_image_label3" alt="image" aria-labelledby="crossref_link" src="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==">
</h3>

1. h3 uses Name From Content to determine its name.
2. Consult 1st h3 child: a. Follow aria-labelledby ID to consult nested_image_label3.
3. nested_image_label3 has aria-labelledby attribute, but is already part of an ongoing aria-labelledby traversal, so we do not use the LabelledBy step. Instead, use the Host Language Label (alt) to get the name "image".
4. Append "image" to the accumulated text ("image") and do not consult the 1st child (a) further.
5. Consider 2nd h3 child, img, but note that it has already been consulted once in this Name From Content calculation. Per spec note, "Each node in the subtree is consulted only once." So, skip this node.
6. Result is "image".

4. heading with link referencing image using aria-labelledby, that in turn references itself and another element via aria-labelledby

<h3 data-expectedlabel="image link" data-testname="heading with link referencing image using aria-labelledby, that in turn references itself and another element via aria-labelledby" class="ex">
  <a href="#" aria-labelledby="nested_image_label4">
    <span class="note" id="crossref_link2">link</span>
  </a>
  <img id="nested_image_label4" alt="image" aria-labelledby="nested_image_label4 crossref_link2" src="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==">
</h3>

1. h3 uses Name From Content to determine its name.
2. Consult 1st h3 child: a. Follow aria-labelledby ID to consult nested_image_label4.
3. nested_image_label4 has aria-labelledby attribute, but is already part of an ongoing aria-labelledby traversal, so we do not use the LabelledBy step. Instead, use the Host Language Label (alt) to get the name "image".
4. Append "image" to the accumulated text ("image") and do not consult the 1st child (a) further.
5. Consider 2nd h3 child, img, but note that it has already been consulted once in this Name From Content calculation. Per spec note, "Each node in the subtree is consulted only once." So, skip this node.
6. Result is "image".

[dandclark]

I agree with @nmlapre's analysis here. It looks like heading with link referencing image using aria-labelledby, that in turn references text element via aria-labelledby and heading with link referencing image using aria-labelledby, that in turn references itself and another element via aria-labelledby need to be updated/removed/marked tentative.