Open tbostic32 opened 1 year ago
It feels we are going to duplicate bits, need to maintain in two places (e.g. if we figure out the Applicability needs fixing), … So I get the feeling we are making things more complex to maintain without bringing any real value (we are even diluting the rule and loosing a bit of cohesion).
@Jym77 I do agree, and I left a comment on that new rule proposal (https://github.com/act-rules/act-rules.github.io/issues/2037) that we were reusing the applicability and the the passed examples from this rule. I think the larger conversation we had is that there is also likely to be a third rule around deprecated
properties which will follow a very similar format to each of these rules as well. In the end, I think the decision was to just split them fully apart (each to it own atomic rule) for simplicity in covering each of those cases specifically with the knowledge that it does introduce a bit more overhead.
Splitting the aria-state-or-property permitted into multiple rules. Essentially changing from having the 2 expectation where Expectation 1 is the state or property is permitted and Expectation 2 is the state or property is not prohibited, to 2 separate rules for each of the expectations. We also expect to have a rule for aria state or property is not deprecated in the future.
Need for Call for Review: This will require a 2 week Call for Review
Pull Request Etiquette
When creating PR:
develop
branch (left side).After creating PR:
Rule
,Definition
orChore
.When merging a PR:
How to Review And Approve