Editorial: Update computation step "comp_embedded_control" (formerly step 2c) text for clarity

[MelSumner]

Closes accname issue 244

If merged, this PR updates step "comp_embedded_control" (formerly step 2c) to be the agreed upon text per this issue: w3c/accname#244

[netlify]

✅ Deploy Preview for wai-aria ready!

Name	Link
🔨 Latest commit	03a72ef
🔍 Latest deploy log	https://app.netlify.com/sites/wai-aria/deploys/66aaa119e7480700087f23da
😎 Deploy Preview	https://deploy-preview-2299--wai-aria.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[cookiecrook]

"user-adjustable" doesn't account for an embedded readonly field.

Do we care about this?

<label for=""cb>
  <input type="cb" name="cb" id="id">
  Flash the screen <input readonly value="3"> times.
</label>

Will the new language, the (admittedly contrived) label above would be " Flash the screen times."

[cookiecrook]

Actually I guess the old text doesn't account for readonly fields either.

…where the user can adjust the embedded control's value…

[cookiecrook]

"user-perceivable" perhaps?

Suggested change

	<span id="step2C"><!-- Don't link to this legacy numbered ID. --></span><em>Embedded Control:</em> Otherwise, if the <code>current node</code> is a user-adjustable control embedded
	<span id="step2C"><!-- Don't link to this legacy numbered ID. --></span><em>Embedded Control:</em> Otherwise, if the <code>current node</code> is a user-perceivable control embedded

Or just remove that adjective?

[cookiecrook]

Note: This new proposed language would bring in disabled fields too, but I think that'd be expected if a disabled control were inside a label. What do you all think about this (also contrived) example?

<label for=""cb>
  <input type="cb" name="cb" id="id">
  Flash the screen <input disabled value="3"> times.
</label>

[cookiecrook]

Nit: take or leave. "as part of the text alternative" kinda makes it sound like you're overriding how this returned value would be included in the overall text alternative computation... I think the sentence stands without that clause, but feel free to keep it and resolve this comment if you disagree.

Suggested change

	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:
	within the label, and the control is not the element being named or described, then return the embedded control's value in the following manner:

[accdc]

Simply referring to control sounds good to me if it's clear to everyone else.

[scottaohara]

the argument about just saying "control" is that a display none control's value should not participate. and i'd also argue that one should not anticipate a input type=checkbox value=nope would have its value participate either.

a non-hidden control with a user-perceivable value (e.g., text input value or chosen option from a select, but not checkbox or radio button value) seems more like what we would actually want covered here.

[cookiecrook]

a non-hidden control with a user-perceivable value (e.g., text input value or chosen option from a select, but not checkbox or radio button value) seems more like what we would actually want covered here.

"user-perceivable value" for a checkbox (true or false, checked or unchecked) would also be perceivable. If that's the case, the value for each control type would need to be specified. Yuck.

Should it be limited this to "user-perceivable control with a string value"?

[scottaohara]

when i was referring to value i meant the string value. e.g., input type=checkbox value=foo the state (checked or not) shouldn't be considered as part of the calculation. agreed that'd be yucky.