-
Notifications
You must be signed in to change notification settings - Fork 70
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
WCAG mapping for 'Link has non-empty accessible name' c487ae #1875
Comments
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. 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). 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 (#1854 (review), CG call, and #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 |
In some cases I think they are non-text content. For example, a clickable map of the world with an The Understanding 1.1.1 document has 2 techniques (H24 and F65) relating to area elements and also this text:
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 #2060. |
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 text was updated successfully, but these errors were encountered: