-
Notifications
You must be signed in to change notification settings - Fork 882
Give rules a consistent impact #4066
Description
The impact of a violation is currently determined by which checks fail. The idea of it was to give some flexibility in setting the impact within the same rule. This never worked well though. Since impact is bound up with the checks of a rule, and which checks run is driven by the remediation message we want to give, axe-core's architecture gives very little control over the impact.
As variable impact is also a common source of confusion, we're going to change this so that a single rule only ever outputs one level of impact. It is already possible to set the impact on a rule, although we aren't using it much.
Since impact is used in many UIs, and we don't want the numbers to drastically change by this release we're going to have to put a few checks into separate rules
Prerequisites
- Put label-same-as-description (from label / select-name) into its own rule #1325
- Put aria-prohibited-attr (from aria-allowed-attr) into its own rule #4067
- Put aria-conditional-attr (from aria-allowed-attr) into its own rule #4068
- Put aria-deprecated-role (from aria-roles) into its own rule #4069
- Move no-implicit-explicit-label check into label-content-name-mismatch rule #4070
Make impact a required prop on rules/*.json
Once all the above tickets are done, the work for this ticket will be to give each rule an impact property, and make it required in the build tool. We can then do some cleanup in how rule-descriptions.md is generated, as that won't need to look at checks anymore.