-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Computation steps, section 2C could be more clear #244
Comments
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? |
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 ***@***.***>
|
this is how i'm interpreting what that text says
expected names: 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:
expected/actual names: |
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: |
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: |
That last one sounds good to me personally. |
@accdc or @tranjocelyn could one of you update the spec text? |
If merged, this PR updates step 2C to be the agreed upon text per this issue: w3c/accname#244
@aleventhal tagged you in the PR so you can let me know if I have accurately captured your requested text update. |
@aleventhal and I were reading the computation steps, section 2C:
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!
The text was updated successfully, but these errors were encountered: