Adjusting the applicability of composite rules #2214
Replies: 5 comments 4 replies
-
Thread to discuss Option 1: current proposal. |
Beta Was this translation helpful? Give feedback.
-
Thread to discuss Option 2: Definitions. |
Beta Was this translation helpful? Give feedback.
-
Thread to discuss Option 3: Adjusting applicability in composite rules. |
Beta Was this translation helpful? Give feedback.
-
Thread to discuss Option 4: Atomic outcomes in the applicability. |
Beta Was this translation helpful? Give feedback.
-
Side note: while the discussion is focused here on the recent "Target Size" proposal, I feel that the core of it is broadly relevant. Notably:
So, I think this is a fairly important discussion (not just local to a proposal). And we can also try the various options on existing and approved rules… |
Beta Was this translation helpful? Give feedback.
-
This topic has been discussed a few times now. The problem we were looking at is this one. WCAG's target size requirement is fairly complex. It has a the a number of clauses, and a number of exceptions. In order to avoid having to put all of this complexity into a single rule, we'd like to break different parts of it up and put those into atomic rules, then have one composite rule for each success criterion to put it together.
Under the current ACT Rules Format, this could look like this:
Option 1: current proposal
The applicability of these three rules will then be something like this:
Drawback This creates a problem where small targets will end up passing the rule if they are in a block of text, controlled by the user agent, or the size is essential. The language of the success criterion seems to suggest this should be inapplicable. While in practice this doesn't change whether a page conforms to WCAG or not, passing things that seem like they should be inapplicable has proven to be confusing to people in the past. This is something we'd prefer to avoid.
Putting these exceptions into their own atomic rules can be especially confusing, since these atomic rules failing things that are in no way an accessibility problem. The inline text block atomic rule fails controls that are not in line. The user agent size rule fails controls who's size is not controlled by the user agent, etc.
To address this, we came up with a few options:
Option 2: Definitions
The most obvious solution is to take the things that should be inapplicable, and rather than put them in a separate rule we put those ideas into a definition which is used in the applicability of both the atomic and the composite rules. The rule structure would then be:
And the applicability of these three rules will then be something like this:
Drawbacks: The the atomic rules this results in cannot be reused between Target Size (Minimum) and Target Size (Enhanced). Since Target Size (Enhanced) does not allow for spacing, it wouldn't need to leaves only one requirement, which means no composite rule is necessary. Whether Target Size (minimum) need atomic rules is questionable then too.
Option 3: Adjusting applicability in composite rules
Another thing that has been proposed is to allow the composite rule to limit the applicability. This is similar to option 2, except that the applicability of the composite rule would be different from that of the atomic rules:
Atomic rule applicability:
Composite rule applicability:
Drawbacks: The big problem with this is that it is a significant change to the ACT Rules Format. Currently the only thing that can be used to determine the outcome in a composite rule is the outcome of the composite rules. If we update the rules format to allow the applicability of the composite rule to change, we need to add input aspect in the composite rule. This fundamentally changes what composite rules do, and as a result may make rules written in the ACT Rules Format more difficult to implement in tools using different architectures.
Option 4: Atomic outcomes in the applicability
This approach is has all the atomic rules from option 1, except that it uses some of the outcomes in the applicability, rather than using all in the expectation:
Composite rule applicability:
Composite rule expectation:
Drawbacks: This is currently not allowed by the ACT Rules Format, although since this won't require input aspects to be added to the composite rule, it is a smaller change to the rules format than option 3, and will likely be less impactful on implementors. And while this partially addresses the issue that the overall outcome will better match the expected outcome, this solution still requires atomic rules that fail things that are not accessibility problems. (I.e failing controls that are not inline text, who's size is not controlled by the user agent, etc.)
Task force conclusions
Looking at all these solutions the ACT Task Force seemed to lean towards option 2. Option 1 and 4 have atomic rules that seem "off" for failing things that aren't accessibility problems, and option 3 doesn't seem like it's a enough improvement over option 2 to justify the changing the rules format in a way that potentially makes implementation more difficult.
I've opened this discussion for people to share alternative proposals, or if someone would like to make a case in favor of something other than option 2.
Beta Was this translation helpful? Give feedback.
All reactions