Computation steps, section 2C could be more clear

[tranjocelyn]

@aleventhal and I were reading the computation steps, section 2C:

Otherwise, if the current node is a control embedded within the label (e.g. any element directly referenced by aria-labelledby) for another widget, where the user can adjust the embedded control's value, then return the embedded control as part of the text alternative in the following manner:

We're not 100% sure what this means and we thought others might also find it confusing. Would it be possible to revise this step for improved clarity? Including additional examples could be helpful as well. Thanks!

[accdc]

I agree, this should say the following instead.

Otherwise, if the current node is a control embedded within the label (e.g. any element directly referenced by aria-labelledby) for another widget, where the user can adjust the embedded control's value, then return the embedded control's value as part of the text alternative in the following manner:

It should directly reference the value of the embedded control. Does this make more sense?

[aleventhal]

For me it's still unclear. - Parentheses tend to make things harder to read. Maybe we need to split this up into multiple bullet points or something. - Is there any difference between what we consider a widget vs. control? It's confusing that we are using 2 different terms. Can we talk about some examples here? We don't have to put them in the final text, but maybe that will help us wordsmith if we have all the examples of when to use the value and when not to.

…

On Tue, Jul 23, 2024 at 7:11 PM Bryan Garaventa ***@***.***> wrote: I agree, this should say the following instead. Otherwise, if the current node is a control embedded within the label (e.g. any element directly referenced by aria-labelledby) for another widget, where the user can adjust the embedded control's value, then return the embedded control's value as part of the text alternative in the following manner: It should directly reference the value of the embedded control. Does this make more sense? — Reply to this email directly, view it on GitHub <#244 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKQAZRXHFDWKUZVKP32RRTZN3PITAVCNFSM6AAAAABLLITDVSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBWGQ2TGOJRGY> . You are receiving this because you were mentioned.Message ID: <w3c/accname/issues/244/2246453916 ***@***.***>

[scottaohara]

this is how i'm interpreting what that text says

<div id=f>
  color
  <input type=text value="red" aria-labelledby=f> <!-- 1 -->
</div >
<input aria-labelledby=f> <!-- 2 (another widget) -->

expected names:
input 1: color
input 2: color red

in chromium, the above returns "color red" for input 1. and that doesn't seem like the right outcome, and it also differs from how the following, which does match my name expectations, above:

<label id=f>
	color
	<input type=text value=red>
</label>

<input type=text aria-labelledby=f>

expected/actual names:
input 1: color
input 2: color red

[aleventhal]

How about:

If the current node is a user-adjustable control embedded within the label, and the control is not recursively referencing itself, then return the embedded control's value as part of the text alternative in the following manner:

[aleventhal]

Or

If the current node is a user-adjustable control embedded within the label, and the control is not the element being named or described, then return the embedded control's value as part of the text alternative in the following manner:

[accdc]

That last one sounds good to me personally.

[aleventhal]

@accdc or @tranjocelyn could one of you update the spec text?

[MelSumner]

@aleventhal tagged you in the PR so you can let me know if I have accurately captured your requested text update.