Notes in the label should not have to be part of the AccName (2.5.3)

[JAWS-test]

I wonder if it would be useful to add in the Understanding to 2.5.3 that hints (that are in the visually visible label) do not have to be part of the Accessible Name to satisfy SC 2.5.3.

Example:

• Formatting hint (label: "Date (yyyy-mm-dd)" - AccName "Date" would be sufficient if input hint is transmitted elsewhere, e.g. as description).
• Accesskey (label "Save (Alt+S)" - AccName "Save" would be sufficient if accesskey is transmitted elsewhere, e.g. via aria-keyshortcuts)

Reason:

• Accessible Name should be concise.
• Accesskeys should be transmitted programmatically rather than in text form
• Input hints should be transmitted as description rather than as part of the name
• no one will try to call the element by its accesskey or input hint when using speech input

[bruce-usab]

Another reason maybe worth mentioning in Understanding is that any punctuation in Accessible Name makes it problematic for human using a voice recognition to predict/guess.

[mbgower]

@JAWS-test please review the changes in PR #2725 to see if you believe this issue has been addressed.

@bruce-usab, the Understanding document already has some information on punctuation being optional. Do you find that insufficient?

[JAWS-test]

@mbgower Thank you for your update - I think it's good. Just a small note: maybe we should recommend required instead of aria-required because of https://www.w3.org/TR/using-aria/#rule1

[mbgower]

Thanks @JAWS-test. I've done a slight edit to list that first.

[bruce-usab]

. Understanding document already has some information on punctuation being optional. Do you find that insufficient?

Instead of punctuation being optional, I think it might be better to say that it is best practice to avoid including punctuation in AccName.

But please note that I do not personally have enough recent personal experience with voice recognition to assert just how problematic is punctuation in AccName, let alone to have done any experimentation. Difficulties I am aware of are second hand, and could be due to a number of factors. But even an apostrophe (which could be one of three characters) seems like it might have been the culprit.

[patrickhlauke]

I think it might be better to say that it is best practice to avoid including punctuation in AccName.

that would potentially lead to lots of unnecessary work for authors who then try to rewrite natural AccNames to try and not have punctuation. for instance, in very common situations like

<label for="foo">What's your favourite cheese?</label>
<input type="text" id="foo">

i think that type of advice would be misguided.

[mbgower]

Yeah, I agree with @patrickhlauke, I think it's better just to make punctuation not count in the assessment. This is what the test says for https://www.w3.org/WAI/WCAG22/Techniques/general/G211

Tests
Procedure

1. For input controls, examine each input that has adjacent text which serves as its label
2. For each input, check that the entire string of text (disregarding letter case and punctuation) matches the accessible name for the input, according to the accessible name computation
3. For buttons, links, menus and other non-input controls, examine each control that contains text which serves as its label
4. For each non-input control, check that the entire string of text (disregarding letter case and punctuation) matches the accessible name for the input

That test should be updated to also disregard parenthetical content, as per the PR. I'll add that to the PR...

[mbgower]

Change added to #2725

[bruce-usab]

I agree with not suggesting to authors that they should rewrite natural AccNames as to try to not have punctuation. The label for="foo" above is a good counter example!

I was thinking of situations where the label used for AccNames is tied to an image of text or other situations where its only available in source code and the text that is presented visually is not programmatically generating the AccName.

[patrickhlauke]

I agree with not suggesting to authors that they should rewrite natural AccNames as to try to not have punctuation. The label for="foo" above is a good counter example!

I was thinking of situations where the label used for AccNames is tied to an image of text or other situations where its only available in source code and the text that is presented visually is not programmatically generating the AccName.

if natural accnames that contain punctuation don't cause problems (which, anecdotally from speech users, is the case), then neither should "forced" accnames (with something like aria-label)

[mbgower]

@mraccess77 This is one of the two issues being addressed by #2725