JR comment on Accessible Name

[michael-n-cooper]

Filed by email 14 October 2017 by @JanRichards

Don’t agree. The visible label might be an abbreviation “MM”, but I should be able to set the accessible name to “2 digit month”.

[awkawk]

The intent is that the name includes, and ideally starts with the "MM" from the label in this case, but would not prohibit an author from providing a further expansion in the name, such as "MM, two digit month". It is worth noting that a label "MM" might need to be expanded to meet SC 3.1.4 Abbreviations (AAA).

[JanRichards]

I'm just trying to say that the focus on the "string", while helpful for automatic testing could be overly constraining for authors who know what they're doing. In my example, "2 digit month" is very helpful but would fail, while "Summer" makes no sense, but would pass because it contains "mm" (though it would of course fail the more all-encompassing 1.3.1). Another example is the visible label "Serial#:" and the aria-label="Serial number".

[steverep]

@JanRichards, note that the SC has changed in response to other comments, and the latest version no longer talks about the "string". It simply says the name contains the text presented. In my opinion, "summer" in your example should fail because it is not the same thing as represented in human language (per the definition of text).

[JanRichards]

OK, and are you comfortable with the fact that the label text might be an abbreviation while the accessible in such a case would often be better to be the expanded form?

[awkawk]

This has been discussed - the author could provide both if needed in the name.

[JanRichards]

We discussed it, but I don't see anything in the current wording that enables abbreviation expansions to be used in place of the abbreviations. Maybe that could be called out as a technique for clarity?

[awkawk]

Good idea - marked for implementation followup to remind us.

[steverep]

OK, and are you comfortable with the fact that the label text might be an abbreviation while the accessible in such a case would often be better to be the expanded form?

Honestly, I'm confused as to why you think that is more accessible to show the vast majority of users the abbreviation, and then show screen reader users something different. If a developer thinks it's important enough to spell out for a screen reader user, that should be a clue it's important enough to spell out for everyone. I'm a full-time screen reader user who gets this type of question often, and I always say the same thing: I want to hear what you see - no more, no less. And this is even more true with low vision where it can be confusing to see one thing on screen but hear another.

[JanRichards]

I'm not saying it's better to show everyone abbreviations, but using abbreviations is not forbidden for visible form field labels is not prohibited by WCAG and sometimes there are space constraints and designers may use them. In such cases, I'm just saying a designer conscious of accessibility might choose to use the expanded form of the abbreviation in the aria-label. You may disagree that this is the best screen reader user experience, but is it so bad that it should fail WCAG?

[jnurthen]

All a designer has to to in this case is provide both the expanded form and the abbreviation in the aria-label and they would pass this. That doesn't sound particularly hard to do. i.e. in your example MM <input aria-label="2 digit month - MM">

…

On Fri, Nov 17, 2017 at 4:16 PM, Jan Richards ***@***.***> wrote: I'm not saying it's better to show everyone abbreviations, but using abbreviations is not forbidden for visible form field labels is not prohibited by WCAG and sometimes there are space constraints and designers may use them. In such cases, I'm just saying a designer conscious of accessibility might choose to use the expanded form of the abbreviation in the aria-label. You may disagree that this is the best screen reader user experience, but is it so bad that it should fail WCAG? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#557 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABpQP7jrLlV1PbuoF45ZvBN5GQmzrhc7ks5s3iHUgaJpZM4QRkqO> .

[steverep]

@JanRichards, you are making an argument that a developer should be able to do this because they are being "conscious of accessibility", but the entire point of this SC is that it actually creates inaccessibility for speech users (and I would add bad experience for low vision users who see one thing and hear another). And as @jnurthen points out, providing the extra expanded form in the name would not result in a failure as long as the label text is there too. This SC is very easy to meet.

[JanRichards]

When you say "inaccessibilty for speech users", what do you mean? That blind speech users will specify the month field by saying "month" because that's what they hear from the screen reader when they should say "M...M" because that's what the is? In that case, it sounds like the speech access systems can be part of the solution by enabling the use aria-labels.

[jake-abma]

Hi @JanRichards,

For the "inaccessibility for speech users" here’s a small illustration for the MM example:

(in this example no “for / id” attributes used…)

• We have a label element with “MM” as text node
• We have an input with the aria-label of “2 digit month”

<label>MM</label>
<input type="text" name=“month” aria-label="2 digit month">

• The visible label for the input will be "MM"
• The accessible name for the input will be “2 digit month”

So when using a speech command like “click text field MM” nothing will happen as there's no match with the label.

Adding the “MM” to the aria-label makes it possible to put the focus directly on the input or show the input field as one of the options to choose from (if there are more inputs with “MM” in the name you may get numbers next to the input fields).

Users with low vision will see “MM” but also hear “MM” in the accessible name.

A best practice is to even place the text string at the start of the text string.
So to apply this to the example @jnurthen gave above we’ll end up with:

<label>MM</label>
<input type="text" name=“month” aria-label="MM - 2 digit month">

[JanRichards]

Thanks for the clear example (which looks like a nice start for a related technique).