Accname discussion - multiple references

[jnurthen]

To facilitate discussion of https://lists.w3.org/Archives/Public/public-aria/2021Jan/0052.html it was decided to post into separate github issues. Please also see #98

What should the accessible name be for the button (#test)

<div id="p">
<i id="q">Outside Text</i>
<button id="test" aria-labelledby="p q" >Screen Text</button>
</div>

Please post your answer and reasoning - referencing the steps in the ACCNAME spec which result in your decision.

[JAWS-test]

IE 11, Firefox: "Outside Text Screen Text Outside Text"
Chrome, Edge: "Outside Text Outside Text"
AccName Prototype Test: "Outside Text Screen Text"

AccName Prototype Test is correct because of: "Important: Each node in the subtree is consulted only once. If text has been collected from a descendant, but is referenced by another IDREF in some descendant node, then that second, or subsequent, reference is not followed. This is done to avoid infinite loops"

I.e. aria-labelledby=p is evaluated as in Issue 98 and aria-labelledby=q is ignored

[JAWS-test]

But much more interesting is the original example:

Edit: Here I am of the opinion that choise 2 is correct. ("If traversal of the current node is due to recursion and the current node is an embedded control as defined in step 2E, ignore aria-label and skip to rule 2E."). I agree with @jongund at https://lists.w3.org/Archives/Public/public-aria/2021Jan/0001.html

If this is true, then the output would be correct in Chrome and incorrect in Firefox + AccName Prototype Test

[cookiecrook]

@JAWS-test wrote:

IE 11, Firefox: "Outside Text Screen Text Outside Text"
Chrome, Edge: "Outside Text Outside Text"
AccName Prototype Test: "Outside Text Screen Text"

It's useful to know this. Thank you.

I also want to remind the readers that the discussion should be about what the algorithm should do, regardless of what the browsers currently do.

[joanmarie]

Answer: "Outside Text Screen Text"

I think that's what the spec intends. But I can get there in two slightly different ways, and even get different results, depending on how I read the algorithm.

The differences come from the following:

• 2F says "... or if the current node is referenced by aria-labelledby ...". Does that mean referenced by aria-labelledby by some element anywhere else in the document? Or does it mean for the node we're calculating the text alternative for? To put it a different way, does it mean "If you got to this step from 2.B.ii"?

• 2H says "... if the current node is a descendant of an element whose Accessible Name or Accessible Description is being computed, and contains descendants ..." Are "descendants" elements, or can they be text nodes? I assume they can be elements or text nodes. But if descendant means elements, you can get a different result.

• Under 2F it says "Important: Each node in the subtree is consulted only once. If text has been collected from a descendant but is referenced by another IDREF in some descendant node, then that second, or subsequent, reference is not followed." If text has NOT been collected from a descendant (i.e. because none of the steps in 2 apply the first time we "consulted" it), can we try again for the subsequent reference? If you can, and descendant means elements, you can get a different result.

Below are the two ways I can get "Outside Text Screen Text," which I believe is what authors expect to get.

Version 1

Step 1
root node = button (test)
current node = button (test)

Step 2: Compute text for current node button (test)
Step 2B applies: computing a name and current node (test) has aria-labelledby
For each IDREF, return to step 2 and append its text alternative. Then return the result.
Two IDREFs: p and q

Processing IDREF p:
Step 2F applies: the current node (p) is referenced by aria-labelledby (for the node we're calculating, test)
For each child of current node (p) return to step 2 and append its text alternative. Then return the result.

Processing child node q:
Step 2F applies: The current node (q) is referenced by aria-labelledby (though it's for the root node; not for the node we're calculating the text alternative for, p)
Result for child node q: "Outside Text"

Processing child node test:
This time 2B does not apply: it IS already part of an aria-labelledby traversal
2F applies: The current node's role allows name from content.
Result for child node test: "Screen Text"

Results for IDREF p: "Outside Text Screen Text"

Processing IDREF q:
Re 2F: the current node (q) is referenced by aria-labelledby. But the "important" note seems to suggest we should ignore this subsequent reference.
Result for IDREF q: ""

Final result: "Outside Text Screen Text"

Version 2

Step 1
root node = button (test)
current node = button (test)

Step 2: Compute text for current node button (test)
Step 2B applies: computing a name and current node (test) has aria-labelledby
For each IDREF, return to step 2 and append its text alternative. Then return the result.
Two IDREFs: p and q

Processing IDREF p:
Step 2F applies: the current node (p) is referenced by aria-labelledby (for the node we're calculating, test)
For each child of current node (p) return to step 2 and append its text alternative. Then return the result.

Processing child node q:
Step 2F does not apply: The current node (q) is referenced by aria-labelledby BUT not for the node we're calculating the text alternative for (p)
Step 2H applies: the current node (q) is a descendant of an element whose Accessible Name or Accessible Description is being computed (p), and contains descendants (a text node)
Step 2H says to proceed to 2F.i.
Result for child node q: "Outside Text"

Processing child node test:
This time 2B does not apply: it IS already part of an aria-labelledby traversal
2F applies: The current node's role allows name from content.
Result for child node test: "Screen Text"

Results for IDREF p: "Outside Text Screen Text"

Processing IDREF q:
Re 2F: the current node (q) is referenced by aria-labelledby. But the "important" note seems to suggest we should ignore this subsequent reference.
Result for IDREF q: ""

Final result: "Outside Text Screen Text"