Visible label is part of accessible name (2ee8b8): extra spaces in name might be OK.

Jym77 commented 3 years ago

Related to #1458 but somewhat different…

We've encountered a case where a phone number was announced digit by digit:

<a aria-label="Call 1 2 3. 4 5 6. 7 8 9 0." href="tel:1234567890">123.456.7890</a>

This currently fails the rule because the visible text is not included in the accessible name (due to the internal spaces, only the leading/trailing ones are trimmed).

Yet, this is arguably OK and might even be a better experience for screen reader users (to have the digits announced one by one rather than as part of a larger number).

dd8 commented 3 years ago

For numbers this might be true, but for words there are definitely cases where adding / removing / moving spaces completely changes the meaning. For example:

speed of art != speedo fart justice != just ice

More examples here: https://english.stackexchange.com/questions/188076/term-for-words-which-change-meaning-when-a-space-is-added https://www.boredpanda.com/worst-domain-names

Edit: a related issue is multiple spaces normalised to a single space preserves the meaning, but the current rule doesn't cover this. For example this fails the rule, but probably shouldn't:

<button aria-label="Next Page in the list">Next   Page</button>

dd8 commented 3 years ago

And an example Fibonacci sequence where the spaces are important:

0 1 1 2 3 5 8 13 21 34 != 0112358132134

WilcoFiers commented 3 years ago

I have no idea what to do with this one... but we can discuss. Interesting scenario.

dd8 commented 3 years ago

Does anyone know how speech input works reacts when the same number is spoken in different ways?

2.5.3. Label in Name targets speech input, so speaking the visible label text should activate the control, but that might be difficult with sequences of digits. How digit sequences are spoken depends on context (in Japanese and English at least) and there's often no suitable semantic markup for this context.

For example the digits "2021" would usually be spoken in English as:

"twenty twenty-one" or "two thousand and twenty-one" if it's a year
"two zero two one" if it's a PIN
"two thousand and twenty-one" if it's an integer

In Japanese it's even more complicated - how numbers are spoken depends on the shape of the thing you're counting: https://www.learn-japanese-adventure.com/japanese-numbers.html

Jym77 commented 3 years ago

Yes, I agree with mark that speech recognition might be the important factor here (given that it is a SC of Principle 2: Operable).

Would "Call one hundred and twenty-three four hundreds and fifty-six" (the visible label) be connected to "Call one two three four five six" (the accessible name)?

Does the fact that these are numbers written with digits changes how speech recognition work? (versus numbers written in plain text) (e.g. Stuff that happened in <a href="#2021" aria-label="twenty twenty-one">two thousand twenty-one</a> would definitely fail the rule but is it more incorrect that Stuff that happened in <a href="#2021" aria-label="20 21">2021</a> ?)

I have no clue what speech recognition software accepts 😕

dd8 commented 3 years ago

If you have macOS 10.15 or later you can enable Voice Control in Preferences. https://support.apple.com/en-gb/HT210539

Activating links and controls labelled with numbers in Voice Control looks problematic since VC also uses numbers to give quick access to menu items (e.g. "Click 1" instead of "Click Apple Menu. Click About this Mac").

VC also uses numbers to handle controls/links with duplicate names. That's going to be difficult if there are duplicate links only containing digits:

<a href="1a">1</a>
<a href="1b">1</a>

If you say "Click one" with VC activated, this displays a number next to the link that's supposed to let you pick an option using "Click one" or "Click two":

1 (1) 1 (2)

ajanec01 commented 3 years ago

I've done a test for

<a aria-label="Call 1 2 3. 4 5 6. 7 8 9 0." href="tel:1234567890">123.456.7890</a>
<a href="tel:2021" aria-label="20 21">2021</a>
<a href="tel:2021" aria-label="twenty twenty-one">two thousand twenty-one</a>

using Dragon with FireFox, Dragon with Chrome, Voice Control on Safari (iOS), Voice Access on Chrome (Android). See the live page for the test cases.

Dragon

Looks like Dragon does not care what is an accessible name and what is the visible label. For <a aria-label="Call 1 2 3. 4 5 6. 7 8 9 0." href="tel:1234567890">123.456.7890</a> I gave two commands (as can be noticed in the attached images):

"click one hundred and twenty three",
"click call one two three".

Both commands have worked (you can see the browser alertdialog that tries to dial the number". The same happened with the other two examples, all of the following commands have worked for words and numbers:

"click twenty twenty one",
"click two thousand twenty one".

Voice Control

Different results, VC is only concerned with an accessible name. So, for example, saying "tap two thousand twenty one" does not work but a "tap twenty twenty one" does work for <a href="tel:2021" aria-label="20 21">2021</a>.

Voice Access

VA does not work well with words that express numbers but for the most part reacts to the accessible name and visible label. <a href="tel:2021" aria-label="twenty twenty-one">two thousand twenty-one</a> does not work at all. However, <a href="tel:2021" aria-label="20 21">2021</a> works on "click twenty twenty one" or "click two thousand twenty one".

Fallbacks

All of those have fallback mechanisms. For Dragon, commands such as "click links" or "show links" display numbers next to links so the following command "click one" can activate the link the user has intended to activate in the first place, effectively a two-step process instead of a single step. Alternatively, "mouse grid" would also work. clickLink showLinks mouseGrid

For VC, "show names" and "show numbers" do the same as "click links" in Dragon. The same goes for "show numbers" in VA.

A two-step process is not ideal but probably not a deal-breaker. For screen reader users, white spacing numbers could definitely help. Would be good to get the opinion of others but in my view, I don't think this is an issue.

Jym77 commented 3 years ago

🤔 If most STT (speech-to-text) software react to both label and name, then I start to think either 2.5.3 is pointless, or there is more to it than just STT… Similarly if we consider that the fallback mechanism of these technologies is enough. Then 2.5.3 is more of a comfort thing (so you don't need to default to fallback mechanism) than a real need and should be AAA rather than A…

On one hand, it does make sense for STT software to react to both label and name. The mismatch is likely a common mistake and since STT concerns both sighted and non-sighted users, catering to both is a good idea. So if, in case of <a href="#" aria-label="lorem">ipsum</a>, the STT software decides to react to both "click lorem" and "click ipsum", that is actually a fairly good idea… Which in turns makes 2.5.3 pointless for STT (might have some other bits to it).

Adding to the confusion with Specification for Spoken Presentation in HTML that was pointed by @ajanec01 during last call, and CSS Speech Module which I just found (none of them seems to have any support currently).

So, if I get the idea correctly, <a href="#" style="speak-as: digits">123</a> is supposed to be read as "one two three" rather than "one hundred and twenty three". This is not directly related to 2.5.3 or our rule, but certainly makes the full STT problem even trickier. Now, sigthed and non-sigthed users do perceive the same bit differently, even though it is totally satisfying 2.5.3, and so STT software should react to both…

…and let's not get started with <a href="#" style="speak-as: digits" aria-label="456">123</a> which I have no clue if it's supposed to be announced as "four five six" (applying speak-as to the name), "four hundred and fifty six" (the name) or even "one two three" (speak-as being for the label…)

EmmaJP commented 3 years ago

We advise colleagues at the BBC not to adjust spelling or spacing in aria labels to improve pronunciation by screen readers, because it also has an impact on braille readers. Also screen reader users can adjust how numbers are read out in the settings, and if something is unclear can ask a screen reader to read individual numbers/characters.

For something like the Fibonacci numbers the spaces do matter, but for something like a phone number or words unexpected or incorrect spaces have an impact.

daniel-montalvo commented 3 years ago

VoiceOver picks up the spaces included in the aria-label when you reach the link via VoiceOver navigation. If you interact with the link and read character by character, VoiceOver does seem to ignore the spaces. The same happens with the braille output.

I've done a test for
<a aria-label="Call 1 2 3. 4 5 6. 7 8 9 0." href="tel:1234567890">123.456.7890</a>
<a href="tel:2021" aria-label="20 21">2021</a>
<a href="tel:2021" aria-label="twenty twenty-one">two thousand twenty-one</a>
using Dragon with FireFox, Dragon with Chrome, Voice Control on Safari (iOS), Voice Access on Chrome (Android). See the live page for the test cases.

Dragon

Looks like Dragon does not care what is an accessible name and what is the visible label. For <a aria-label="Call 1 2 3. 4 5 6. 7 8 9 0." href="tel:1234567890">123.456.7890</a> I gave two commands (as can be noticed in the attached images):

"click one hundred and twenty three",

"click call one two three".

Both commands have worked (you can see the browser alertdialog that tries to dial the number". The same happened with the other two examples, all of the following commands have worked for words and numbers:

"click twenty twenty one",

"click two thousand twenty one".

Voice Control

Different results, VC is only concerned with an accessible name. So, for example, saying "tap two thousand twenty one" does not work but a "tap twenty twenty one" does work for <a href="tel:2021" aria-label="20 21">2021</a>.

Voice Access

VA does not work well with words that express numbers but for the most part reacts to the accessible name and visible label. <a href="tel:2021" aria-label="twenty twenty-one">two thousand twenty-one</a> does not work at all. However, <a href="tel:2021" aria-label="20 21">2021</a> works on "click twenty twenty one" or "click two thousand twenty one".

Fallbacks

All of those have fallback mechanisms. For Dragon, commands such as "click links" or "show links" display numbers next to links so the following command "click one" can activate the link the user has intended to activate in the first place, effectively a two-step process instead of a single step. Alternatively, "mouse grid" would also work.

For VC, "show names" and "show numbers" do the same as "click links" in Dragon. The same goes for "show numbers" in VA.

A two-step process is not ideal but probably not a deal-breaker. For screen reader users, white spacing numbers could definitely help. Would be good to get the opinion of others but in my view, I don't think this is an issue.

Jym77 commented 3 years ago

It seems that some extra spaces are OK, but not all: https://github.com/w3c/wcag/issues/1936#issuecomment-868676987 We should discuss what to do with the rule.

carlosapaduarte commented 1 year ago

@ajanec01 we're finally getting to discuss this in CG meetings! Would you be able to rerun your tests with updated versions of the voice assistants you used originally?

Jym77 commented 1 year ago

I think Wilco's closing argument was pretty good: What would one write

<a aria-label="Call 1 2 3. 4 5 6. 7 8 9 0." href="tel:1234567890">123.456.7890</a>

The reason is to give a "better" experience to screen readers users by reading numbers one by one. But:

Screen readers can already be configured for that. So no need to do it.
If you want to do it, it can be done other ways, namely using the spoken HTML specs (note: I do not know the actual support for it).
Doing so is taking away the choice from the user. What if a screen reader user wants it to be read as big numbers?

So, ultimately, this is not really a good idea and might hamper the screen reader users more than helping them, defeating its own purpose. So, I feel it is OK to be strict until we find cases where being lenient would really be needed.

act-rules / act-rules.github.io