How does label in name relate to the description of a field?

[WilcoFiers]

This issue was raise on ACT: https://github.com/act-rules/act-rules.github.io/issues/2040

We're curious how the working group thinks about the following example. Do controls like this pass of fail SC 2.5.3 Label in Name:

<button aria-label="Subscribe to newsletter" aria-describedby="label">   
  <span>Subscribe to newsletter</span></br>   
  <span style="font-size: smaller" id="label">We send 1 mail per month.</span>
</button>

[anevins12]

I'm not part of the working group, but the accName must contain the visible label in its entirety. To pass this criterion, the accName must contain "Subscribe to newsletter We send 1 mail per month." It cannot reorder or cut up the visible label, but you can add additional information as a prefix or suffix, for example "[PREFIX] Subscribe to newsletter we send 1 mail per month [SUFFIX]!"

Edit: the accDesc does not interfere with the accName, making its use not important for 2.5.3 in this case.

[patrickhlauke]

the point of the SC is that voice users can trigger controls by announcing/reading out what they see visually (though unsurprisingly some big beasts in that space like Dragon actually don't support even basic aria-label, from what I hear...)

so whether or not the above would be ok would depend on whether or not speech control also takes into account accessible description, and not just accessible name (and since even just the latter has apparently flaky support, I doubt it). then could at least make an argument that it should also count/pass. but regardless, as written, at the moment, the SC would fail that I think...

[awkawk]

I think I agree that this fails, although it likely is the result of good intentions and extra efforts. If there was no aria-label then the accessible name would be the same as the (visible) label. I don't think that I can rationalize claiming that text within a button isn't part of the label, so the Accessibility Name would include all of it.

[JAWS-test]

See https://github.com/w3c/wcag/issues/2276 - Since the large font is visually the label and the small font is just a hint, a description, I would not see a violation of 2.5.3

[awkawk]

@JAWS-test I wouldn't lose any sleep over that explanation either. I don't think about buttons typically having description/help text in them, but the argument is consistent with treating input format info in a textfield label as descriptive...

[mbgower]

My gut reaction was that this SHOULD pass the intent of the SC. Yes, a strict reading of the normative text would fail this. However, most of this Understanding document is clarifying all the ways in which a strict interpretive reading of Label in Name does not actually serve the intended audience -- and worse can potentially jeopardize the experience of other users.

It is important to bias towards treating only the adjacent text as a label because liberal interpretations of what constitutes a text label can jeopardize the value of this Success Criterion (SC) by lessening predictability

Interestingly, when I look at the actual test for G208: Including the text of the visible label as part of the accessible name it seems to pass it, even though the gist of 208 is the opposite. That is likely a shortcoming of the test language.

Here is how this button would appear (the first line of the button's label "Subscribe to newsletter" in 'normal' sized text; the second line smaller)

If a speech-input user says "Click Subscribe to newsletter" they match the accname. Without having anything but anecdotal experience to back me up (which is the kind of data I would argue was the basis of this SC, unfortunately), I'm going to posit that most speech-input users would only say that top string. This would be because of:

• the change in text size
• the line break
• syntax (the second line is secondary)

But even if they also say the secondary string, this will still pass because the actual accname is still said. So it's hard to argue that anyone is poorly served by this construct passing?

I don't have enough info on how SR ATs work to know how they infer partial string matches. My suspicion is that even if this was flipped and whole two line string was the accname and the displayed label was only the top line, there would still likely be a match if the users said "Click Subscribe to newsletter." It would be good to understand actual behaviour going forward.

I should have listened to my original instincts on this SC. I held my nose on incorporation to 2.1 and on CFC, and it has probably sucked up more of my time on the Understanding document changes than any other 2.1 SC :) Let's make sure it's better thought through in whatever form it takes in 3.0.

[patrickhlauke]

I should have listened to my original instincts on this SC. I held my nose on incorporation to 2.1 and on CFC, and it has probably sucked up more of my time on the Understanding document changes than any other 2.1 SC

as an aside, I have similar feelings about some of the other "new" 2.1 SCs (e.g. Reflow). think they may have needed a bit more gestation time...

[junykallukalam]

I am not part of the working group, this is what I think, to interact with a button labeled "Subscribe to newsletter," user might say "Click Subscribe to newsletter." In this case, the accessible name of the button, as specified by the aria-label attribute, is "Subscribe to newsletter." This matches the voice command, enabling it to identify and interact with the button.

The element also includes text, "We send 1 mail per month," which provides supplementary information , it does not affect the voice command interaction. But after looking at your example, If "We send 1 mail per month" is visually styled as part of the button label, it might be better to include it in the accessible name as well to ensure a consistent experience for all users.