act-rules
WCAG mapping for 'Link has non-empty accessible name' c487ae
The mapping for this rule is:
4.1.2 Name, Role, Value (Level A) 2.4.4 Link Purpose (In Context) (Level A) 2.4.9 Link Purpose (Link Only) (Level AAA)
but failed example 9 is also a 1.1.1 failure:
https://act-rules.github.io/rules/c487ae#failed-example-9
This example matches the 1.1.1 failure condition in F65 https://www.w3.org/TR/WCAG20-TECHS/F65.html
The rules maps to SC that are guaranteed to fail if the rule fails, to maintain the fail-on-fail relationship and prevent false positives.
That is, we guarantee that when the rule fails than 2.4.4, 2.4.9 and 4.1.2 also fail. If we added a 1.1.1 mapping, we would have a lot of false positive where the rule can fail on a page where 1.1.1 is satisfied, but the mapping would still say "if the rule has at least one failed outcome, then 1.1.1 fails", which would be incorrect.
This is why this rule does not map to 1.1.1. It is possible that failing this rule creates a failure of 1.1.1, but it is not guaranteed.
That's fine. Just wanted to flag that failing SC 1.1.1 in addition to the other SCs for Example 9 is correct, so the conformance mapping cannot require that only 4.1.2, 2.4.4 and 2.4.9 are flagged for Example 9
That's an awfully good point 🤔
On one hand, Understanding ACT Consistency says that the tool should report all the SC that are expected to fail but doesn't mention reporting more SC (for all or some of the test cases). On the other hand it seems that on some rule Alfa has a partially consistent mapping only because it reports too many SCs…
But it may indeed be the case that reporting "too many" SCs is actually fine for some (or even all…) failed test cases. And we should probably consider the implementation as consistent in these cases.
I do feel this ties a bit with the discussion we had around removing SCs for some rules (https://github.com/act-rules/act-rules.github.io/pull/1854#pullrequestreview-1001009558, CG call, and https://github.com/act-rules/act-rules.github.io/pull/1862 for the latest occurrence). Because a solution could be to say "this rule must report A.B.C and may report X.Y.Z".
This is different from the interpretation we took when we wrote this rule. I don't think area elements should fail 1.1.1, they aren't the non-text content, they are links on top of non-text content. I think this technique is wrong. We can debate whether or not this was the correct decision, but the intent was to explicitly not fail area elements under 1.1.1. If we want to change that we may need to pull area elements into a separate rule, in the same way that we put image buttons into a separate rule.
I don't think that's the correct interpretation though. If you take a native link with no content, give it an accessible name, and position it on top of an image to simulate the effect of an area element - I don't think that suddenly then becomes non-text content. Similarly, I don't think links inside SVG are non-text content, regardless of if those have <text> inside them or not.
I don't think area elements should fail 1.1.1, they aren't the non-text content, they are links on top of non-text content
In some cases I think they are non-text content. For example, a clickable map of the world with an <area shape=poly> for each country. There's a 1-to-1 mapping between each area outline and each country shape on the map. The fact they're in an area element is an implementation detail - you could also implement the world map as an SVG with an <a> element round each country shape. WCAG is technology agnostic, so there shouldn't be a difference in failures for 2 world maps that are implemented differently, but look and behave identically.
The Understanding 1.1.1 document has 2 techniques (H24 and F65) relating to area elements and also this text:
For non-text content that is a control or accepts user input , such as images used as submit buttons, image maps or complex animations, a name is provided to describe the purpose of the non-text content so that the person at least knows what the non-text content is and why it is there
My understanding of this is the image map areas accept user input (clicks) so need they text alternatives.
If the missing area alt doesn't fail 1.1.1, how could you satisfy 1.1.1. for each clickable country on the world map?
SC 1.1.1 should be mapped as a secondary requirement.
This rule was used as Example 9 in the ACT Rules Format draft update.
Update will be made by https://github.com/act-rules/act-rules.github.io/pull/2060.