Skip to content

Commit

Permalink
Update act-rules-format.bs for secondary requirements explanation (#542)
Browse files Browse the repository at this point in the history
* Update act-rules-format.bs for secondary requirements explanation

Update secondary requirements explanation to https://github.com/act-rules/act-rules.github.io/pull/2060/files#diff-5b9654ba823ee48091fedcd2a4911a8858a6dda77bf9de025c204973ff3d71a3

* Update act-rules-format/act-rules-format.bs

* Apply suggestions from code review

* Update act-rules-format/act-rules-format.bs

* Update act-rules-format/act-rules-format.bs
  • Loading branch information
kengdoj authored Nov 21, 2023
1 parent de1dae8 commit 73ef490
Showing 1 changed file with 12 additions and 16 deletions.
28 changes: 12 additions & 16 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,50 +238,47 @@ 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
**Scenario 2**: the rule is stricter than a 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>
A rule was designed to test a specific solution for an accessibility requirement, but the requirement can be satisfied by other solutions that are not included in the rule. 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.

<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:
<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 the use of other possible solutions, such as non-standard navigation, that can satisfy the success criterion. 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><li>Explanation: This success criterion is **less strict** than this rule. This is because this criterion allows for the use of non-standard keyboard navigation to exit a keyboard trap. Some of the failed examples may satisfy this success criterion.</li></ul>
</ul>
</blockquote>
</aside>

**Scenario 3**: 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>
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 [=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 3**: the rule may impact the result of the accessibility requirement, but the rule is not intended to test the conformance of that requirement

**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

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.
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 secondary requirements.

<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:
<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). In an image map, &lt;area&gt; elements that define regions within the map are both links and images. 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 Success Criterion 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><li>Explanation: This success criterion is **related** to this rule. This is because HTML &lt;area&gt; 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 73ef490

Please sign in to comment.