[Don't merge] Set Element with role attribute has required states and properties [4e8ab6] to approved #334
Conversation
✅ Deploy Preview for wai-wcag-act-rules ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
WilcoFiers
changed the title
daniel-montalvo
changed the title
There was a problem hiding this comment.
I am of the opinion that the caveats under Secondary Requirements are so cautious as to be counter productive.
This success criterion is less strict than this rule.
This is potentially very bad! A rule failing something which is a pass can have worse consequences than a rule missing something.
Some of the failed examples may satisfy this success criterion.
Yikes! That leaves a reader hanging, as it begs the question as to which failure examples are questionable?
All of the failed examples provided are fine! My suggestion is to rework the disclaimer. Instead of the excerpted sentence above, I suggest:
It may be possible to craft theoretical examples which satisfy this success criterion but fail the rule.
| </ul> | ||
| </details></li> | ||
| <li><details> | ||
| <summary><span>undefined</span></summary> |
There was a problem hiding this comment.
This success criterion is less strict than this rule.
This is potentially very bad...
My apologies for my poor reading comprehension! If this had been stated as:
This rule is more strict and than this success criterion.
I would have thought "of course, that's good" and not caused the churn. It is fine as-is, and in the context of ACT rule format, the word order is better than reversing the statement.
I still think the disclaimer sentence is misplaced.
Some of the failed examples may satisfy this success criterion.
My thanks to @kengdoj for the hand-holding, and I now have more background and better understanding of Secondary Requirements. I will file an issue on the GitHub repo for the ACT Rules 1.1 FPWD.
See w3c/wcag-act#594
Here is a preview of this rule.