2.5.3: how strict does the match between label and name need to be?

[Jym77]

Raising this from act-rules/act-rules.github.io#1615

---

Long story short,

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

Is this failing 2.5.3? The label has no spaces, the accessible name does, hence they do not strictly match. But speech recognition softwares seem to not care, hence this doesn't really cause an issue.

---

Some summary of the discussion (see the ACT rule issue for details)

• It seems that the common speech recognition softwares can handle the number both as one big number and digit by digit; additionally they also seem to react both when the label or the name is spoken. Since Understanding 2.5.3 is pointing heavily toward speech recognition, this case doesn't seem to create any issues…
• However, the common speech recognition softwares also tend to have a two-steps process (1. display all interactive elements; 2. "click on number 3") which effectively let users of speech recognition interact with any page, maybe not in an ideal way, but still without blocking. If we consider this as good enough, then it is not clear what is the purpose of 2.5.3… (or why it is at level A).
• There are obviously cases were spaces are important and make a difference. The question is whether we should consider that it is always the case, or whether there are cases were removing spaces is OK (that is not just about changing " " (two spaces) to " " (one space), which is likely always OK).
• There are also related cases with numbers being split differently, e.g. "2021" could equally be read as "two thousand and twenty one", "twenty twenty-one" or "two zero two one" and all three would make sense in some context, should the accessible name matching this be "2021", "20 21", "2 0 2 1" (or are all three OK as far as 2.5.3 is concerned)?

[patrickhlauke]

i would suggest that spacing should be mentioned in https://www.w3.org/WAI/WCAG22/Understanding/label-in-name.html as part of / in addition to "Punctuation and capitalization" - essentially saying that it can be ignored unless a space (including any other spacing characters like unicode hairline space characters, or tabs, carriage returns, line feeds, etc) changes the meaning. this may introduce a bit of "squishiness" to this rule, and it still won't fully account to things like "what if adding spaces leads explicitly to reading out a string character by character/number by number)

[alastc]

The normative bit we're working with is "the name contains the text that is presented visually".
And "text" is a "sequence of characters that can be programmatically determined, where the sequence is expressing something in human language"

I guess the angle is that for a series of numbers where spacing is irrelevant, the expression is the same in human language terms. I.e. if "34523" is not 34 thousand etc, it doesn't matter whether it has spaces, full-stops, commas or semi-colons between them.

So we could add, under the Punctuation and capitalization heading, something like:

For numbers which can use various forms of punctuation without meaning something different it is not necessary for the punctuation to match. For example, if a phone number were presented visually as "01234 567 890", it could have a name of "01234 567 890", or "01234.567.890", or "01234567890", or "0 1 2 3 4 . 5 6 7 . 8 9 0".

[patrickhlauke]

it goes beyond numbers though. it's probably worth adding some allowance/statement about various forms of space/line break/etc in general

[alastc]

What would it be beyond numbers? You can't break up words randomly without affecting what it expresses in human language. E.g. "Compose email" isn't the same as "C O M P O S E Email".

[patrickhlauke]

you can have more than one space, or a hairline character, or a line breaks, in between words which don't affect how AT will interpret things. same as punctuation.

Compose email vs Compose    email vs Compose<br>email

[WilcoFiers]

@kengdoj asked me to look into this again. I think there are multiple things going on which makes this confusing, so I'll try to tease them apart. Looking at Aron's test results, it seems this is the situation:

Tool	AccName	Text
Dragon	Yes	Yes
Voice Control	Yes	No
Voice Access	No?	Yes

I think there are two problem scenarios to consider under 2.5.3. 1) Text links with aria-label adjusting the name, and 2) active images of text, where the accessible name doesn't match the text on the image. The ACT rule only covers scenario 1. But scenario 2 is a valid accessibility problem -- arguably not a level A violation though because of the alternative, but that's a given now.

On text links (scenario 1), I think we're facing an accessibility support question. If you're only interested to support tools that accept the link text, then it seems to me that failing this rule does not result in a failure of SC 2.5.3. If we care to support Voice Control though, we must support doing this exclusively by the accessible name.

The number question

Let's focus in on Voice Control only. If you have a number like "2023", there are different ways to call that:

• "Two thousand twenty three"
• "Twenty Twenty three"
• "two o two three"

What that does is basically allow a long number to be grouped in different ways: "2023", "20 23" or "2 0 2 3". That those are supported will be expected from the user of Voice Control. So then if you use aria-label="2 0 2 3", suddenly other number groups no longer work. It seems to me that that's basically the same error as if you'd used aria-label="two zero two three", which we explicitly prohibit.

In conclusion

So I'm of the opinion that spacing of numbers matters under SC 2.5.3. If you did alt="2 0 2 3" of an image with "2023" I'm confident to say that fails SC 2.5.3. So unless you're not supporting Voice Control, spaced out numbers in aria-label fails the SC, even if the link text isn't spaced out.

The only time you can space numbers in the accessible name is if they are spaced in the same way in the link text. I don't think you can omit it either.

We need to update the accessibility support section of this rule. This rule seems to be one that depending on support, it may not fail the SC at all. We have a few other rules where failing it depends on support. If someone wants to advocate for deprecating this rule based on its support, that's a conversation we could have. But given the current data we have my vote would be to keep this rule.

Side note: An interesting side question that I don't have a suggestion on is what to do with number separation. For example: <button aria-label="12345">12.345</button> I'm not sure whether something like that would be a problem.

Side note: We may want to consider using secondary requirements for rules like this, where whether the SC fails when the rule does depends on accessibility support. Separate conversation, but probably worth having.

[patrickhlauke]

interestingly, i'm almost inclined to say that the "does the accName match/contain the exact string that is presented visually or not" is not a straightforward technical match() type test, but rather a "fuzzy match" that needs to take into account various human nuances (which is of course not ideal for those who have an interest in running a test for this SC as purely an automated test that gives a pass/fail, rather than a "hey, we spotted these, you need a human to verify").

[WilcoFiers]

There's fuzzyness to it. But I don't think it's "human nuance". It's more just what are common "allowances" these tools have added in. Allowing different pronounciations of numbers is one. "2002" vs "20 23". Chunking up numbers, "12.345" vs "12345" possibly. Maybe acronyms too. "WAVE" vs "W A V E"

It's going to be a finite list of things the rule needs to account for. But my guess would be that it's probably not even a very long list. We may not have thought of all of them. But we have a few, and if more come up, we can add them. That's exactly why these rules are not normative. We don't want to rely on WCAG-esk vagueness to handle edge cases. We explicitly list all the ones we know, and add when we find new ones.

[patrickhlauke]

it'll also be weird/interesting if a user does try to announce/vocalise punctuation marks or special characters... ("hash something", "number something", "octothorpe something"). likely this will come down to each tool's heuristic...

it's yet again a WCAG SC that, on its face, was simple and straightforward, but does hit up problems when it crashes against the reality of both web content in the wild, assistive tech and its heuristics, and users...

[detlevhfischer]

@WilcoFiers - you talk about Aron's test results above - are these public? If so, a link would be great. Without context I have trouble understanding the small table in your posting.

One issue around "Label in Name" that would be of additional interest is the practicalities of including longish accNames corresponding to images of text (think of a logo with a strapline "ACME - we help you develop a better future". Related might be text labels followed by instructions, as in "First name (include all your first names)"

What I am wondering about (and this may be covered in extant voice input tests already) is whether it actually works to say "click ACME - we help you develop a better future" - i.e. will software like VoiceControl or Dragon patiently listen till some pause of voice input occurs, and then process / try to match the input, or apply some cut-off point?
I imagine - but this is mere conjecture - that voice inputs are predominantly short. If they also work better when the accName is kept short, that may even suggest that from a practical utility perspective, it might be better to just use "ACME" as accName (thus technically failing 2.5.3).

Consider also that the author may have decided to include "Logo" at the beginning of the accName: "Logo ACME - we help you develop a better future". This would be a technical pass of 2.5.3 but might not work well for voice control (again mere conjecture).

We are currently planning some tests with voice control users using Dragon on a day-to-day basis to improve the empirical evidence regarding 2.5.3 issues.

[WilcoFiers]

@detlevhfischer Sorry, yes. They're in the original ACT thread: act-rules/act-rules.github.io#1615 (comment)