Speech Input

[kwahlbin]

Current versions of SC and Definitions

• SC for viewing | SC for editing
• Accessible Name for viewing | Accessibility Name for editing

SC Shortname

Accessible Name

SC Text

Where an active control has a visible label, the accessible name for the control includes the text string used for its visible label.

Suggestion for Priority Level (A/AA/AAA)

Level A

Related Glossary additions or changes

Accessible Name

The accessible name is the name of a user interface element. The value of the accessible name may be derived from a visible (e.g., the visible text on a button) or invisible (e.g., the text alternative that describes an icon) property of the user interface element. A simple use for the accessible name property may be illustrated by an "OK" button. The text "OK" is the accessible name. When the button receives focus, assistive technologies may concatenate the platform's role description with the accessible name. For example, a screen reader may speak "push-button OK" or "OK button".

Based on Definition of Accessible name https://www.w3.org/TR/accname-aam-1.1/

What Principle and Guideline the SC falls within.

Principle 2: Operable
New Guideline: Speech

Description

One means of speech input is speaking menu, link and button labels that appear on a webpage. Speech input programs sometimes enable users to speak labels that are not seen on the page. Speech users can accidentally say a word in a hidden label and be taken to that link without knowing what has happened. Mismatched labels can also confuse speech users when they say what they can see, but this does not match the actual command.

Single key shortcuts can also obstruct speech input – this is addressed under SC M12a and M12a.

Another important means of speech input is speaking keyboard controls. This is addressed under 2.2.1. Detail specific to speech input users: Users can speak keyboard controls or write custom speech commands that can call keyboard controls. Making sure that keyboard controls are available to speech input users ensures that, in general, anything that is accessible by keyboard is accessible by speech. Some speech users' may use a mix of inputs or have colleagues who use keyboard input. Mapping speech to keystrokes ensures that the same mental map can be used for both types of commands.

Proposed SC Examples

A speech input user is buying a gift on a website. The user is adding a note to his nephew when he utters the word "time" and is suddenly whisked off to another website, losing the information she entered because a hidden label link on the page contains the word "time". The user doesn't know what has happened, and tries again. This time he is more careful in writing the note and so speaks in short phrases. This invariably causes him to say the single word "time" again, which starts him on another loop. Despite going through this loop several times he doesn't have the information to figure out what has happened because the hidden label is not discoverable.

A speech input user tries to click a button labeled "submit" by saying "submit", but it does not respond. This is due to a mismatched label, but the user cannot see the mismatch and so does not know why this particular button does not respond. After trying to click the button by saying the label several times, she falls back to having to say several commands to move the mouse and click the button instead. The next time she uses the site she remembers that the site doesn't work well with speech, but doesn't remember which button doesn't respond.

Benefits

Speech input users will have fewer surprising changes of focus and will be able to easily activate controls on the page.

Testability

Identify all controls on the page. Review underlying code and note the accessible names provided for the control. Ensure that the visible label and the accessible name contain the same text.

Techniques

Ensure that visible labels match hidden labels.

[alastc]

As per my comment on Non-interferance with AT, would it be possible to make this a test of content instead of AT?

I like the examples, that made it much clearer to me and it seems the nub is the active but invisible controls?

I could be way off, but this will demonstrate what I have understood from reading the description above, how about something like:
Active controls in web pages have visible labels that match the accessible name

That appears to match the testability section to me?

We probably can't use 'accessible name', that needs a better term, but would it be possible to make it about a test of the content?

[goetsu]

Do it mean that any website using icons only for button like cart, like, home, email, etc without text next to the icon can't conform to WCAG 2.1 level A ?

[mbgower]

This proposal seems to be highlighting poor authoring habits that can be addressed through existing SC -- specifically using keyboard operability to support conformace requirement 4 .

There is one mentioned which may have potential to be put into a more agnostic piece of guidance:

One means of speech input is speaking menu, link and button labels that appear on a webpage. Speech input programs sometimes enable users to speak labels that are not seen on the page. Speech users can accidentally say a word in a hidden label and be taken to that link without knowing what has happened.

I would phrase this principle in this manner:
Where interactive content is removed visually from the UI, the interactive content should also be removed from keyboard operability.

Does anyone feel this is adequately captured through existing SC -- or that it can be covered by adding techniques to an existing SC? Otherwise, I would propose it for a new SC. However, I do not think it should be presented as a speech-only consideration.

In regard to the visible label not being the programmatic label (and thus not being actionable via speech), that seems to me like it would fall under 1.3.1

Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)

We could beef up the language around ensuring the visual text is matched programmatically. That might make a decent Failure technique for 1.3.1

[detlevhfischer]

@mbgower: "Where interactive content is removed visually from the UI, the interactive content should also be removed from keyboard operability."
Depending on how you interpret this advice, it might be seen as conflicting with the common pattern of invisible (but keyboard-accessible) skip links that are displayed once they receive focus?

I am concerned that the requirement "Ensure that the visible label and the accessible name contain the same text" might me too restrictive. There are cases where for non-visual users the accessible name should carry more information than is necessary for visual use. A common example are "read more" links that can be differentiated visually by being close to the teaser text and headline (and be programmaticall yavailable by using some of the techniques for SC 2.4.4, but benefit from containing hidden text (or using aria-label or aria-labelledby) to serve a more descriptive text to non-visual users (including those that call up link lists).

@ Kim Patch: It sounds a bit like the accidental activation when listening to speech might easily happen at some point if that function is turned on? Is it not just a mattter of tiime until you mention "time" somewhere in speech? So to me (but maybe I misunderstand) it looks like the point is the ability to correct accidental activation after it has happend? I not familiar enough with speech input but is there generally a way around accidental activation (after moving back to the page) by calling up the numbering of controls so they can be activated by speaking the number that is then shown next to it? That would require controls to be semantic (native or with ARIA roles) but this would be caught anyway by SC 4.1.2. But it would be an alternative way to avoid that obstacle.

[mbgower]

@detlevhfischer

Depending on how you interpret this advice, it might be seen as conflicting with the common pattern of invisible (but keyboard-accessible) skip links that are displayed once they receive focus?

I take your meaning, although a skip link, itself, is an accessible affordance for keyboard and I think could easily be worked in as an exception in the same way alternatives are excepted in other SCs (e.g., in 1.2.1, "except when the audio or video is a media alternative for text")

I am concerned that the requirement "Ensure that the visible label and the accessible name contain the same text" might me too restrictive. There are cases where for non-visual users the accessible name should carry more information than is necessary for visual use.

Accessible name is a defined term and covers both visible and invisible properties of the element. I think the wording of the term could be tightened up to clarify how aria-labelledby, aria-describedby and other concatenation techniques do or do not constitute part of the accessible name. But I agree, the wording in this proposed SC around this concept needs attention and consideration.

[StommePoes]

@detlevhfischer I only have experience with one speech-rec program, but if I'm dictating (like into this text input), the text isn't seen as a command. I'd have to do a pause long enough for Dragon to check if what I said could be a command. Recognised commands appear visually to me, which would help me see what triggered an action. Additionally, if a crap page was constantly setting off a command, I could for safety switch my mode to Dictation-only for while I'm dictating my note. This is poor UX but it's not the same as it being impossible to input text without accidentally calling a command. The ability-to-correct looks like the right direction though.

@goetsu This would be great (at least to have mentioned somewhere). Controls with icons are pretty hard to call out by name. If you happen to know the aria-label name or similar, it works (at least in things that have that ARIA support like Dragon) but I usually only know the aria-labels because I'm a developer poking into code. Nobody in my family would know the secret word.

Once on a page I said "click button" expecting to get buttons numbered so I could choose the right one. Instead, there was actually only 1 button on the page (the rest were links disguised as buttons) and it was a submit to a form I hadn't filled out, so I ended up on a form error page when all I wanted to do was click something with a goofy icon :(

[KimPatch]

@detlevhfischer @StommePoes It's important to be able to undo – and also to be able to see what was accidentally done (even if I can see that I said "2" and got bounced out of a Google doc, I still may have no idea what happened or if it will happen again in that Google doc or any Google doc). But that's not the whole solution. Switching to dictation-only mode while you are dictating a note means that you don't have access to some of the commands that you use for correcting and changing as you dictate. Having to remember what set of commands you have at your service for dictation increases cognitive difficulty and makes it impossible to use your whole brain for whatever it is you're trying to write. Switching out of dictation mode, issuing a command, and then switching back takes 300% the effort of using one mode. So, in a practical sense, many users will take the chance of getting burned more often rather than switching back and forth. Identifying a page where you have to switch back and forth also means having a bad experience on that page, and then remembering that.

Understood that for some purposes it's useful for hidden text to be different than what's showing. I think ultimately it's not appropriate for hidden text to be enabled for speech use. What's really needed are discoverable short labels that are appropriate as speech commands that are separate from descriptive text. This is akin to how keyboard shortcuts are used for speech users – we can voice them, which can be a bit clunky, or we can take the time to make speech commands that call them.

[StommePoes]

Agreed with both points @KimPatch

[patrickhlauke]

Late comments on this. From the original proposed example

The user is adding a note to his nephew when he utters the word "time" and is suddenly whisked off to another website, losing the information she entered because a hidden label link on the page contains the word "time".

Is this not a failing of the AT/speech software? If the user is currently writing (presumably in a textarea or similar input), the AT should suppress any triggering behavior until the user has exited the input. The fact that the label is visually hidden here is orthogonal to the problem...if a user was able to see the visible "time" label, they'd have a way of knowing why they're being taken for a loop...but fundamentally they'd still be prevented from doing what they're trying to do, i.e. write in an input using a word that also happens to be a label somewhere on the page? And what would be the proposed technique for authors here? Making the label visible?

I think the proposed text here is still a bit of a mix of purposes/problems. Boiling it down, it seems to focus on "controls need to have a visible label that matches their actual triggerable name" or similar. Refocusing the SC proposed name and text to just just may help in removing ambiguity (and removing the example there with "time", which seems to point to AT problems outside of an author's control)

[StommePoes]

'"the AT should suppress any triggering behavior until the user has exited the input"
Not if the AT thinks the user is doing a command. If I'm in the middle of dictating something and I pause (long enough, you can set it but I leave it at the default) and then say "click Comment" then the AT (if Dragon in this case) would show I said a command "click" and could press the comment button, which would then move on to the browser web page doing whatever clicking Comment does.

That is, should I have to say "press Tab" to get to the control first? My current copy (13 Pro) actually seems to have a bug where I can only say to press Shift-Tab maybe once before it stops understanding it. If I'm on a crap page like the GitHub login page (the page you end up at if you go to github.com and you're not logged in), you're autofocussed into an edit field right away, against your will, and instead of needing to attempt to "press shift-tab" a gazillion times, I should instead be able to say "click Signin" despite being stuck on a text input (not that I don't still many times end up with the field getting "click signin" typed in though).

So, I don't know that that's a reasonable way out of the above problem.

"I think the proposed text here is still a bit of a mix of purposes/problems. Boiling it down, it seems to focus on "controls need to have a visible label that matches their actual triggerable name" or similar. Refocusing the SC proposed name and text to just just may help in removing ambiguity (and removing the example there with "time", which seems to point to AT problems outside of an author's control)"
Hm, yes, that's probably better. The labels thing is something we can do something about, as a recommendation to authors or an idea for a feature from vendors.

[patrickhlauke]

@StommePoes but what is the expectation on an the web page author? this comes down to how AT behaves (whether it ignores it any commands, or expects a modifier key, or a specific word to be uttered first like "press...") etc.

in short, that part is unrelated (and out of the control of the author) to the other part of having visible labels (which does tally with the SC's aim of "All functionality of the content does not obstruct a user’s ability to access the commands through speech input.") - this SC should focus on that part, I'd say

[StommePoes]

Agreed, I don't see author-based solutions for the "time" story above, while I do for visible-labels.

[mraccess77]

Added a pull request for this issue #139

[marc-thorson]

As a developer who also relies almost entirely on speech recognition due to mobility issues, I feel that @alastc's comment is closest to what a success criterion actually needs to be that will truly help:

Active controls in web pages have visible labels that match the accessible name.

This is imperative for sighted speech recognition users to have an accessible experience — if you don't know what to say, how are you going to say it?

That said, in my opinion, this is more of a "perceivable" issue than an "operable" one from a content author's perspective. As @mbgower indicates, this is very close to SC 1.3.1 Info and Relationships; however, as someone who regularly trains other developers on accessibility techniques, I feel that particular success criterion already has a huge scope and learning curve for authors to understand and its examples clearly focus on screen reader usage, so I think it would be beneficial to have this separate criterion focusing on the speech recognition aspects of perception.

I think it's critical to point out techniques that truly will help authors create more accessible content. In this case, it involves pointing out how important the precise accessible name is for speech recognition to work. For example, an author might create a fancy graphical button with an image of the text "Buy Now" on a page selling The Amazing Thingamajig. The author might choose to use an alt or aria-label of "Buy The Amazing Thingamajig Now" to provide good context for screen reader users, but he/she may not realize that changing sequence of what is seen visually actually prevents most speech recognition software from triggering the button when the user says exactly what he/she sees — saying "buy now" doesn't work. However, choosing either "Buy Now: The Amazing Thingamajig" or "The Amazing Thingamajig: Buy Now" as the alt/aria-label would make things accessible for both screen readers and speech recognition, as the sequence of words used in the accessible name matches the visible label in those cases. This is the example I'd like to see emphasized in WCAG to go along with the fact that interactive controls must have visible labels.

[KimPatch]

@marc-thorson @alastc's I agree that this is the crux of it
@marc-thorson I like your thoughts about this. Speech developers need to be able to narrow this rather than allowing the user to say any combination of words in the alt/aria-label. It's important to know what to say but it's equally important that there not be a whole bunch of hidden ways to say something that can be accidentally tripped. Having the on-screen label be the first part of the alt/aria-label would give speech developers a mechanism to do this. Otherwise the only thing they can do is enable all the words, which makes for many hidden command minefields.

[DavidMacDonald]

@KimPatch @marc-thorson
@alastc suggested this, which is much better than the original.

Active controls in web pages have visible labels that match the accessible name

Screen reader users sometimes need extra text in their offscreen label, which contains instructions, context etc. Wouldn't it be only necessary that the invisible label contains the exact text string...

• Visible label = Amazing thingmagig
• Invisible label = Buy the Amazing thingmagig now

Would pass, right? If so, how about this.

If an active control has both an invisible and a visible label, the invisible label contains the exact same text string as the visible label (including the same order of words), as part of, or all of, the invisible label.

[KimPatch]

I like this.

If an active control has both an invisible and a visible label, the invisible label contains the exact same text string as the visible label (including the order of words), as part of, or all of, the invisible label.

I would add the words "the first"
If an active control has both an invisible and a visible label, the invisible label contains the exact same text string as the visible label (including the order of words), as the first part of, or all of, the invisible label.

The thing that will make this work for speech users is if the speech program can enable the visible label and only the visible label rather than any word in the label plus the description. So it needs to be delineated in some way. Seems like putting it first would be good for everyone including screenreader users.

[Ryladog]

I like this: Each active control has a label that includes its visible name on the web page. ​​​​​* katie *

[DavidMacDonald]

@mraccess77 @KimPatch @Ryladog
If it needs to be in the first part of the label, then we can simplify it a bit I think:

If an active control has an invisible label that is different from its visible label, the invisible label starts with the full text of the visible label.

I think this is a winner. Very testable, simple requirement, appropriate for WCAG.

[jnurthen]

Is this necessary?I know that with Dragon NaturallySpeaking you can speak any of the text of the link and it will still activate that link. Why do we need to limit the text as being the first part link?

…

On Thu, 6 Apr 2017 at 10:00 David MacDonald ***@***.***> wrote: @mraccess77 <https://github.com/mraccess77> @KimPatch <https://github.com/KimPatch> If it needs to be in the first part of the label, then we can simplify it a bit I think: If an active control has an invisible label that is different from the visible label, the invisible label starts with the full text of the visible label. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#68 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABpQP6G_D6HJZPOcloTc0hIuk3ThAWFVks5rtRpFgaJpZM4K-jMT> .

[DavidMacDonald]

Perhaps we need further testing to determine if providing the string in the middle still triggers the button.
@KimPatch ?

[DavidMacDonald]

Where an active control has invisible and visible labels, the invisible label starts with the string of the text used for its visible label.

OR

Where an active control has invisible and visible labels, the invisible label includes the string of the text used for its visible label.

[KimPatch]

I like it – these ensure that visible labels work for speech input.

It would be even better for speech users if the portion of the visible label that's in the invisible label was delineated in some way that can be sensed programmatically because that would address the problem with hidden commands. I was going to say the first one – "starts" would be better, but it sounds like it might work better for screen reader uses to say "ends" rather than "starts". Here's a detailed explanation:

@jnurthen providing the string in the middle still does trigger the button. But delineating the visible label in some way that can be sensed programmatically is an advantage. Triggering anything more than the text of the visible label is a problem – that means some commands that speech input users can say would be hidden. The concept of a hidden command isn't so much a problem for other means of input because you don't usually go pressing key combinations randomly, and if you do, you're aware of what keys you're pressing. However, if you pause before and after a group of words that makes up a command, the speech input engine returns the command, not the words. This is the way speech engines generally work and it generally works really well with a well-scoped command set. But if you have a whole bunch of hidden, extra commands, and worse yet, commands made up of words that you are likely to use to input text on that page, it becomes easy to unexpectedly click a hidden command. And when this happens it can be difficult for users to tell what happened – maybe it's a link and the page disappears. And if the user does get back to the page sometimes text they've entered is gone. So hidden speech commands are minefields. Delineating the visible label portion of the invisible label would give speech engines a way to address this issue. The current choice for the speech input user is to enable web commands that include a bunch of hidden commands, enable the commands with a preceding word like "click", which is hard on your voice, or turn off the ability to click links by speech. Given these choices many users turn off these commands. I have them off now. If I turn them on, and happen to say an isolated word or phrase contained in one of the 307 aria-label tags on this page something unexpected would happen. Whatever might happen is usually not a disaster, and sometimes it is.

[DavidMacDonald]

I think we should keep this text above for the understanding doc. We're really close to a good SC.

... an outstanding topic is where to place the command, at the front, at the end or anywhere in the string. The advantage of at the front (or end) it sounds, is that it gives Speech AT a hook that they could do something with, to help avoid mistakes for their users. This functionality does not yet exist but would be helpful if it did.

On the other hand, having flexibility of being able to place the visible text anywhere in the invisible text string could result in more natural sounding controls and hidden cues and instructions for screen reader users. I have quite a bit of experience with this and often give developers a few extra words to add to invisible labels to help screen reader users.

So we have to weigh possible future features in Speech AT vs more flexibility in the invisible label.

We could also give a best practise of placing the label at the end, while allowing it to be anywhere. We did that kind of thing with "Page Titled", allowing any descriptive title but a best practise of front loading the description of the page followed by the common institution name that is on all pages. I think that is my preference.

Where an active control has invisible and visible labels, the invisible label includes the string of the text used for its visible label.

Note: A best practice is to place the text string at the front [end] of the text string.

What do people think?

[mraccess77]

I agree with Patrick that we should be focusing on the accessible name calculated for the interactive control. In test that I had run in the past the spoken label did not have to Just appear at the beginning but I have not fully tested this.

[jnurthen]

With dragon naturally speaking on windows (I haven't tested other voice recognition packages) you can speak either the label from the base HTML (i.e. The child text node of a button) OR the different programmatically associated label (via aria-label or labelledby) or any word or words from either of those labels in order to activate an element.

…

On Apr 6, 2017, at 19:20, Jonathan Avila ***@***.***> wrote: I agree with Patrick that we should be focusing on the accessible name calculated for the interactive control. In test that I had run in the past the spoken label did not have to Just appear at the beginning but I have not fully tested this. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[patrickhlauke]

backfilling here what i said on the mailing list (which @mraccess77 alludes to above)

Depending on how that's implemented specifically, it may result in that bit of text being announced twice, which is redundant. Say you have

<button aria-describedby="foo">Visible label</button>
<div class="offscreen-hidden" id="foo">Additional invisible text</div>

then screen readers would generally announce the visible label text, followed by the offscreen hidden part.

Same for something like

<button>Visible label<span class="offscreen-hidden"> additional invisible text</span></button>

Requiring authors to always include the visible text in the invisible extra text is possibly not the right approach then. If the intent is to ensure that SRs will also announce the visible label regardless, then probably a better way to phrase it would be that the visible label must always be part of the "accessible name" of the control (with reference to https://www.w3.org/TR/accname-aam-1.1/ ?)

[patrickhlauke]

and while yes, the first example mixes accessible name and accessible description, here are some additional scenarios to test using just accessible name:

• definite passes - the additional text does contain the visible label text at the very start - presumably speech AT lets you trigger these by just announcing the visible label?

<button aria-label="Visible label text and additional invisible text">Visible label</button>

<button aria-labelledby="foo1">Visible label</button>
<div class="offscreen-hidden" id="foo1">Visible label text and additional invisible text</div>

• possible passes - the additional text does contain the visible label text, but not at the very start...is speech AT smart enough to detect/cater for this?

<button aria-label="Additional invisible text containing the visible label text">Visible label</button>

<button aria-labelledby="foo2">Visible label</button>
<div class="offscreen-hidden" id="foo2">Additional invisible text containing the visible label text</div>

• possible failures - accessible name does not contain the visible label text, likely can't be triggered by announcing the visible label

<button aria-label="Additional invisible text">Visible label</button>

<button aria-labelledby="foo3">Visible label</button>
<div class="offscreen-hidden" id="foo3">Additional invisible text</div>

[KimPatch]

@patrickhlauke @DavidMacDonald

Requiring authors to always include the visible text in the invisible extra text is possibly not the right approach then. If the intent is to ensure that SRs will also announce the visible label regardless, then probably a better way to phrase it would be that the visible label must always be part of the "accessible name" of the control (with reference to https://www.w3.org/TR/accname-aam-1.1/ ?)

I think Patrick is right about accessible name being more appropriate than label. It looks like making sure the visible text matches the accessible name would give speech input a way to programmatically enable visible commands without the hidden command problem and without changing the label in a way that's worse for screen reader users. Any downsides to this?

[DavidMacDonald]

I'm OK with ACCESSIBLE NAME... it's a little markup specific, but I think that is fine.

[DavidMacDonald]

There might also be another scenario where the visible label is not an accessible name, its just text next to the control

<span>First Name</span><input aria-label="the name your mother gave you that is not your family name">

Perhaps this:

Where an active control has a visible label (which may or may not be an accessible name) and an invisible accessible name, the invisible accessible name includes the string of the text used for its visible label.

Note: A best practice is to place the text string at the front [end] of the text string.

OR This might be better:

Where an active control has a visible label, the accessible name for the control includes the string of the text used for its visible label.

Note: A best practice is to place the text string at the front [end] of the text string.

[patrickhlauke]

I think the language can be kept high level, a la "The accessible name [of the control, link, whatever] must contain the same text as the visible label" or something along those lines. This high-level wording would clearly make the example with the <span> a fail. in understanding the above can then be given as an example of failure

[DavidMacDonald]

Like this?

Where an active control has a visible label, the accessible name for the control includes the text string used for its visible label.

Note: A best practice is to place the text string at the front [end] of the text string.

Definition of Accessible name https://www.w3.org/TR/accname-aam-1.1/

[patrickhlauke]

sounds good to me. also i'd add to our discussion here that the concept of accessible name is fairly general, not limited to markup (as it relates to the accessibility API). this may require us to grab a high-level description/definition of "accessible name" if it's not already in WCAG 2.0 (presumably can be grabbed/adapted from https://www.w3.org/TR/accname-aam-1.1/)

[DavidMacDonald]

Yes I agree, perhaps something like this:

Accessible Name
The accessible name is the name of a user interface element. The value of the accessible name may be derived from a visible (e.g., the visible text on a button) or invisible (e.g., the text alternative that describes an icon) property of the user interface element. A simple use for the accessible name property may be illustrated by an "OK" button. The text "OK" is the accessible name. When the button receives focus, assistive technologies may concatenate the platform's role description with the accessible name. For example, a screen reader may speak "push-button OK" or "OK button".

[DavidMacDonald]

@mraccess77
Should we update this in the Github repo to reflect the most recent iteration
#68 (comment)

[mraccess77]

@DavidMacDonald It looks like you have made the needed changes to the proposed SC at the top of this page and to proposed SC in the branch. Thanks! Let me know if there is anything else I need to do such as to make a pull request.

[mbgower]

Note: A best practice is to place the text string at the front [end] of the text string.

That note is nonsensical. I think it is supposed to mean:
Note: A best practice is to locate the visible text string at the start of the accessible name.

A few comments on this.

• It needs a new title. "Speech Input" is not descriptive of the SC. I can't think of a good one at the moment, but "Label Names" is at least closer.
• Does it mean we have to change the definition of Accessible Name? As I mentioned before, I think the wording of the term could be tightened up to clarify how aria-labelledby, aria-describedby and other concatenation techniques do or do not constitute part of the accessible name.
• I wonder if we need to indicate what a visible label is. I'm assuming it means persistently visible? For instance, a title attribute would expose a visible label on hover on a desktop system, but I don't think many would consider that visible. On that other hand, I would expect the title value might be part of the consideration here...

[DavidMacDonald]

That note is nonsensical.

I wouldn't say that. The standard is for authors. It's a not that they should include the text string at the front of the label if possible. SC's provide the conditions rather than directives, but notes should be worded in whatever way best communicates of clarifies what needs to be communicated or clarify. Now if we want to remove the directive nature of the label, then we "could" say something like this.

Note: it is best if the text string that is visible, occupy the beginning of the invisible Accessible name.

[KimPatch]

@mbgower @DavidMacDonald
I think nonsensical because it said start [end], which I think was a vestige of a discussion about whether tthe advice should be to put the accessible name at the start or the end. If I'm remembering correctly it might be repetitive for screen reader users if it were at the start. For speech input users might be best if it's at the start, so we might have clashing needs here. What we're trying to get at for speech input users is a way to programmatically determine what the Accessible name is so it can be enabled as a speech command without enabling a whole bunch of extra, hidden words at the same time.

I think the directive wording is clearer.

I think a less speech-centric title is fine.

It doesn't have to be persistently visible – just visible at all. Hover labels of icons without persistent labels are an excellent example. The key is to have a label that's discoverable in some way and for that to be aligned with the Accessible name so that speech input users have a way to know what to say. The other issue is giving speech users a way to avoid having a a bunch of live speech commands that are not discoverable, which can cause much confusion.

[mbgower]

It doesn't have to be persistently visible – just visible at all. Hover labels of icons without persistent labels are an excellent example.

Right, but my point would be that I think there would be a debate on whether title attribute values should be considered part of an element's accessible name. When we're tying in current guidance to a defined term, we just need to be careful of ramifications.

If I'm remembering correctly it might be repetitive for screen reader users if it were at the start. For speech input users might be best if it's at the start, so we might have clashing needs here.

Right, aria-describedby values are appended to a label, by convention. There are also conventions around concatenation. with aria-labelledby. As I also pointed out, there is no mention of such things in the current definition of accessible name. I see problems trying to make the accessible name a required composite of all these things.
At some point, as with screen reader user-created custom labels for objects on a page, i think it's reasonable for power users of speech recognition to address what they view as page curiosities with their own macros. If I'm a regular user of a page and I want to cue an action which I frequently have troubles triggering (i.e., there are homonyms or similar sounding label names, or the label is so long I don't want to say it ever time), a macro IMO is a reasonable solution. The author should not have to be responsible for every curiosity of every implementation of every AT-- or every user preference, until such time as we have a solid framework for supporting that.

[mbgower]

@DavidMacDonald , in regard to your note on my "nonsensical" comment, I merely meant that the note is nonsensical because it makes use of the term 'text string" twice in the same short sentence but each occurence is talking about a different string.

[KimPatch]

@mbgower
I completely agree with you in terms of speech input users using speech macros. I've written and used many speech macros. I'm assuming full use of that indispensable tool.
Understood about ramifications. It's not an improvement if it breaks something else. Maybe it will help to more clearly lay out the speech input user issues:

There are three interlocking issues:

• When I'm writing custom macros I need a way to call the elements I want to click. Keyboard shortcuts work well, but there's not a keyboard shortcut for every link.
• For some tasks, for example, wide-ranging research that touches once on 100 different pages, it's not practical to stop to write custom macros for every page. But I still need to be able to navigate. So It would be awfully useful to call an element by name. That's why speech input software supports some elements of ARIA.
• This brings us to the third issue. Speech input that supports ARIA doesn't work well in practice, because it has a side effect – many hidden commands. These are what trip up speech users. It's not the lack of a good command (including writing your own macro), but that there is not a good way to make a rule about a label. Therefore, the way it this is currently implemented, the user can say any combination of these hidden words, which gets old fast for users, because of the ever present danger of accidentally tripping a hidden command – trying to avoid what you don't know exists. So it would be a step towards solving this problem, and an increase in cognitive ease for other types of users as well, if labels had a consistent order to them.
  I don't have a good macro workaround for Dragon users for the ARIA problem. The workaround I currently recommend is to turn off Dragon's Web plug-in completely.

[steverep]

I realize this one has already passed a CFC, but here are some editorial recommendations to use existing WCAG 2.0 terminology. Not making such changes may lead to confusion.

1. Replace "control" with "user interface component" and link to glossary
2. Link to glossary for "label". Note that the definition of label implies it is visible (i.e. "presented to all users"), so the initial clause may not really be necessary, but a label can also be a text alternative so slight word changes may be needed.
3. Instead of adding an "accessible name" term, we really should be using the existing "name" term in the glossary used in 4.1.2. It's the same thing with a very different definition.
4. Given the last point, we probably need a better handle for this SC than "accessible name", but I'm drawing a blank at the moment.

I think something like this would work:

For active user interface components with labels that include text, the name includes the text of the label.

Also, I think we need to take a hard look at removing this sentence from note 1 of the definition of label:

In many (but not all) cases the name and the label are the same.

Unless I'm mistaken, this criterion would make that sentence non-compliant, correct?

[awkawk]

@steverep Comments noted, we can revisit, but I put it into the editor's draft as approved.

[johnfoliot]

Arriving late to this particular party...

Instead of adding an "accessible name" term, we really should be using

the existing "name" term in the glossary used in 4.1.2. It's the same thing with a very different definition. Yikes yes! Accessible name is already defined elsewhere at the W3C, and specifically in ARIA <https://www.w3.org/TR/accname-aam-1.1/>, where it is mapped to equivalent constructs in all of the platform accessibility APIs, and we should not be attempting to redefine that here.

[steverep]

@johnfoliot, glad you agree but from your reaction I'm inferring you might have it backwards. We're using a new definition here that is synced up with other W3C docs, but WCAG 2.0 4.1.2 has its own very different definition. We need to meld that together eventually.