Visible label is part of accessible name (2ee8b8): Expectation seems to have unintended consequences #1458
Comments
|
Both Alfa, aXe, and QualWeb concatenate the text nodes so I'm guessing we'll want to reflect that in the rule 🙈 That does bring up an interesting case though for code such as this: <div role="button" aria-label="Hello world">
<p>Hello</p><p>world</p>
</div>That button visually renders as two separate words, <a href="#" aria-label="Some article by John Doe">
<h6>Some article</h6>
<p>by John Doe</p>
</a>When minified, the concatenated text will be |
|
I tried to dig up the use case for this, but I can't find it. I remember why we did it though. If we're concatenating, we need to make the assumption that the text will be part of the same piece of text, and that it isn't rearranged with CSS in some way to appear in a different order. |
|
Example 2 of Failure technique F96 seems to close the case of adding text in the middle of a label to create an accessible name (which, as far as I understand, is the shopping cart example @WilcoFiers mentioned during call):
|
|
I have some ideas on this. Maybe I could volunteer. It seems to me that this rule needs a normalization algorithm, and to run it on both the label and the name, then do a substring check. Something like this: To normalize a label or name:
Then do the check "is the normalized label a substring of the normalized name"? I'll have to check how the above algorithm behaves on all the cases in #1615. I think that this algorithm will do okay and err on the side of 'no false positives'. There are cases there which will fail the rule according to this algorithm, and which speech-to-text accepts. That might be unavoidable. |
|
I think that this should globally work.
This might actually depends on its |
|
That's an interesting discussion over there at the W3C. Based on that, how about something like this: Let 'label' be the inner text of the target element as per the innertText algorithm. ('label' is a string.) To normalize a string:
Then do the check "is the normalized 'label' a substring of the normalized 'name'"? |
|
Here's an updated idea for an algorithm (to deal with this case: Let 'label' be the inner text of the target element as per the innertText algorithm. ('label' is a string.) Algorithm to tokenize a string:
Then do the check: is the tokenized 'label' a sublist of the tokenized 'name'? |
|
Updating my idea for an algorithm again. And adding some test cases, from this issue and others. Test cases:
Algorithm: Let 'label' be the inner text of the target element as per the innertText algorithm. ('label' is a string.) Algorithm to tokenize a string:
Then do the check: is the tokenized 'label' a sublist of the tokenized 'name'?
|
|
Another draft: Test cases:
Algorithm: Let 'label' be the inner text of the target element as per the innertText algorithm. ('label' is a string.) Algorithm to tokenize a string:
Then do the check: is the tokenized 'label' a sublist of the tokenized 'name'?
|
|
@dan-tripp-siteimprove in the last CG group meeting we agreed to update some of those examples. These are the ones:
The reasoning is summarised in Jean-Yves' comment on issue 1615 |
|
Okay, I think I'm starting to get it. Thank you. I'll try to follow up soon. |
|
Here's another draft, in light of these recent discussions: Test cases:
The algorithm below implements all of the "desired behaviours" above correctly, I think. Algorithm: Let 'label' be the inner text of the target element as per the innertText algorithm. ('label' is a string.) To tokenize a string:
Then do the check: is the tokenized 'label' a sublist of the tokenized 'name'?
|
The expectation currently reads:
According to this expectation, something like the following passes the rule:
That seems a little odd 🤔 Shouldn't the rule instead be looking at the concatenation of the data of the relevant text nodes?
Summoning @WilcoFiers as you authored #1419.
The text was updated successfully, but these errors were encountered: