Impact being bound to checks is limiting when composing new rules
See original GitHub issueThe impact property (“minor”, “moderate”, “serious”, or “critical”) is currently bound to a check. It means that when composing a new rule, this rule will necessarily inherit the impacts of the underlying checks.
In my understanding however, a check is an “abstract” atomic piece of logic. A rule on the contrary is the “concrete” implementation of a given accessible guideline. The actual impact of a violation only makes sense for a given rule.
For instance, the non-empty-title
check has a serious
impact. But there may be cases where a rule checks the presence of empty titles but isn’t about a serious violation (we have such rules in the digital publishing context). In that case, we have no other choice than implementing a custom check with a lesser impact, even if the implementation logic is exactly the same as non-empty-title
.
A possible improvement IMO would be to associate the impact to the check only when the rule is composed, but not bake it in the check.
Issue Analytics
- State:
- Created 6 years ago
- Comments:16 (14 by maintainers)
Top GitHub Comments
Having a different impact for checks is only one use case.
The other common case is having two different rules with different impacts for the same check.
Custom rule writers quite often require this and right now we have to duplicate the check to achieve this.
I think that just overcomplicates things. Very few rules can actually come up with issues of different levels of impact (
aria-roles
,button-name
,label
,link-name
andscope-attr-valid
). And only for one of their checks - one that should probably have been its own rule instead of getting tagged onto an existing rule. I think if you have multiple impact levels, you’re probably dealing with different issues, in which case they shouldn’t be part of the same rule IMO.