act-rules
"Links with identical accessible names and context serve equivalent purpose" [fd3a94]: Failed Example 1 should pass.
(splitting from #1879 since it is taking a different direction) Failed Example 1 is:
<html lang="en">
<p>
We are on social media:
<a href="https://act-rules.github.io/">ACT rules</a>
<a href="https://www.w3.org/community/act-r/">ACT rules</a>
</p>
</html>
However, in that case, the links purposes are ambiguous to users in general, which is a valid exception of 2.4.4
We've discussed this a bit while discussing #1879, but that issue took the direction of refining the definition of "context", which won't fix this problem.
I'll work on creating a non-semantic structure with image and "Read more" text that allow sighted users to visually associate the elements, but keeping the same semantic context for AT users.
Something like:
<div style="display:flex; justify-content:space-around;">
<img src="..." alt="image context 1">
<img src="..." alt="image context 2">
</div>
<div style="display:flex; justify-content:space-around;">
<a href="...">Read more</a>
<a href="...">Read more</a>
</div>
But I don't think that updating the Failed Example solves the problem. As long as the code (currently) in Failed Example 1 is failing the rule, the rule is problematic. If we update the example to be an actual failure, but the rules keep failing the old code, then it is still a False Positive.
But the rule has an assumption stating:
This rule assumes that the purpose of the links with identical accessible names and context would not be ambiguous to users in general, which is the exception mentioned in Success Criterion 2.4.4 Link Purpose (In Context). If the links are ambiguous to users in general, users of assistive technologies are not at a disadvantage when viewing the links, which makes it more of a general user experience concern than an accessibility issue.
Therefore, we decided to replace the example with one that would visually present different contexts, but the same context from an AT perspective, so that we don't have an example that challenges the assumption.
True. I'm challenging the assumption as to how often it is actually met. Additionally, our Test case design document states:
The decision of what the edge cases to test will be, should be based on issues in real-world examples. (emphasise not mine)
I'm not sure how "real world" this new example is.
Out of the 5 Failed Examples, only Failed Example 4 is currently a failure of 2.4.4 (by presenting different visual and accessible content).
I'm not sure how "real world" this new example is.
It's for sure not usual, but still happens to see old "table layouts" with this kind of failure. It's even more frequent something like:
<div>
<a href="..." style="background-image: url('pdf.png'); padding-left:30px;">Download file</a>
<a href="..." style="background-image: url('doc.png'); padding-left:30px;">Download file</a>
</div>
or
<div>
<a href="..."><img src="pdf.png" alt="">Download file</a>
<a href="..."><img src="doc.png" alt="">Download file</a>
</div>
For sure they are also failing 1.1.1, but in this case the rule apply. Honestly I don't know statistically how much this happens, but as it still happens in my opinion it makes sense to list them (of course fixing passed and failed examples to reflect the real intent of the rule).
@giacomo-petri while you are addressing this, check if you can find a good way to move parts of the assumption about the links not being ambiguous to users in general, to the applicability or expectation of the rule