Editorial: Update computation step 2c text for clarity

[MelSumner]

Closes accname issue 244

If merged, this PR updates step 2C to be the agreed upon text per this issue: https://github.com/w3c/accname/issues/244

[netlify[bot]]

✅ Deploy Preview for wai-aria ready!

Name	Link
🔨 Latest commit	9c24b9011c3553a7619a0caacf96cc247c41af07
🔍 Latest deploy log	https://app.netlify.com/projects/wai-aria/deploys/682f6349f5a1f700072b3420
😎 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 project configuration.

[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.

[MelSumner]

@MelSumner note for myself to rebase and also address comments that don't have suggestions.