Update act-rules-format.md for mapping secondary accessibility requirements

act-rules-format.md

@@ -160,7 +160,9 @@ Refer to the [Rule Type](#rule-types) section for detailed definitions of the ru
 Accessibility Requirements Mapping {#accessibility-requirements-mapping}
 ------------------------------------------------------------------------
 
-When an ACT Rule is designed to test conformance to one or more [=Accessibility requirements documents=], the rule <em class="rfc2119">must</em> list all [=accessibility requirements=] from those documents that are not satisfied when one or more of the [=outcomes=] of the rule is `failed`. For example, when designing a rule for WCAG that tests if image buttons have alternative text, the rule maps to success criteria 1.1.1 Non-text content, and 4.1.2 Name, Role, Value. That ACT Rule will list both success criteria in its accessibility requirements mapping.
+When an ACT Rule is designed to test conformance to one or more [=Accessibility requirements documents=], the rule <em class="rfc2119">must</em> list all [=accessibility requirements=] from those documents that are not satisfied when one or more of the [=outcomes=] of the rule is `failed`. The rule <em class="rfc2119">should</em> list accessibility requirements that could be not satisfied when the rule outcome is failed. There are two types of accessibility requirements:
+- Conformance Requirements
+- Secondary Requirements
 
 Each [=accessibility requirement=] in the mapping <em class="rfc2119">must</em> include the following:
 
@@ -169,17 +171,24 @@ Each [=accessibility requirement=] in the mapping <em class="rfc2119">must</em>
 3. a link or reference to the [=accessibility requirements document=] if one exists, and
 4. the conformance level associated with the accessibility requirement, if one exists.
 
-
 ### Outcome Mapping ### {#outcome-mapping}
+For each accessibility requirement in the mapping, an ACT Rule <em class="rfc2119">must</em> indicate what the [=outcomes=] of the rule mean for satisfying an accessibility requirement for that [=test subject=]. 
+
+#### Conformance Requirements ### {#conformance-requirements}
+
+When a rule is designed to test a specific accessibility requirement, the accessibility requirement is mapped as a Conformance Requirement when both of the following are true: 
 
-For each accessibility requirement in the mapping, an ACT Rule <em class="rfc2119">must</em> indicate what the [=outcomes=] of the rule mean for satisfying that accessibility requirement for that [=test subject=]. When one or more of the outcomes for a test target is `failed`, the accessibility requirements are <dfn>not satisfied</dfn> for the test subject. When all of the outcomes are `passed` or `inapplicable`, the accessibility requirements could be <dfn>satisfied</dfn>, or <dfn>further testing is needed</dfn>. Rules that can be used to determine if an accessibility requirement is *satisfied* are called <dfn>satisfying tests</dfn>.
+- Failed Outcomes: When one or more of the outcomes for a test target is `failed`, the accessibility requirement is <dfn>not satisfied</dfn> for the test subject, and 
+- Passed or Inapplicable Outcomes: When all of the outcomes are `passed` or `inapplicable`, the accessibility requirement could be <dfn>satisfied</dfn> or <dfn>further testing is needed</dfn>.
+
+Rules that can be used to determine if an accessibility requirement is *satisfied* are called <dfn>satisfying tests</dfn>.
 
 <div class=note>
   <p>**Note:** In the [Web Content Accessibility Guidelines](https://www.w3.org/WAI/standards-guidelines/wcag/) [[WCAG]], success criteria do not evaluate to `passed`, `failed` or `inapplicable`. Rather they can be *satisfied* (or not). (See the [WCAG 2.1 definition: satisfies a success criterion](https://www.w3.org/TR/WCAG21/#dfn-satisfies).) If a success criterion is *not satisfied*, a web page can only conform if there is a conforming alternative version, as described in [WCAG 2.1 Conformance Requirement 1](https://www.w3.org/TR/WCAG21/#cc1).</p>
 </div>
 
 <aside class=example>
-  <header>Example accessibility requirements mapping for a rule that tests if an image button has an accessible name:</header>
+  <header>Example accessibility requirements mapping for a rule that was designed to test if an image button has an accessible name maps success criteria 1.1.1 Non-text content and 4.1.2 Name, Role, Value as conformance requirements:</header>
   <blockquote><ul>
     <li>
       [Success criterion 1.1.1: Non-text content](https://www.w3.org/TR/WCAG21/#non-text-content)
@@ -206,6 +215,82 @@ For each accessibility requirement in the mapping, an ACT Rule <em class="rfc211
   </ul></blockquote>
 </aside>
 
+#### Secondary Requirements ####
+
+When both the "Failed Outcomes" and "Passed or Inapplicable Outcomes" described under [=Conformance Requirements=] are true for an accessibility requirement, the rule <em class="rfc2119">must</em> map that accessibility requirement as a Conformance Requirement.
+
+When only one of the Outcomes is true or both Outcomes are only sometimes true for an accessibility requirement, the rule <em class="rfc2119">should</em> map the accessibility requirement as Secondary. When an ACT rule maps to a Secondary requirement, it must include an explanation of why that requirement is Secondary in the Background section of the rule.
+
+Some scenarios when a rule will have Secondary requirements include:
+
+**Scenario 1**: only the "Failed Outcomes" are true for the requirement
+
+A rule was designed to test a minimum accessibility requirement and there exists a stricter requirement. In this scenario, the rule’s failed outcomes can determine that the stricter accessibility requirement is not satisfied, and the rule’s passed outcomes may not determine that the stricter requirement is satisfied. It is possible that the accessibility requirement may be not satisfied when the rules outcomes are passed. The stricter requirement is a Secondary requirement.
+
+<aside class=example>
+  <header>Example: a rule that tests if text has minimum contrast</header>
+<blockquote>This rule was designed to test Success Criterion 1.4.3 Contrast Minimum (AA). A stricter requirement, Success Criterion 1.4.6 Contrast (Enhanced) (Level AAA), will be not satisfied when the rule outcome is failed, and may be not satisfied when the rule outcomes are passed. This rule’s mapping:
+<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 <dfn>not satisfied</dfn>when the rule’s outcomes are `passed`. </li></ul>
+</ul>
+</blockquote>
+</aside>
+
+**Scenario 2**: only the "Passed or Inapplicable Outcomes" are true for the requirement
+<ol style="list-style-type: lower-alpha">
+  <li>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 <dfn>not satisfied</dfn>. 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>
+
+<li>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>
+
+<aside class=example>
+<header>Example: a rule that tests Enhanced Contrast</header>
+<blockquote>This rule was designed to test Success Criterion 1.4.6 Contrast (Enhanced) (Level AAA). A less strict requirement, Success Criterion 1.4.3 Contrast Minimum (AA), will be satisfied when the rule outcomes are passed, and may be satisfied when the rule outcomes are failed.This rule’s mapping:
+<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 <dfn>satisfied</dfn>when the rule’s outcomes are `failed`.</li></ul>
+</aside>
+</ul>
+</ol>
+
+**Scenario 3**: both outcomes are only sometimes true
+
+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.
+
+<aside class=example>
+  <header>Example 1: a rule that tests if a link has a non-empty accessible name</header>
+  <blockquote>This rule was designed to test links for accessibility requirements 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). When a &lt;map&gt; element is used with <area> elements to define an image map, this is also a link area. Testing for non-empty accessible name for &lt;area&gt; elements would map to another accessibility requirement 1.1.1 Non-text Content. Because the rule tests for all links and SC 1.1.1 only applies certain links, this rule’s mapping:
+  <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>
+  </blockquote>
+</aside>
+
+<aside class=example>
+  <header>Example 2: A rule that tests that elements that have an explicit role also specify all required states and properties </header>
+  <blockquote>This rule was designed to test a requirement of WAI-ARIA. In some cases, a failed outcome for this rule may result in WCAG 2 Success Criterion 4.1.2 Name, Role, Value being not satisfied, but not always. This rule’s mapping:
+  <ul>
+    <li>Conformance Requirement: WAI-ARIA 1.1</li>
+    <li>Secondary Requirement: Success Criterion 4.1.2 Name, Role, Value
+      <ul><li>Background Section: Success Criterion 4.1.2 Name, Role, Value is mapped as a Secondary requirement because it only applies to user controls. </li></ul>
+    </li>
+  </ul>
+  </blockquote>
+</aside>
 
 ### Mapping Outside WCAG ### {#mapping-outside-wcag}