Move secondary requirement texts out of the background #2060
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -12,7 +12,6 @@ accessibility_requirements: | |
| inapplicable: further testing needed | ||
| wcag20:1.4.9: # Images of Text (No Exception) (AAA) | ||
| forConformance: true | ||
|
There was a problem hiding this comment. While I understand why this has been removed (together with the Background note), I feel this requires a specific PR just to make 1.4.9 a primary requirement instead. (implementer hat on), making the requirement primary may make my implementation "partially consistent" if it doesn't already report it. That requires me to update my report. An easy fix, but I'd rather track that change to an ACT PR that focuses on it. There was a problem hiding this comment. The real reason I did this is because I couldn't come up with an explanation of why this was secondary. If you have one I don't mind putting it in, but I don't think there's anything I can put in here. This rule assumes that the difference between 1.4.5 and 1.4.9 doesn't occur, and so the rule maps to those criteria the same way. I can put this into a separate PR, but I can't merge this one until that separate PR would then be merged. I did it this way to avoid introducing a blocking PR. Are you okay with that @Jym77? There was a problem hiding this comment. Also, we made 1.4.6 a secondary requirement for the 1.4.3 rule, while it always fail. How is that case different? There was a problem hiding this comment. See above. This rule assume there is the difference between 1.4.5 and 1.4.9 never occurs. That's why we don't have two rules for image-no-text. There is no difference in how we test 1.4.5 and 1.4.9. For color contrast the numbers are different, and so we have two different rules. There was a problem hiding this comment. I'm confused 😕 Back in #1920 when we added secondary requirements, part of the reasoning in the PR description was:
This, in turn, linked to w3c/wcag-act-rules#134 which has pretty much the same description:
The later is marked as fixed by w3c/wcag-act#531 which updates the format (to allow secondary requirements) but doesn't change the tool consistency checking by discarding AAA mapping for AA tools or something like that. How will that not recreate the same situation? There was a problem hiding this comment. There are two reasons why an implementation may not report an accessibility requirement and still be consistent:
I think what you were expecting is for secondary requirements to cover both situations. That's not the intent. This is exactly an example of why that difference is necessary. If an implementation supports AAA, then it must report both 1.4.5 and 1.4.9 as not satisfied when this rule fails, Otherwise it is partially consistent. An implementation that only covers AA is not required to report 1.4.9. Whether or not it can report 1.4.9 is an open question, and is possibly a topic for TPAC. There was a problem hiding this comment. I still do not understand why 1.4.9 shouldn't be a more strict secondary requirement 🤔 How is the 1.4.5/1.4.9 case (and the 2.1.1/2.1.3 one) different from the 2.4.4/2.4.9, the 1.4.3/1.4.6, the 1.2.3/1.2.5-1.2.8, or the 2.2.1/2.2.4-3.2.5 ones? I won't block the PR due to that, it seems I'm misunderstanding something. I guess we can talk through that at TPAC. There was a problem hiding this comment. I'll take another crack at explaining, but yes, lets take this to TPAC. The way I think of it, and why I ended up doing it this way is because this rule effectively treats those 1.4.5 and 1.4.9 as identical criteria. The assumption effectively says there is no difference, and so they are tested in the same way, and only require one rule. Compare that to 2.2.1 / 2.2.4. There are two rules for it. One with the 20 hour exception and one without. Similarly 1.4.3 / 1.4.6. Two rules, one with a 4.5:1 contrast, and one with a 7:1 contrast. I can explain why the rule for 1.4.3 is less strict than 1.4.6: The number is lower. I can explain why the rule for 2.2.1 is less strict than 2.2.4: The rule has a 20 hour exception. There is no difference between how 1.4.5 is measured and how 1.4.9 is measured. The rule assume it. |
||
| failed: not satisfied | ||
| passed: further testing needed | ||
| inapplicable: further testing needed | ||
|
|
@@ -56,7 +55,7 @@ There are no accessibility support issues known. | |
|
|
||
| ## Background | ||
|
|
||
| This rule is designed specifically for [SC 1.4.5 Images of Text][sc1.4.5]. There are however only minimal differences between this criterion and [SC 1.4.9 Images of Text (No Exception)][sc1.4.9]. The two differences are that customizable images of text are allowed, and that images of text are allowed when the presentation cannot otherwise be achieved. These scenarios are so rare the rule ignores them as part of the assumptions, and so the [accessibility requirements mapping](#accessibility-requirements-mapping) of these two criteria is the same. | ||
|
There was a problem hiding this comment. While I agree that SC 1.4.5 and 1.4.9 are very similar, I do not agree with characterization of "only minimal differences" because using the Essential exception for logotypes is very common. But maybe there is a precondition for the applicability of this test? There was a problem hiding this comment. I think the confusion here comes from this "No exception" thing in the title of that SC. 1.4.9 does allow text where presentation is essential (like logos) and text that is purely decorative. The only difference between 1.4.5 and 1.4.9 is that 1.4.5 allows images of text if the text can be customised. |
||
|
|
||
| ### Bibliography | ||
|
|
||
|
|
@@ -210,10 +209,13 @@ This image resource referenced by the `img` element contains text that provides | |
| This `img` element loads an SVG with text as an image resource. Because the SVG is loaded as an image resource, instead of being embedded in HTML the text cannot be selected or customized. | ||
|
|
||
| ```html | ||
| <img | ||
| alt="WCAG Rocks" | ||
| src="data:image/svg+xml;utf8, | ||
| <svg xmlns='http://www.w3.org/2000/svg' height='20px' width='80px'> | ||
| <text x='0' y='15'>WCAG Rocks</text> | ||
| </svg>" | ||
| /> | ||
|
Comment on lines
-213
to
+218
There was a problem hiding this comment. This was Prettier's doing. |
||
| ``` | ||
|
|
||
| ### Inapplicable | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: depending on our ES target, we may be able to use optional chaining:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's not quite the same. Doing it the way you suggests triggers the tests on line 107 / 108, which would then fail.