-
Notifications
You must be signed in to change notification settings - Fork 237
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2.5.3: how strict does the match between label and name need to be? #1936
Comments
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) |
The normative bit we're working with is "the name contains the text that is presented visually". 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:
|
it goes beyond numbers though. it's probably worth adding some allowance/statement about various forms of space/line break/etc in general |
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". |
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.
|
@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:
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 questionLet's focus in on Voice Control only. If you have a number like "2023", there are different ways to call that:
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 In conclusionSo I'm of the opinion that spacing of numbers matters under SC 2.5.3. If you did 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: 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. |
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 |
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. |
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... |
@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? 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. |
@detlevhfischer Sorry, yes. They're in the original ACT thread: act-rules/act-rules.github.io#1615 (comment) |
My guess is that Speech recognition would do fuzzy match and see that "Click ACME" can only match the accessible name "Logo ACME - we help you develop a better future" (unless all clickable have "ACME" in their name, in which case you probably won,t say "click ACME" anyway…) I'm somewhat guessing that by the fact that 2.5.3 require the visible label to be included in the accessible name, which suggest that more stuff in the name is OK, hence that stuff in the name can be ignored by the tools. That is |
This issue is labelled as a discussion, so we’re moving this to Discussions. There doesn’t seem to be an update to make to the documentation, but if that changes, we can move it back to the issues list. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Raising this from act-rules/act-rules.github.io#1615
Long story short,
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)
" "
(two spaces) to" "
(one space), which is likely always OK).The text was updated successfully, but these errors were encountered: