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 | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -6,9 +6,9 @@ description: | | |||||||||
| This rule checks that each `aria-` attribute specified is defined in ARIA 1.2. | ||||||||||
| accessibility_requirements: | ||||||||||
| wcag20:1.3.1: # Info and Relationships (A) | ||||||||||
| secondary: This success criterion is **less strict** than this rule. This is because the rule does not ignore irrelevant ARIA properties. This is why some of the failed examples may not satisfy this success criterion. | ||||||||||
|
There was a problem hiding this comment.
Suggested change
There was a problem hiding this comment. @WilcoFiers and others ... I would want us to define the "some" where as you'd want to map to what are the "some" examples that people can reference in context of what fails / passes as secondary reqs. Thanks! There was a problem hiding this comment.
Suggested change
There was a problem hiding this comment.
There was a problem hiding this comment. This rule is more strict than the success criterion because it does not ignore irrelevant ARIA properties. Therefore, some of the reported failures can be false positives rather than a success criterion failure. My comment carries to the rest of the examples where this text appears. It was a little difficult to read and understand, as written. There was a problem hiding this comment. I'm not a huge fan of using the term "false positives" here, since it has a connotation of "the rule is bad and generate false positives" while we want to carry the information "this rule is designed for a slightly different use case and tangentially affects this use case". Typically, in a color contrast case, saying that the 1.4.6 rule "reports false positives (for 1.4.3)" is technically true but sounds a bit dramatic. There was a problem hiding this comment. I like the change from saying "the rule more strict" (than the SC) to "the SC is less strict" (than the rule). |
||||||||||
| wcag20:4.1.2: # Name, Role, Value (A) | ||||||||||
| secondary: This success criterion is **less strict** than this rule. This is because the rule does not ignore irrelevant ARIA properties. This is why some of the failed examples may not satisfy this success criterion. | ||||||||||
| input_aspects: | ||||||||||
| - DOM Tree | ||||||||||
| acknowledgments: | ||||||||||
|
|
@@ -36,7 +36,7 @@ There are no accessibility support issues known. | |||||||||
|
|
||||||||||
| ## Background | ||||||||||
|
|
||||||||||
| The presence of unknown ARIA attributes is often the result of a typo or other developer error. These attributes are ignored by browsers and other assistive technologies. This often means that a state or property which should exist is missing. | ||||||||||
|
|
||||||||||
| ### Bibliography | ||||||||||
|
|
||||||||||
|
|
@@ -130,5 +130,3 @@ This `canvas` element does not have an `aria-` attribute specified. | |||||||||
| ``` | ||||||||||
|
|
||||||||||
| [wai-aria specifications]: #wai-aria-specifications 'Definition of WAI-ARIA specifications' | ||||||||||
| 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 | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -11,7 +11,7 @@ accessibility_requirements: | |
| passed: further testing needed | ||
| inapplicable: further testing needed | ||
| wcag20:2.4.4: # Link Purpose (In Context) (A) | ||
| secondary: This success criterion is **less strict** than this rule. This is because the rule does not consider the context of the link. This is why some of the failed examples may not satisfy this success criterion. | ||
|
There was a problem hiding this comment. If the success criterion is less strict, shouldn't the failed examples potentially satisfy the criterion (e.g., where the link text does not provide the purpose but the context does). There was a problem hiding this comment. In regard to @tbostic32's concerns with the over-use of the word "this"...
@tbostic32's second comment seems correct to me just reading the sentence statements. If the following is not accurate, then I think there's a larger problem here...
|
||
| input_aspects: | ||
| - Accessibility Tree | ||
| - DOM Tree | ||
|
|
@@ -57,8 +57,6 @@ When followed, the links in each set of target elements resolve to the [same res | |
|
|
||
| ## Background | ||
|
|
||
| ### Bibliography | ||
|
|
||
| - [CSS Scoping Module Level 1 (editor's draft)](https://drafts.csswg.org/css-scoping/) | ||
|
|
@@ -389,7 +387,6 @@ These `span` elements do not have a [semantic role][] of `link`. They are not va | |
| [presentational roles conflict resolution]: https://www.w3.org/TR/wai-aria-1.1/#conflict_resolution_presentation_none 'Presentational Roles Conflict Resolution' | ||
| [same resource]: #same-resource 'Definition of same resource' | ||
| [sc249]: https://www.w3.org/TR/WCAG21/#link-purpose-link-only 'Success Criterion 2.4.9: Link Purpose (Link Only)' | ||
| [semantic role]: #semantic-role 'Definition of semantic role' | ||
| [shadow tree]: https://dom.spec.whatwg.org/#shadow-tree 'Definition of shadow tree' | ||
| [web page (html)]: #web-page-html 'Definition of web page (HTML)' | ||
|
|
||
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.