Accessibility requirements mapping rewrite

act-rules-format.bs

@@ -17,7 +17,7 @@ Introduction {#intro}
 
 There are currently many test procedures and tools available which aid their users in testing web content for conformance to accessibility standards such as the [Web Content Accessibility Guidelines (WCAG)](https://www.w3.org/WAI/standards-guidelines/wcag/) [[WCAG]]. As the web develops in both size and complexity, these procedures and tools are essential for managing the accessibility of resources available on the web.
 
-This format is intended to enable a consistent interpretation of how to test for [accessibility requirements](#accessibility-requirements) and promote consistent results of accessibility tests. It is intended to be used to describe both manual accessibility tests as well as automated tests performed by accessibility testing tools.
+This format is intended to enable a consistent interpretation of how to test conformance to [=accessibility requirements documents=] and promote consistent results of accessibility tests. It is intended to be used to describe both manual accessibility tests as well as automated tests performed by accessibility testing tools.
 
 Describing how to test certain accessibility requirements will result in accessibility tests that are transparent, with test results that are reproducible. The Accessibility Conformance Testing (ACT) Rules Format defines the requirements for these test descriptions, known as Accessibility Conformance Testing Rules (ACT Rules).
 
@@ -27,7 +27,7 @@ Scope {#scope}
 
 The ACT Rules Format defined in this specification is focused on the description of rules that can be used in testing content created using web technologies, such as [Hypertext Markup Language](https://www.w3.org/TR/html/) [[HTML]], [Cascading Style Sheets](https://www.w3.org/TR/CSS/) [[css-2018]], [Accessible Rich Internet Applications](https://www.w3.org/WAI/standards-guidelines/aria/) [[WAI-ARIA]], [Scaleable Vector Graphics](https://www.w3.org/TR/SVG/) [[SVG2]] and more, including digital publishing. The ACT Rules Format is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies.
 
-The ACT Rules Format can be used to describe ACT Rules dedicated to testing the [accessibility requirements](#accessibility-requirements) defined in Web Content Accessibility Guidelines [[WCAG]], which are specifically designed for web content. Other accessibility requirements applicable to web technologies can also be testable with ACT Rules. For example, ACT Rules could be developed to test the conformance of web-based user agents to the [User Agent Accessibility Guidelines](https://www.w3.org/WAI/standards-guidelines/uaag/) [[UAAG20]]. The ACT Rules Format might not always be suitable to describe tests for other types of accessibility requirements.
+The ACT Rules Format can be used to describe ACT Rules dedicated to testing the [=accessibility requirements=] defined in Web Content Accessibility Guidelines [[WCAG]], which are specifically designed for web content. Other accessibility requirements applicable to web technologies can also be testable with ACT Rules. For example, ACT Rules could be developed to test the conformance of web-based user agents to the [User Agent Accessibility Guidelines](https://www.w3.org/WAI/standards-guidelines/uaag/) [[UAAG20]]. The ACT Rules Format might not always be suitable to describe tests for other types of accessibility requirements.
 
 
 ACT Rule Types {#rule-types}
@@ -53,7 +53,7 @@ In accessibility, there are often different technical solutions to make the same
 
 The separation between atomic rules and composite rules can be seen as a division of responsibility. Atomic rules typically test if web content is correctly implemented in a particular solution. Composite rules can test if a combination of outcomes from atomic rules satisfy the accessibility requirement, in part or as a whole.
 
-Not all atomic rules have to be part of a composite rule. Composite rules are used when the outcomes of multiple atomic rules need to be combined in order to determine (non-)conformance of a test subject to the [Accessibility Requirements](#accessibility-requirements)
+Not all atomic rules have to be part of a composite rule. Composite rules are used when the outcomes of multiple atomic rules need to be combined in order to determine (non-)conformance of a test subject to an [=accessibility requirement=].
 
 
 ACT Rule Structure {#act-rule-structure}
@@ -65,7 +65,7 @@ An ACT Rule MUST consist of at least the following items:
 * [Rule Identifier](#rule-identifier)
 * [Rule Description](#rule-description)
 * [Rule type](#rule-types)
-* [Accessibility Requirements](#accessibility-requirements)
+* [Accessibility Requirements Mapping](#accessibility-requirements-mapping)
 * [Aspects Under Test](#input-aspects) (for atomic rules) OR [Atomic Rules List](#atomic-rules-list) (for composite rules)
 * [Applicability](#applicability)
 * [Expectations](#expectations)
@@ -110,42 +110,95 @@ An ACT Rule MUST have a description that is in plain language, and provides a br
 </div>
 
 
-Accessibility Requirements {#accessibility-requirements}
+Accessibility Requirements Mapping {#accessibility-requirements-mapping}
 ========================================================
 
-Accessibility requirements are just that: A requirement that a particular web page conforms to for it to be considered accessible. A common example of accessibility requirements are the WCAG 2.1 success criteria. Some organizations have additional requirements that come from different sources, such as laws, internal standards, etc. These too are considered accessibility requirements which can be tested using the ACT Rules Format.
+When an ACT Rule is designed to test the conformance to one or more [=Accessibility requirements documents=], the rule MUST list all [=accessibility requirements=] from those documents that are not satisfied when the outcome of the rule is `failed`. For example, when designing a rule for WCAG 2.1 that tests if image buttons have an alternative text, the rule maps to success criteria 1.1.1 Non-text content, and 4.1.2 Name, Role, Value.
+
+Each [=accessibility requirement=] in the mapping MUST include the following:
 
+1. the name, title or summary of the accessibility requirement, and
+2. the name of the [=accessibility requirements document=], and
+3. a link to the [=accessibility requirements document=] if one exists, and
+4. the conformance level associated with the accessibility requirement, if one exists.
 
-Accessibility Requirements List {#accessibility-requirements-list}
-------------------------------------------------------------------
+For each accessibility requirement in the mapping, an ACT Rule MUST indicate what the [=outcome=] of the rule means for satisfying that accessibility requirement. When the outcome is `failed`, the accessibility requirements are *<dfn>not satisfied</dfn>*. When the outcome is `passed` or `inapplicable`, the accessibility requirements could be *<dfn>satisfied</dfn>*, or *<dfn>further testing could be necessary</dfn>*. Rules that can be used to determine if an accessibility requirement is *satisfied* are called <dfn>satisfying tests</dfn>.
 
-An ACT Rule SHOULD list an identifier and reference for each accessibility requirement that it maps to.
+<div class=note>
+**Note**: In WCAG 2.1, 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).
+</div>
 
 <div class=example>
-  <p><strong>Example</strong>: The outcome of this rule affects conformance to the following WCAG 2.1 success criteria:</p>
-  <ul>
-    <li>[1.3.1 Info and Relationships](https://www.w3.org/TR/WCAG21/#info-and-relationships)</li>
-    <li>[4.1.2 Name, Role, Value](https://www.w3.org/TR/WCAG21/#name-role-value)</li>
-  </ul>
+  <p><strong>Example:</strong> Accessibility Requirements Mapping for a rule that tests if an image button has an accessible name:
+  <blockquote><ul>
+    <li><a href="https://www.w3.org/TR/WCAG21/#non-text-content">
+        Success Criterion 1.1.1: Non-text content
+      </a><ul>
+        <li><strong>Required for conformance</strong> to WCAG 2.0 and WCAG 2.1 level A</li>
+        <li>Outcome mapping: <ul>
+          <li>Failed outcome: not satisfied</li>
+          <li>Passed outcome: further testing is needed</li>
+          <li>Inapplicable outcome: further testing is needed</li>
+        </ul></li>
+      </ul>
+    </li>
+    <li><a href="https://www.w3.org/TR/WCAG21/#name-role-value">
+        Success Criterion 4.1.2: Name, Role, Value
+      </a><ul>
+        <li><strong>Required for conformance</strong> to WCAG 2.0 and WCAG 2.1 level A</li>
+        <li>Outcome mapping:<ul>
+          <li>Failed outcome: not satisfied</li>
+          <li>Passed outcome: further testing is needed</li>
+          <li>Inapplicable outcome: further testing is needed</li>
+        </ul></li>
+      </ul>
+    </li>
+  </ul></blockquote>
 </div>
 
-One reason why an [=atomic rule=] might not list accessibility requirements is because it is part of a [=composite rule=], and only a `failed` [=outcome=] in the composite rule would mean not satisfying the accessibility requirement. Another reason might be that an ACT Rule is designed to evaluate a best practice that is not part of any accessibility standard.
+ACT Rules can be used to test accessibility requirements that are not part of a W3C accessibility standard, such as [[WAI-ARIA]] requirements, or a testing methodology like [RGAA 3](https://disic.github.io/rgaa_referentiel_en/criteria.html). An ACT Rule MUST indictate whether or not the [=accessibility requirement=] it maps to is required for conformance in its [=accessibility requirements document=]. Examples of accessibility requirements that are not required for conformance are WCAG sufficient techniques, or a company style guide which includes both requirements and optional "best practices". That distinction between what is required and what is optional has to be made clear.
 
-Accessibility Requirements Mapping {#accessibility-requirements-mapping}
-------------------------------------------------------------------------
+<div class=example>
+  <p><strong>Example:</strong>Accessibility Requirements Mapping for a rule that tests that each `img` element has an `alt` attribute</p>
+  <blockquote><ul>
+    <li><a href="https://www.w3.org/TR/WCAG20-TECHS/H37.html">
+      Technique H37: Using alt attributes on img elements
+      </a><ul>
+        <li><strong>Not required</strong> for conformance to WCAG 2.0 and WCAG 2.1 at any level</li>
+        <li>Outcome mapping: <ul>
+          <li>Failed outcome: not satisfied</li>
+          <li>Passed outcome: satisfied</li>
+          <li>Inapplicable outcome: satisfied</li>
+        </ul></li>
+      </ul>
+    </li>
+    <li><a href="https://disic.github.io/rgaa_referentiel_en/criteria.html#test-1-1-1">
+      RGAA 3, Test 1.1.1: Does each image have a text alternative
+      </a><ul>
+        <li><strong>Required for conformance</strong> to RGAA 3 level A</li>
+        <li>Outcome mapping: <ul>
+          <li>Failed outcome: not satisfied</li>
+          <li>Passed outcome: satisfied</li>
+          <li>Inapplicable outcome: satisfied</li>
+        </ul></li>
+      </ul>
+    </li>
+  </ul></blockquote>
+</div>
+
+If the `failed` outcome can not be mapped to *not satisfied* for an accessibility requirement, that requirement MUST NOT be included in the accessibility requirements mapping. The optional [Background section](#background) could be used to list accessibility requirements and standards that may be thematically related, but for which the rule is not a failure test.
 
-If any accessibility requirements are listed, the ACT Rule MUST indicate how each outcome impacts the conformance to the listed accessibility requirements. For WCAG 2.1 Success Criteria, this means indicating whether or not the success criterion can be satisfied, or if further testing is needed.
+If the rule does not map to any [=accessibility requirement=], the accessibility requirement mapping will only contain the explainer that it is not required for conformance to the [=accessibility requirements document=]. This is common with atomic rules used in composite rules, where accessibility requirements are only not satisfied with multiple atomic rules have the outcome`failed`.
 
 <div class=example>
-  <p><strong>Example</strong>: The outcome of this rule maps to the accessibility requirements in the following manner:</p>
-  <ul>
-    <li>`failed`: The success criteria are *not satisfied*</li>
-    <li>`passed` or `inapplicable`: Further testing is necessary to determine if the success criteria are satisfied</li>
-  </ul>
+  <p><strong>Example:</strong> An ACT Rule that tests a best practice not included in any accessibility standard:</p>
+  <blockquote>
+    <p>This rule is <strong>not required</strong> for conformance to WCAG 2.0 or WCAG 2.1 at any level.</p>
+  </blockquote>
 </div>
 
 <div class=note>
-  **Note**: In WCAG 2.1, 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).
+**Note**: While rules are often designed for one, or possibly a small collection of [=accessibility requirements document=], it is likely that other accessibility requirements documents also map to those rules. For example, rules may be written for WCAG 2.1, but many of those may map to a company's internal accessibility policy. In such a scenario, an external accessibility requirements mapping could be created. An external accessibility requirements mapping ammend the accessibility requirements mapping of a rule by adding mapping to a different accessibility requirements document. An external accessibility requirements mapping avoids duplication of a rule, for the sole purpose of changing the mapping.
 </div>
 
 
@@ -360,9 +413,9 @@ There are two types of inaccuracies that can produce incorrect results. Inaccura
 
 When a test result incorrectly indicates non-conformance to an accessibility requirement, this is known as a false positive. Opposite, when a rule incorrectly indicates conformance, this is a false negative. A percentage of false positives and false negatives can be calculated by comparing it to results from an accessibility audit:
 
-- **False positives**: This is the percentage of [=test subjects=], that were `failed` by the rule, but conform to the [accessibility requirements](#accessibility-requirements).
+- **False positives**: This is the percentage of [=test subjects=], that were `failed` by the rule, but conform to the [=accessibility requirements=].
 
-- **False negatives**: This is the percentage of [=test subjects=], that were `passed` by the rule, but were non-conformant to the [accessibility requirements](#accessibility-requirements).
+- **False negatives**: This is the percentage of [=test subjects=], that were `passed` by the rule, but were non-conformant to the [=accessibility requirements=].
 
 The possibility of false positives and false negatives with ACT Rules mean they will likely require ongoing maintainence. Designing a process for maintaining ACT Rules is outside the scope of the ACT Rules Format, which is limited to the rules themselves. Neverthless, it is suggested that rule authors work out a process for maintaining their rules.
 
@@ -391,6 +444,17 @@ Definitions {#definitions}
 ==========================
 
 <dl>
+  <dt><dfn>Accessibility requirement</dfn><dt>
+  <dd>
+    <p>A requirement is a condition that has to be satisfied in order to conform to a standard, or to comply with a contract, policy or regulation. An accessibility requirement is a requirement aimed at improving access for people with disabilities to an ICT product.</p>
+    <p>A common example of accessibility requirements are the WCAG 2.1 success criteria. There are other standards, including W3C standards that include recommendations for accessibility, such as WAI-ARIA and HTML. Accessibility requirements are also often found in company policies, regional standards or in legislation.</p>
+  </dd>
+
+  <dt><dfn>Accessibility requirements document</dfn><dt>
+  <dd>
+    <p>A document, such as a standard, contract, policy or regulation, that includes [=accessibility requiremenst=]. For example, WCAG 2.1, WAI-ARIA 1.1, HTML 5.2, BBC HTML Accessibility Standards v2.0</p>
+  </dd>
+
   <dt><dfn>Test Subject</dfn></dt>
   <dd>
     <p>A resource or collection of resources that can be evaluated by an ACT Rule.</p>
@@ -432,7 +496,7 @@ Definitions {#definitions}
       <li>**Failed**: The test subject does not meet all expectations</li>
     </ul>
     <div class="note">
-      <p><strong>Note</strong>: While *inapplicable* is a valid outcome for ACT Rules, it might not be a valid result for all [accessibility requirements](#accessibility-requirements). Notably the success criteria of WCAG 2.0 and WCAG 2.1 can only be evaluated to satisfied (passed and inapplicable) or not satisfied (failed).</p>
+      <p><strong>Note</strong>: While *inapplicable* is a valid outcome for ACT Rules, it might not be a valid result for all [=accessibility requirements=]. Notably the success criteria of WCAG 2.0 and WCAG 2.1 can only be evaluated to satisfied (passed and inapplicable) or not satisfied (failed).</p>
     </div>
     <div class="note">
       <p><strong>Note</strong>: Implementers using the [[EARL10-Schema]] can express the outcome with the [outcome property](https://www.w3.org/TR/EARL10-Schema/#outcome). In addition to `passed` `failed` and `inapplicable`, EARL 1.0 also defined an `incomplete` outcome. While this can not be the outcome of an ACT Rule when applied in its entirety, it often happens that rules are only partially evaluated. For example, when applicability was automated, but the expectations have to be evaluated manually. Such "interim" results can be expressed with the `incomplete` outcome.
@@ -553,17 +617,17 @@ This section is *non-normative*.
 }
 ```
 
-Appendix 2: Acknowledgments
+Appendix 2: Acknowledgments {#Acknowledgments}
 ===========================
 
 This section is *non-normative*.
 
-Participants of the AG WG active in the development of this document
+Participants of the AG WG active in the development of this document {#participants}
 --------------------------------------------------------------------
 
 Shadi Abou-Zahra, Trevor Bostic, Romain Deltour, Kathy Eng, Wilco Fiers, Alistair Garrison, Kasper Isager, Maureen Kraft, Mary Jo Mueller, Jey Nandakumar, Charu Pandhi, Stein Erik Skotkjerra, Anne Thyme Nørregaard, Kathleen Wahlbin
 
-Enabling funders
+Enabling funders {#enabling-funders}
 ----------------
 
 This publication has been developed with support from the [WAI-Tools Project](https://www.w3.org/WAI/about/projects/wai-tools/), co-funded by the European Commission (EC) under the Horizon 2020 Program (Grant Agreement 780057). The content of this publication does not necessarily reflect the views or policies of the European Commission (EC) or any of the European Union (EU) Member States.