Skip to content

Commit

Permalink
Update act-rules-format.bs for secondary requirements explanation
Browse files Browse the repository at this point in the history
  • Loading branch information
kengdoj authored Sep 12, 2023
1 parent cb3ebc1 commit db868d1
Showing 1 changed file with 6 additions and 22 deletions.
28 changes: 6 additions & 22 deletions act-rules-format/act-rules-format.bs
Original file line number Diff line number Diff line change
Expand Up @@ -224,8 +224,7 @@ Rules that can be used to determine if an accessibility requirement is *satisfie

A secondary accessibility requirement is a requirement that is correlated with the rule, but for which the rule is not designed to test. The outcome of the rule impacts the result of the accessibility requirement, but the rule is not intended to test the conformance of that requirement. This correlation often results in some of the rule's test cases not satisfying the secondary accessibility requirement.

When the rule is not designed to test the accessibility requirement, or failed outcomes of the rule still require further testing for the accessibility requirement, the rule <em class="rfc2119">may</em> map the accessibility requirement as Secondary. When an ACT rule maps to a Secondary requirement, it <em class="rfc2119">must</em> include an explanation of why that requirement is Secondary in the Background section of the rule.

When the rule is not designed to test the accessibility requirement, or failed outcomes of the rule still require further testing for the accessibility requirement, the rule <em class="rfc2119">may</em> map the accessibility requirement as Secondary. When an ACT rule maps to a Secondary requirement, it <em class="rfc2119">must</em> include an explanation of why that requirement is Secondary.

Some scenarios when a rule will have Secondary requirements include:

Expand All @@ -239,26 +238,12 @@ A rule was designed to test a minimum accessibility requirement and there exists
<ul>
<li>Conformance Requirement: Success Criterion 1.4.3 Contrast (Minimum)</li>
<li>Secondary Requirement: Success Criterion 1.4.6 Contrast (Enhanced)</li>
<ul><li>Background Section: Success Criterion 1.4.6 is mapped as a Secondary requirement because the SC may be [=not satisfied=]when the rule’s outcomes are `passed`. </li></ul>
<ul><li>Explanation: This success criterion is **more strict** than this rule. This is because this criterion has a higher minimum contrast. Some of the passed examples do not satisfy this success criterion.</li></ul>
</ul>
</blockquote>
</aside>

**Scenario 2**: the rule's failed outcomes require further testing for the accessibility requirement

A rule was designed to test a specific type of solution for an accessibility requirement, but the rule does not cover all solutions that can be used to meet the requirement. In this scenario, the rule’s failed outcomes cannot determine that an accessibility requirement is not satisfied because further testing is needed. The rule’s passed outcomes can determine that an accessibility requirement is satisfied. The accessibility requirement is a Secondary requirement.</li>

<aside class=example>
<header>Example: a rule that tests if a focusable element has no keyboard trap via standard navigation</header>
<blockquote>This rule was designed to test for a specific solution that can be used to meet Success Criterion 2.1.2: No Keyboard Trap. The rule does not test for other possible solutions, such as the use of non-standard navigation, so its failed outcomes cannot determine that the accessibility requirement is [=not satisfied=]. This rule’s mapping:
<ul>
<li>Secondary Requirement: Success Criterion 2.1.2: No Keyboard Trap</li>
<ul><li>Background Section: This rule tests for one solution that can meet Success Criterion 2.1.2. SC 2.1.2 is mapped as a Secondary requirement because other solutions (such as use of non-standard navigation to exit a keyboard trap) can be used to meet this SC that are not tested by this rule.</li></ul>
</ul>
</blockquote>
</aside>

**Scenario 3**: the rule is stricter than a requirement
**Scenario 2**: the rule is stricter than a requirement

A rule was designed to test an accessibility requirement and there exists a less strict accessibility requirement. In this scenario, the rule’s passed outcomes can determine that the less strict requirement is satisfied, and the rule’s failed outcomes may not determine that the less strict requirement is not satisfied. It is possible that the accessibility requirement may be satisfied when the rule’s outcome is failed. The less strict accessibility requirement is a Secondary requirement.</li>

Expand All @@ -268,11 +253,10 @@ A rule was designed to test an accessibility requirement and there exists a less
<ul>
<li>Conformance Requirement: Success Criterion 1.4.6 Contrast (Enhanced)</li>
<li>Secondary Requirement: Success Criterion 1.4.3 Contrast (Minimum)</li>
<ul><li>Background Section: Success Criterion 1.4.3 is mapped as a Secondary requirement because the SC may be [=satisfied=]when the rule’s outcomes are `failed`.</li></ul>
<ul><li>Explanation: This success criterion is **less strict** than this rule. This is because this criterion has a lower minimum contrast. Some of the failed examples may satisfy this success criterion.</li></ul>
</aside>


**Scenario 4**: the rule may impact the result of the accessibility requirement, but the rule is not intended to test the conformance of that requirement
**Scenario 3**: the rule may impact the result of the accessibility requirement, but the rule is not intended to test the conformance of that requirement

A rule was designed to test an accessibility requirement and under certain conditions, other accessibility requirements apply. In this scenario, the other accessibility requirements are sometimes, but not always, satisfied or not satisfied because they are not always applicable in the rule. These other accessibility requirements are a Secondary requirement.

Expand All @@ -282,7 +266,7 @@ A rule was designed to test an accessibility requirement and under certain condi
<ul>
<li>Conformance Requirement: Success Criteria 4.1.2 Name, Role, Value (Level A), 2.4.4 Link Purpose (In Context) (Level A), 2.4.9 Link Purpose (Link Only) (Level AAA)</li>
<li>Secondary Requirement: Success Criterion 1.1.1 Non-text Content</li>
<ul><li>Background Section: Success Criterion 1.1.1 Non-text Content is mapped as a Secondary requirement because the SC applies only to certain types of links (<area> element links), not to all links. </li></ul>
<ul><li>Explanation: This success criterion is **related** to this rule. This is because HTML `area` elements are both links and non-text content. Most failed examples satisfy this success criterion. </li></ul>
</ul>
</blockquote>
</aside>
Expand Down

0 comments on commit db868d1

Please sign in to comment.