ACT rules is starting to use secondary requirements for rules.
We need to consider how to support them, some possibilities:
Simply ignore them; only map rules to their primary requirements. This would result in smaller subset of rules to be selected when selecting by requirements.
Fully embrace them; always map rules to both their primary and secondary requirements. This would result in larger subset of rules to be selected when selecting by requirements. This may be annoying for cases like "image has name" mapping to 2.4.4 due to <area> elements, as this is really a side mapping for only a handful of cases…
List them as secondary; introduce a second layer of requirements and split primary/secondary. This requires more work but would be more accurate.
Introduce categories; secondary requirements are secondary for various reason (4 cases in ACT rules format 1.1) and we can mirror that:
either by treating the categories differently; e.g. "stricter" (2.4.4 / 2.4.9) is treated as primary but "less strict" is simply ignored.
or by having the categories in the model so that users know why each requirement is here.
For now, we do a case-by-case decision of whether secondary requirements are included or not, with only one kind of requirement internally.
Parking this issue and we'll revisit later if the need arise.
ACT rules is starting to use secondary requirements for rules. We need to consider how to support them, some possibilities:
<area>
elements, as this is really a side mapping for only a handful of cases…