-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allowing parametric rules #549
Comments
This makes sense for the contrast rules, but is a bit more complex for the Target Size rules. The 2.5.5 Target Size (Enhanced) SC ensures targets are easy to click. It triggers on anything smaller than 44x44 (apart from equivalent, inline, essential and UA defined) The 2.5.8 Target Size (Minimum) SC is similar but with a 24x24 threshold and an extra (and very complicated) exception:
Or put another way: Is there a way to move some of the applicability or expectation into something like a shared definition? |
Yes, I think for Target size, we'd need a parametric rule for |
Yep, I think composition is the right way to do it. There's some stuff that's shared (parameterised applicability and/or expectation) and other stuff that's specific to the rule (accessibility mappings, test cases) We do this by having common calculations for target width, height, etc. The individual rules then assemble those to produce the desired outcome. So it's something like this:
That's why I was suggesting something like a shared definition - you can hide the complexity in the definitions of targetSize, targetTooClose and "call" those definitions from simple looking rules. |
Some though I've had recently about a possible augmentation to the rule format, notably while working on the "Target Size" rules.
We have a few cases of rules that are very similar but checking for a different threshold because there are two "levels" of the same SC (e.g., color contrast). Sometimes one of the rule may have extra conditions. We currently write two separate rules, but that is very WET, and thus creates maintenance overload when we need to edit them (e.g., act-rules/act-rules.github.io#1961 or act-rules/act-rules.github.io#1978). Plus cognitive overload for readers to figure out that the rules are indeed the same apart from a threshold somewhere.
It would be more convenient for us to have a shared rule with one (or more) "parameter", and then the actual rules would use it, with specific parameters. This can fit within the composite rules framework.
For the Target Size, we're likely going to have two rules, one with "more than 44×44", another one with "more than 24×24; or enough spacing". I feel that if the second one was also 44×44, we'd just go for a composite rule. We can still go for a composite rule, but we'll need to duplicate the "target large enough" rule just to change a number. Given that it will likely already be a fairly complex rule, that doesn't feel good.
We're likely going to have:
We can maybe make things a bit more streamlined with
But I feel it would be better in term of DRY and especially DRY the complex bits to have:
While this does dilute a bit rule A, it makes the connection (and differences) between rule A and B much more obvious. And it lowers the maintenance cost on our side, since we only need to change the parametric rule, not both A and B1.
The main problem I see with that is that the parametric rule is a bit "abstract" (in the Object Oriented meaning) and needs to be called. Which notably makes it a bit more tricky to add test cases to it (especially as the parameters would need to be baked in for implementation report generation). But the test cases can be in the "calling" rules.
We'd also need to be a bit cautious on which parameters to allow to avoid too much leeway. Likely restrict them to numbers and booleans 🤔
The text was updated successfully, but these errors were encountered: