From d06205a8dfb75eb42dea13b2a4a5baab25ef1ec9 Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Fri, 15 Jul 2022 14:59:21 -0400 Subject: [PATCH 01/54] Update act-rules-format.md --- act-rules-format.md | 61 ++++++++++++++++++++++++++++++++++++++------- 1 file changed, 52 insertions(+), 9 deletions(-) diff --git a/act-rules-format.md b/act-rules-format.md index 36dc62d6..dd1d31b5 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -170,35 +170,73 @@ Each [=accessibility requirement=] in the mapping must 4. the conformance level associated with the accessibility requirement, if one exists. -### Outcome Mapping ### {#outcome-mapping} +### Mapping Conformance Requirements ### {#mapping-conformance-requirements} -For each accessibility requirement in the mapping, an ACT Rule must 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 not satisfied for the test subject. When all of the outcomes are `passed` or `inapplicable`, the accessibility requirements could be satisfied, or further testing is needed. Rules that can be used to determine if an accessibility requirement is *satisfied* are called satisfying tests. +For each accessibility requirement in the mapping, an ACT Rule must 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 not satisfied for the test subject. When all of the outcomes are `passed`, the accessibility requirements would be satisfied. When all of the outcomes are `inapplicable`, further testing is needed. Rules that can be used to determine if an accessibility requirement is *satisfied* are called satisfying tests.

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

+ +### Mapping Secondary Requirements (Optional) ### + +An ACT Rule may show that the outcomes of the rule have related or secondary [=accessibility requirements=] for that test subject. The secondary accessibility requirements may not be required for conformance to the [=accessibility requirements document=]. When one or more of the outcomes for a test target is `failed`, the secondary accessibility requirement could be not satisfied for the test subject or further testing is needed . When all of the outcomes are `passed` or `inapplicable`, the secondary accessibility requirement could be satisfied or further testing is needed. The rule must explain the secondary relationship of the accessibility requirement to the rule. + + + + -### Mapping Secondary Requirements (Optional) ### +### Mapping Secondary Requirements ### An ACT Rule may show that the outcomes of the rule have related or secondary [=accessibility requirements=] for that test subject. The secondary accessibility requirements may not be required for conformance to the [=accessibility requirements document=]. When one or more of the outcomes for a test target is `failed`, the secondary accessibility requirement could be not satisfied for the test subject or further testing is needed . When all of the outcomes are `passed` or `inapplicable`, the secondary accessibility requirement could be satisfied or further testing is needed. The rule must explain the secondary relationship of the accessibility requirement to the rule. From 3a42ca5286cce0c373e7df0d8c34e11d6f902cd1 Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Wed, 10 Aug 2022 19:08:43 -0400 Subject: [PATCH 07/54] Update act-rules-format.md edits in response to feedback --- act-rules-format.md | 43 +++++++++++++++++++++++++++++-------------- 1 file changed, 29 insertions(+), 14 deletions(-) diff --git a/act-rules-format.md b/act-rules-format.md index 9140157a..5e5e2ad3 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -160,7 +160,7 @@ 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 must 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 must list all [=accessibility requirements=] from those documents that are not satisfied when one or more of the [=outcomes=] of the rule is `failed`. Each [=accessibility requirement=] in the mapping must include the following: @@ -172,17 +172,30 @@ Each [=accessibility requirement=] in the mapping must ### Mapping Conformance Requirements ### {#mapping-conformance-requirements} -For each accessibility requirement in the mapping, an ACT Rule must 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 not satisfied for the test subject. When all of the outcomes are `passed` or `inapplicable`, the accessibility requirements could be satisfied, or further testing is needed. Rules that can be used to determine if an accessibility requirement is *satisfied* are called satisfying tests. +An ACT Rule must indicate what the [=outcomes=] of the rule mean for satisfying an accessibility requirement for that [=test subject=]. A conformance requirement mapped in a rule is an accessibility requirement that is not satisfied when all of the outcomes for a test target in failed test cases is `failed`. When all of the outcomes for passed test cases or inapplicable test cases are `passed` or `inapplicable`, respectively, the mapped conformance requirement could be satisfied or further testing is needed. Rules that can be used to determine if an accessibility requirement is *satisfied* are called satisfying tests.

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

+When a `failed` outcome of the rule can determine that an accessibility requirement is not satisfied, the accessibility requirement must be listed as a Conformance Requirement. That ACT Rule will list each success criteria in its accessibility requirements mapping as **Required for Conformance**. + ### Mapping for Atomic Rules ### {mapping-for-atomic-rules} -Mapping of requirements in atomic rules that are part of composite rules is limited to the conformance and incidental accessibility requirements mapped in their composite rules. +Atomic rules may map to conformance requirements, secondary accessibility requirements, or no accessibility requirements. ### Mapping for Composite Rules ### {mapping-for-composite-rules} -The Accessibility Requirements mapping for Composite Rules must include all mapped (conformance and secondary) requirements in atomic rules. +The Accessibility Requirements mapping for Composite Rules must include all mapped requirements in atomic rules. ### Mapping Outside WCAG ### {#mapping-outside-wcag} From 8aab815cc545150b134aa0416b5b785e73627d16 Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Thu, 25 Aug 2022 17:08:11 -0400 Subject: [PATCH 08/54] Update act-rules-format.md --- act-rules-format.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.md b/act-rules-format.md index 5e5e2ad3..11a29a16 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -209,7 +209,7 @@ When a `failed` outcome of the rule can determine that an accessibility requirem ### Mapping Associated/Affiliated/Secondary Requirements ### - +When an ACT Rule is designed to test conformance to an [=accessibility requirement=], the rule may have outcomes for other [=accessibility requirements=] that are not consistent with the rule and do not meet the criteria to be mapped as Conformance Requirements. An ACT Rule may show that the outcomes of the rule have secondary [=accessibility requirements=] for that test subject. When all of the outcomes for a test target in failed test cases is `failed` but an accessibility requirement cannot be listed as not satisfied, the accessibiity requirement must be listed as a secondary requirement and further testing is needed. When all outcomes for a test target in passed test cases are not `passed`, the mapped secondary accessibility requirement is further testing is needed. The rule must explain the secondary relationship of the accessibility requirement in the Background section of the rule. From 4dc257ec4af5afaf54670adab02d05013c5ea035 Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Thu, 25 Aug 2022 17:08:54 -0400 Subject: [PATCH 09/54] Update act-rules-format.md --- act-rules-format.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/act-rules-format.md b/act-rules-format.md index 11a29a16..208cce9b 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -210,7 +210,10 @@ When a `failed` outcome of the rule can determine that an accessibility requirem ### Mapping Associated/Affiliated/Secondary Requirements ### When an ACT Rule is designed to test conformance to an [=accessibility requirement=], the rule may have outcomes for other [=accessibility requirements=] that are not consistent with the rule and do not meet the criteria to be mapped as Conformance Requirements. -An ACT Rule may show that the outcomes of the rule have secondary [=accessibility requirements=] for that test subject. When all of the outcomes for a test target in failed test cases is `failed` but an accessibility requirement cannot be listed as not satisfied, the accessibiity requirement must be listed as a secondary requirement and further testing is needed. When all outcomes for a test target in passed test cases are not `passed`, the mapped secondary accessibility requirement is further testing is needed. +An ACT Rule may have outcomes for secondary [=accessibility requirements=] for that test subject. Accessibility requirements must be mapped as secondary if one or more of the following is true: + +- further testing is needed when one or more of the outcomes for a test target is `failed`, or +- the accessibility requirement can be satisfied, further testing is needed, or not satisfiedwhen all the outcomes are `passed`. The rule must explain the secondary relationship of the accessibility requirement in the Background section of the rule. From 4149fc8a2e4cb460bd057e19c419ac73746c1dbe Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Thu, 25 Aug 2022 17:13:28 -0400 Subject: [PATCH 10/54] Update act-rules-format.md --- act-rules-format.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.md b/act-rules-format.md index 208cce9b..891f44d5 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -209,7 +209,7 @@ When a `failed` outcome of the rule can determine that an accessibility requirem ### Mapping Associated/Affiliated/Secondary Requirements ### -When an ACT Rule is designed to test conformance to an [=accessibility requirement=], the rule may have outcomes for other [=accessibility requirements=] that are not consistent with the rule and do not meet the criteria to be mapped as Conformance Requirements. +When an ACT Rule is designed to test conformance to an [=accessibility requirement=], the rule may have outcomes for other [=accessibility requirements=] that are not consistent with the rule. These other accessibility requirements do not meet the criteria to be Conformance Requirements and should be mapped as secondary requirements. An ACT Rule may have outcomes for secondary [=accessibility requirements=] for that test subject. Accessibility requirements must be mapped as secondary if one or more of the following is true: - further testing is needed when one or more of the outcomes for a test target is `failed`, or From 94e3ddb532626e4da81d6c3800fa02d3fa4c302a Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Thu, 25 Aug 2022 17:16:37 -0400 Subject: [PATCH 11/54] Update act-rules-format.md --- act-rules-format.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/act-rules-format.md b/act-rules-format.md index 891f44d5..3d7027a2 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -210,7 +210,8 @@ When a `failed` outcome of the rule can determine that an accessibility requirem ### Mapping Associated/Affiliated/Secondary Requirements ### When an ACT Rule is designed to test conformance to an [=accessibility requirement=], the rule may have outcomes for other [=accessibility requirements=] that are not consistent with the rule. These other accessibility requirements do not meet the criteria to be Conformance Requirements and should be mapped as secondary requirements. -An ACT Rule may have outcomes for secondary [=accessibility requirements=] for that test subject. Accessibility requirements must be mapped as secondary if one or more of the following is true: + +Map an accessibility requirements as secondary if one or more of the following is true: - further testing is needed when one or more of the outcomes for a test target is `failed`, or - the accessibility requirement can be satisfied, further testing is needed, or not satisfiedwhen all the outcomes are `passed`. From 1edfa969f5048d14179bc425ac08298d45b20086 Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Thu, 25 Aug 2022 17:17:48 -0400 Subject: [PATCH 12/54] Update act-rules-format.md --- act-rules-format.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/act-rules-format.md b/act-rules-format.md index 3d7027a2..91f94eb4 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -213,7 +213,8 @@ When an ACT Rule is designed to test conformance to an [=accessibility requireme Map an accessibility requirements as secondary if one or more of the following is true: -- further testing is needed when one or more of the outcomes for a test target is `failed`, or +
    +
  • further testing is needed when one or more of the outcomes for a test target is `failed`, or
    • - the accessibility requirement can be satisfied, further testing is needed, or not satisfiedwhen all the outcomes are `passed`. The rule must explain the secondary relationship of the accessibility requirement in the Background section of the rule. From d78ced1166719018b3ed113d8f98628bb2b14176 Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Thu, 25 Aug 2022 17:19:41 -0400 Subject: [PATCH 13/54] Update act-rules-format.md --- act-rules-format.md | 1 - 1 file changed, 1 deletion(-) diff --git a/act-rules-format.md b/act-rules-format.md index 91f94eb4..1dcc4b79 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -213,7 +213,6 @@ When an ACT Rule is designed to test conformance to an [=accessibility requireme Map an accessibility requirements as secondary if one or more of the following is true: -
    • further testing is needed when one or more of the outcomes for a test target is `failed`, or
      • - the accessibility requirement can be satisfied, further testing is needed, or not satisfiedwhen all the outcomes are `passed`. From 50e6f96f00d0717137d9b72c8551f66f804bef0b Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Thu, 25 Aug 2022 17:20:09 -0400 Subject: [PATCH 14/54] Update act-rules-format.md --- act-rules-format.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.md b/act-rules-format.md index 1dcc4b79..0b7f9dea 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -213,7 +213,7 @@ When an ACT Rule is designed to test conformance to an [=accessibility requireme Map an accessibility requirements as secondary if one or more of the following is true: -
    • further testing is needed when one or more of the outcomes for a test target is `failed`, or
      • +- further testing is needed when one or more of the outcomes for a test target is `failed`, or - the accessibility requirement can be satisfied, further testing is needed, or not satisfiedwhen all the outcomes are `passed`. The rule must explain the secondary relationship of the accessibility requirement in the Background section of the rule. From ad065fad560d7236d6c637ce771274fe76a7aa33 Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Thu, 25 Aug 2022 17:23:42 -0400 Subject: [PATCH 15/54] Update act-rules-format.md --- act-rules-format.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.md b/act-rules-format.md index 0b7f9dea..ad44dd2e 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -214,7 +214,7 @@ When an ACT Rule is designed to test conformance to an [=accessibility requireme Map an accessibility requirements as secondary if one or more of the following is true: - further testing is needed when one or more of the outcomes for a test target is `failed`, or -- the accessibility requirement can be satisfied, further testing is needed, or not satisfiedwhen all the outcomes are `passed`. +- further testing is needed or the accessibility requirement is not satisfiedwhen the outcome for a test target is `passed`. The rule must explain the secondary relationship of the accessibility requirement in the Background section of the rule. From 428c7773a452a80708239fe79144ff50588e936e Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Thu, 25 Aug 2022 18:03:40 -0400 Subject: [PATCH 16/54] Update act-rules-format.md --- act-rules-format.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.md b/act-rules-format.md index ad44dd2e..dc128d8a 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -209,7 +209,7 @@ When a `failed` outcome of the rule can determine that an accessibility requirem ### Mapping Associated/Affiliated/Secondary Requirements ### -When an ACT Rule is designed to test conformance to an [=accessibility requirement=], the rule may have outcomes for other [=accessibility requirements=] that are not consistent with the rule. These other accessibility requirements do not meet the criteria to be Conformance Requirements and should be mapped as secondary requirements. +When an ACT Rule's passed or failed outcomes have different meanings for an accessibility requirements from what is described in Conformance requirements, these accessibility requirements are mapped as secondary requirements. Map an accessibility requirements as secondary if one or more of the following is true: From 62ad17ae01c8e54282e6a62c8eee5a1b09a50739 Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Thu, 25 Aug 2022 18:06:59 -0400 Subject: [PATCH 17/54] Update act-rules-format.md --- act-rules-format.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/act-rules-format.md b/act-rules-format.md index dc128d8a..3a12bc41 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -213,7 +213,8 @@ When an ACT Rule's passed or failed outcomes have different meanings for an acce Map an accessibility requirements as secondary if one or more of the following is true: -- further testing is needed when one or more of the outcomes for a test target is `failed`, or +- further testing is needed when one or more of the outcomes for a test target is `failed`, and the accessibility requirement is satisfied when all outcomes are `passed`, + - further testing is needed or the accessibility requirement is not satisfiedwhen the outcome for a test target is `passed`. The rule must explain the secondary relationship of the accessibility requirement in the Background section of the rule. From 3d83ed9be6776875be1a4ddfbb63d65c41134cc5 Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Thu, 25 Aug 2022 18:07:33 -0400 Subject: [PATCH 18/54] Update act-rules-format.md --- act-rules-format.md | 1 + 1 file changed, 1 insertion(+) diff --git a/act-rules-format.md b/act-rules-format.md index 3a12bc41..c2ae6d99 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -214,6 +214,7 @@ When an ACT Rule's passed or failed outcomes have different meanings for an acce Map an accessibility requirements as secondary if one or more of the following is true: - further testing is needed when one or more of the outcomes for a test target is `failed`, and the accessibility requirement is satisfied when all outcomes are `passed`, +or - further testing is needed or the accessibility requirement is not satisfiedwhen the outcome for a test target is `passed`. From 7850c847949c0165e6b7c790b2c36b2d89332691 Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Thu, 25 Aug 2022 18:11:48 -0400 Subject: [PATCH 19/54] Update act-rules-format.md --- act-rules-format.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.md b/act-rules-format.md index c2ae6d99..a7810b48 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -216,7 +216,7 @@ Map an accessibility requirements as secondary if one or more of the following i - further testing is needed when one or more of the outcomes for a test target is `failed`, and the accessibility requirement is satisfied when all outcomes are `passed`, or -- further testing is needed or the accessibility requirement is not satisfiedwhen the outcome for a test target is `passed`. +- the accessibility requirement is not satisfied when one or more outcomes for a test target is `failed`, and is not satisfiedwhen the outcome is `passed`. The rule must explain the secondary relationship of the accessibility requirement in the Background section of the rule. From c6604c677908e615c755073d6012d4568f31c10b Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Thu, 25 Aug 2022 18:14:34 -0400 Subject: [PATCH 20/54] Update act-rules-format.md --- act-rules-format.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.md b/act-rules-format.md index a7810b48..f37214a3 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -211,7 +211,7 @@ When a `failed` outcome of the rule can determine that an accessibility requirem ### Mapping Associated/Affiliated/Secondary Requirements ### When an ACT Rule's passed or failed outcomes have different meanings for an accessibility requirements from what is described in Conformance requirements, these accessibility requirements are mapped as secondary requirements. -Map an accessibility requirements as secondary if one or more of the following is true: +Map an accessibility requirements as secondary for the following rule outcomes: - further testing is needed when one or more of the outcomes for a test target is `failed`, and the accessibility requirement is satisfied when all outcomes are `passed`, or From 3321f8f6cf0f395dfc48a5fe6d0d07fd5ea0ba94 Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Thu, 25 Aug 2022 18:20:16 -0400 Subject: [PATCH 21/54] Update act-rules-format.md --- act-rules-format.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.md b/act-rules-format.md index f37214a3..93c3dae8 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -213,7 +213,7 @@ When an ACT Rule's passed or failed outcomes have different meanings for an acce Map an accessibility requirements as secondary for the following rule outcomes: -- further testing is needed when one or more of the outcomes for a test target is `failed`, and the accessibility requirement is satisfied when all outcomes are `passed`, +- "OR": further testing is needed when one or more of the outcomes for a test target is `failed`, and the accessibility requirement is satisfied when all outcomes are `passed`, or - the accessibility requirement is not satisfied when one or more outcomes for a test target is `failed`, and is not satisfiedwhen the outcome is `passed`. From f1d405142b76a3c78276b8b8d767dbaf6b910abd Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Thu, 25 Aug 2022 18:21:46 -0400 Subject: [PATCH 22/54] Update act-rules-format.md --- act-rules-format.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.md b/act-rules-format.md index 93c3dae8..51a14d75 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -216,7 +216,7 @@ Map an accessibility requirements as secondary for the following rule outcomes: - "OR": further testing is needed when one or more of the outcomes for a test target is `failed`, and the accessibility requirement is satisfied when all outcomes are `passed`, or -- the accessibility requirement is not satisfied when one or more outcomes for a test target is `failed`, and is not satisfiedwhen the outcome is `passed`. +- "AAA": the accessibility requirement is not satisfied when one or more outcomes for a test target is `failed`, and is not satisfiedwhen all outcomes are `passed`. The rule must explain the secondary relationship of the accessibility requirement in the Background section of the rule. From c2cb8bda967478199690373a42c32c32e3ebcbf3 Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Thu, 25 Aug 2022 18:24:33 -0400 Subject: [PATCH 23/54] Update act-rules-format.md --- act-rules-format.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.md b/act-rules-format.md index 51a14d75..eae157fb 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -212,7 +212,7 @@ When a `failed` outcome of the rule can determine that an accessibility requirem When an ACT Rule's passed or failed outcomes have different meanings for an accessibility requirements from what is described in Conformance requirements, these accessibility requirements are mapped as secondary requirements. Map an accessibility requirements as secondary for the following rule outcomes: - +- "AAA": the accessibility requirement is not satisfied when one or more outcomes for a test target is `failed`, and is not satisfiedwhen all outcomes are `passed`. - "OR": further testing is needed when one or more of the outcomes for a test target is `failed`, and the accessibility requirement is satisfied when all outcomes are `passed`, or From b59f9c58067d896953b7369ad475c2356177d42b Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Thu, 25 Aug 2022 18:25:03 -0400 Subject: [PATCH 24/54] Update act-rules-format.md --- act-rules-format.md | 1 - 1 file changed, 1 deletion(-) diff --git a/act-rules-format.md b/act-rules-format.md index eae157fb..6a136d70 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -214,7 +214,6 @@ When an ACT Rule's passed or failed outcomes have different meanings for an acce Map an accessibility requirements as secondary for the following rule outcomes: - "AAA": the accessibility requirement is not satisfied when one or more outcomes for a test target is `failed`, and is not satisfiedwhen all outcomes are `passed`. - "OR": further testing is needed when one or more of the outcomes for a test target is `failed`, and the accessibility requirement is satisfied when all outcomes are `passed`, -or - "AAA": the accessibility requirement is not satisfied when one or more outcomes for a test target is `failed`, and is not satisfiedwhen all outcomes are `passed`. From ca1fde0e3ca97231ec04091c7778b25e0aee9547 Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Thu, 25 Aug 2022 18:25:21 -0400 Subject: [PATCH 25/54] Update act-rules-format.md --- act-rules-format.md | 1 - 1 file changed, 1 deletion(-) diff --git a/act-rules-format.md b/act-rules-format.md index 6a136d70..0f48571f 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -215,7 +215,6 @@ Map an accessibility requirements as secondary for the following rule outcomes: - "AAA": the accessibility requirement is not satisfied when one or more outcomes for a test target is `failed`, and is not satisfiedwhen all outcomes are `passed`. - "OR": further testing is needed when one or more of the outcomes for a test target is `failed`, and the accessibility requirement is satisfied when all outcomes are `passed`, -- "AAA": the accessibility requirement is not satisfied when one or more outcomes for a test target is `failed`, and is not satisfiedwhen all outcomes are `passed`. The rule must explain the secondary relationship of the accessibility requirement in the Background section of the rule. From 0463d8a0059a342c1502cb1a0d177087ac75ed65 Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Thu, 25 Aug 2022 18:30:11 -0400 Subject: [PATCH 26/54] Update act-rules-format.md --- act-rules-format.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/act-rules-format.md b/act-rules-format.md index 0f48571f..8172f550 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -172,7 +172,15 @@ Each [=accessibility requirement=] in the mapping must ### Mapping Conformance Requirements ### {#mapping-conformance-requirements} -An ACT Rule must indicate what the [=outcomes=] of the rule mean for satisfying an accessibility requirement for that [=test subject=]. A conformance requirement mapped in a rule is an accessibility requirement that is not satisfied when all of the outcomes for a test target in failed test cases is `failed`. When all of the outcomes for passed test cases or inapplicable test cases are `passed` or `inapplicable`, respectively, the mapped conformance requirement could be satisfied or further testing is needed. Rules that can be used to determine if an accessibility requirement is *satisfied* are called satisfying tests. +An ACT Rule must indicate what the [=outcomes=] of the rule mean for satisfying an accessibility requirement for that [=test subject=]. + +A conformance requirement mapped in a rule: + +- is not satisfied when one or more outcomes for a test target is `failed`, and +- can be satisfied or further testing is needed, but cannot be not satisfied when all of the outcomes are `passed` or `inapplicable` . + +Rules that can be used to determine if an accessibility requirement is *satisfied* are called satisfying tests. +

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

      From a54100dff4cfe100d6b052683b9e44119475d9ef Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Thu, 25 Aug 2022 18:38:29 -0400 Subject: [PATCH 27/54] Update act-rules-format.md --- act-rules-format.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.md b/act-rules-format.md index 8172f550..ffb524c9 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -272,7 +272,7 @@ The rule must explain the secondary relationship of the accessibility requiremen ### Mapping for Atomic Rules ### {mapping-for-atomic-rules} -Atomic rules may map to conformance requirements, secondary accessibility requirements, or no accessibility requirements. +Conformance requirements and secondary requirements must be included in the Accessibility Requirements of atomic rules. ### Mapping for Composite Rules ### {mapping-for-composite-rules} The Accessibility Requirements mapping for Composite Rules must include all mapped requirements in atomic rules. From 6b3314ec0126853095b236bd4a2e239a0daeff3d Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Wed, 7 Sep 2022 19:29:22 -0400 Subject: [PATCH 28/54] Update act-rules-format.md --- act-rules-format.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.md b/act-rules-format.md index ffb524c9..91b5fba4 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -176,7 +176,7 @@ An ACT Rule must indicate what the [=outcomes=] of the A conformance requirement mapped in a rule: -- is not satisfied when one or more outcomes for a test target is `failed`, and +- is not satisfied when one or more outcomes for a test subject is `failed`, and - can be satisfied or further testing is needed, but cannot be not satisfied when all of the outcomes are `passed` or `inapplicable` . Rules that can be used to determine if an accessibility requirement is *satisfied* are called satisfying tests. From d1c0d9ea7bdc8defc10e7e9decc789d098ca251b Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Wed, 21 Sep 2022 20:10:33 -0400 Subject: [PATCH 29/54] Update act-rules-format.md --- act-rules-format.md | 43 +++++++++++++++++++++++-------------------- 1 file changed, 23 insertions(+), 20 deletions(-) diff --git a/act-rules-format.md b/act-rules-format.md index 91b5fba4..02c41336 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -169,25 +169,22 @@ Each [=accessibility requirement=] in the mapping must 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 +For each accessibility requirement in the mapping, an ACT Rule must indicate what the [=outcomes=] of the rule mean for satisfying an accessibility requirement for that [=test subject=]. -### Mapping Conformance Requirements ### {#mapping-conformance-requirements} +#### Mapping Conformance Requirements ### {#mapping-conformance-requirements} -An ACT Rule must indicate what the [=outcomes=] of the rule mean for satisfying an accessibility requirement for that [=test subject=]. - -A conformance requirement mapped in a rule: - -- is not satisfied when one or more outcomes for a test subject is `failed`, and -- can be satisfied or further testing is needed, but cannot be not satisfied when all of the outcomes are `passed` or `inapplicable` . +An accessibility requirement is mapped as a conformance requirement in a rule when both of the following are true: +- When one or more of the outcomes for a test target is `failed`, the accessibility requirement is not satisfied for the test subject, and +- When all of the outcomes are `passed` or `inapplicable`, the accessibility requirement could be satisfied or further testing is needed. The accessibility requirement can not be not satisfied. + Rules that can be used to determine if an accessibility requirement is *satisfied* are called satisfying tests. -

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

      -When a `failed` outcome of the rule can determine that an accessibility requirement is not satisfied, the accessibility requirement must be listed as a Conformance Requirement. That ACT Rule will list each success criteria in its accessibility requirements mapping as **Required for Conformance**. - -### Mapping Associated/Affiliated/Secondary Requirements ### -When an ACT Rule's passed or failed outcomes have different meanings for an accessibility requirements from what is described in Conformance requirements, these accessibility requirements are mapped as secondary requirements. +#### Mapping Secondary Requirements #### +An accessibility requirement is mapped as a secondary requirement in a rule when both of the following are true: -Map an accessibility requirements as secondary for the following rule outcomes: -- "AAA": the accessibility requirement is not satisfied when one or more outcomes for a test target is `failed`, and is not satisfiedwhen all outcomes are `passed`. -- "OR": further testing is needed when one or more of the outcomes for a test target is `failed`, and the accessibility requirement is satisfied when all outcomes are `passed`, +- (a.) When one or more of the outcomes for a test target is `failed`, the accessibility requirement is not satisfied or further testing is needed for the test subject, or +- (b.) When all of the outcomes are `passed` or `inapplicable`, the accessibility requirement could be satisfied or further testing is needed or not satisfied. + +When all of these are true, the accessibility requirement is mapped as a conformance requirement. + +**Temporary**: these are the situations discussed that necessitated a secondary requirements category: +- requirement is sticter than the rule (contrast AAA): the accessibility requirement is (a.)not satisfied when one or more outcomes for a test target is `failed`, and is (b.) not satisfiedwhen all outcomes for the rule are `passed`. +- rule tests a specific type of solution (keyboard trap std nav): (a.)further testing is needed when one or more of the outcomes for a test target is `failed`, and the accessibility requirement is (b.)satisfied when all outcomes are `passed`, +- conditions outside of rule, (link area 1.1.1): (a.)further testing is needed when one or more of the outcomes for a test target is `failed`, and (b.) is further testing is needed when all outcomes are `passed` The rule must explain the secondary relationship of the accessibility requirement in the Background section of the rule.
    -#### Secondary Requirements #### +#### Secondary Requirements #### {#secondary-requirements} 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 test cases not satisfying these secondary accessibility requirements. From 0f6dea96b2f400085c37e5dc67b537a0a281d942 Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Tue, 6 Dec 2022 15:44:48 -0500 Subject: [PATCH 48/54] Update act-rules-format.md --- act-rules-format.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/act-rules-format.md b/act-rules-format.md index 30adaf51..63ae2682 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -184,6 +184,8 @@ When a rule is designed to test a specific accessibility requirement, the access Rules that can be used to determine if an accessibility requirement is *satisfied* are called satisfying tests. +- Passed: When all of the outcomes are `passed`, the accessibility requirement is satisfied. +

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

    From b6ec42ba3fea71aef4c503b2b1de208eeae5c700 Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Tue, 6 Dec 2022 17:22:01 -0500 Subject: [PATCH 49/54] Update act-rules-format.md --- act-rules-format.md | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/act-rules-format.md b/act-rules-format.md index 63ae2682..f21b4adb 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -184,7 +184,7 @@ When a rule is designed to test a specific accessibility requirement, the access Rules that can be used to determine if an accessibility requirement is *satisfied* are called satisfying tests. -- Passed: When all of the outcomes are `passed`, the accessibility requirement is satisfied. +- Passed: When all of the outcomes are `passed`, the accessibility requirement is satisfied for the test subject.

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

    @@ -220,16 +220,16 @@ Rules that can be used to determine if an accessibility requirement is *satisfie #### Secondary Requirements #### {#secondary-requirements} -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 test cases not satisfying these secondary accessibility requirements. +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 may 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 +**Scenario 1**: the rule is not as strict as a 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. +A rule was designed to test a minimum accessibility requirement and there exists a stricter requirement. 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 rule's outcomes are passed. The stricter requirement is a Secondary requirement. -**Scenario 2**: only the "Passed or Inapplicable Outcomes" are true for the requirement -
      -
    1. 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.
      2. +**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. -
    2. 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.
      3. +**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. -
- -**Scenario 3**: both outcomes are only sometimes true + +**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. From 17350feed38e7dc019cee17e6617d350b6a365ea Mon Sep 17 00:00:00 2001 From: Wilco Fiers Date: Wed, 18 Jan 2023 15:47:38 +0100 Subject: [PATCH 50/54] Update version & editors --- act-rules-format.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/act-rules-format.md b/act-rules-format.md index f21b4adb..c5807ce6 100644 --- a/act-rules-format.md +++ b/act-rules-format.md @@ -1,16 +1,18 @@ 
-Title: Accessibility Conformance Testing (ACT) Rules Format
+Title: Accessibility Conformance Testing (ACT) Rules Format 1.1
 Shortname: ACT-Rules-Format
 URL: https://w3c.github.io/wcag-act/act-rules-format.html
-Previous Version: https://w3c.github.io/wcag-act/archive_act-format/2019-07-12.html
-Level: 1.0
+Previous Version: https://w3c.github.io/wcag-act/archive_act-format/2019-07-22.html
+Level: 1.1
 Status: w3c/ED
 Group: act-rules-format
 Editor: Wilco Fiers, Deque Systems
-Editor: Maureen Kraft, IBM Corp.
-Editor: Mary Jo Mueller, IBM Corp.
-Editor: Shadi Abou-Zahra, W3C
-Abstract: The Accessibility Conformance Testing (ACT) Rules Format 1.0 defines a format for writing accessibility test rules. These test rules can be used for developing automated testing tools and manual testing methodologies. It provides a common format that allows any party involved in accessibility testing to document and share their testing procedures in a robust and understandable manner. This enables transparency and harmonization of testing methods, including methods implemented by accessibility test tools.
+Editor: Katherine Eng, US Access Board
+Editor: Trevor Bostic, MITRE Corp.
+Former Editor: Maureen Kraft, IBM Corp.
+Former Editor: Mary Jo Mueller, IBM Corp.
+Former Editor: Shadi Abou-Zahra, W3C
+Abstract: The Accessibility Conformance Testing (ACT) Rules Format 1.1 defines a format for writing accessibility test rules. These test rules can be used for developing automated testing tools and manual testing methodologies. It provides a common format that allows any party involved in accessibility testing to document and share their testing procedures in a robust and understandable manner. This enables transparency and harmonization of testing methods, including methods implemented by accessibility test tools.
 Markup Shorthands: markdown yes
- -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](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 conformance to WCAG and other [=accessibility requirements documents=] and promote consistent results in accessibility testing. The rules format is designed to describe both manual accessibility tests, as well as automated tests as performed by accessibility testing tools. - -Documenting how to test [=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). - -An ACT Rule is a plain language description of how to test a specific type of content for a specific aspect of an accessibility requirement. An ACT Rule describes what kind of content it applies to and which conditions are true about the applicable elements for them to meet all expectations of the rule. In the context of WCAG, ACT Rules test for failures in satisfying Success Criteria. Such failures are often described in [common failures](https://www.w3.org/TR/WCAG21/#wcag-2-layers-of-guidance) documented for WCAG. ACT Rules are written for the testing process and are usually more specific than common failures. - -The ACT Rules Format defines the requirements and rule structure for the types of information each rule needs to include to be called an ACT Rule. The structure of the ACT rule is defined in the [ACT Rule Structure](#act-rule-structure) section. Each ACT Rule also contains a plain language description of the type of content under test, the test to perform, and the expected result. Where the test result affects conformance, the rule documents the particular requirement being tested. The resulting outcomes from the test can be used to help determine conformance or non-conformance to the requirement. Test cases are also written as part of the ACT rule to provide a way to verify that implementations of the rule can successfully determine the expected outcomes. - - -Scope {#scope} -============== - -The ACT Rules Format defined in this specification is designed for 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]], [Scalable Vector Graphics](https://www.w3.org/TR/SVG/) [[SVG2]], [EPUB 3](http://www.idpf.org/epub3/latest/), and more. 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=] defined in the 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} -============================ - -In accessibility, there are often different technical solutions to make the same type of content accessible. For example, there are multiple methods for giving an `img` element in HTML an accessible name. Multiple solutions could be tested in a single rule; however, such a rule tends to be quite complex, making it difficult to understand and maintain. The ACT Rules Format solves this by providing two types of rules: - -- Atomic rules describe how to test a specific type of solution. It contains a precise definition of what elements, nodes or other "parts" of a [=test subject=] are to be tested, and when those test targets are considered to pass or fail the rule. These rules are to be kept small and *atomic*. This means that atomic rules test a single "condition" and do so without using the [=outcomes=] from other rules. - -- Composite rules describe how the [=outcomes=] of multiple [=atomic rules=] can be combined into a single outcome for each [=test target=]. A composite rule can have multiple "conditions", each of these tested in a separate atomic rule. The logic in the composite rule describes how any one of these satisfying conditions, or some combination of them, is used to determine a single outcome. - -Composite rules cannot contain other composite rules. Any time a nested composite rule would be needed, all of the relevant atomic rules can be combined directly into the new composite rule. - - - -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 to determine if a [=test subject=] does not satisfy an [=accessibility requirement=]. - -The separation between atomic rules and composite rules creates a division of responsibilities. Atomic rules test if web content is correctly implemented in a particular solution. Composite rules can test if a combination of [=outcomes=] from other atomic rules satisfy the accessibility requirement, in part or as a whole. - - -ACT Rule Structure {#act-rule-structure} -=============================== - -An ACT Rule must consist of at least the following items: - -* Descriptive Title -* [Rule Identifier](#rule-identifier) -* [Rule Description](#rule-description) -* [Rule Type](#rule-type) -* [Accessibility Requirements Mapping](#accessibility-requirements-mapping) -* [Rule Input](#input), which is one of the following: - * [Input Aspects](#input-aspects) (for atomic rules) OR - * [Input Rules](#input-rules) (for composite rules) -* [Applicability](#applicability) -* [Expectations](#expectations) -* [Assumptions](#assumptions) -* [Accessibility Support](#accessibility-support) -* [Test Cases](#test-cases) -* [Change Log](#change-log) -* [Glossary](#glossary) - -An ACT Rule MAY also contain: - -* [Issues List](#issues-list) (optional) -* [Background](#background) (optional) -* [Acknowledgments](#acknowldgements) (optional) - -The ACT Rules format does not prescribe what format ACT Rules can be written in (e.g. HTML, DOCX, PDF, etc.). However, ACT Rules must be written in a document that conforms to the Web Content Accessibility Guidelines [[WCAG]] or a comparable accessibility standard. This ensures that ACT Rules are accessible to people with disabilities. ACT Rule [test cases](#test-cases) are allowed to contain inaccessible content. If any test case contains accessibility issues listed in [WCAG 2.1 Section 5.2.5 Non-Interference](https://www.w3.org/TR/WCAG21/#cc5), users must be warned of this in advance. In addition to supporting people with disabilities, using an accessible format also makes internationalization of ACT Rules easier. - - -Rule Identifier {#rule-identifier} ----------------------------------- - -An ACT Rule must have an identifier. This identifier must be unique when the rule is part of a ruleset. The identifier can be any text, such as plain text, URL, or a database identifier. - - - -In addition to the identifier, each new release of an ACT Rule must be versioned with either a date or a number. A reference to the previous version of that rule must be available. The identifier must not be changed when the rule is updated. For substantial changes, a new rule should be created with a new identifier, and the old rule should be deprecated. - - - - -Rule Description {#rule-description} ------------------------------------- - -An ACT Rule must have a description that is in plain language which provides a brief explanation of what the rule does. - - - - -Rule Type {#rule-type} ------------------------------------- - -An ACT Rule must have a rule type which is one of the following: -
    -
  • Atomic rule
    • -
  • Composite rule
    • -
- -Refer to the [Rule Type](#rule-types) section for detailed definitions of the rule types. - - -Accessibility Requirements Mapping {#accessibility-requirements-mapping} ------------------------------------------------------------------------- - -When an ACT Rule is designed to test conformance to one or more [=Accessibility requirements documents=], the rule must 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 may list accessibility requirements that could be not satisfied when the rule outcome is failed. There are two types of accessibility requirements: -- [Conformance Requirements](#conformance-requirements) -- [Secondary Requirements](#secondary-requirements) - -Each [=accessibility requirement=] in the mapping must include the following: - -1. either the name, title, identifier or summary of the accessibility requirement, and -2. the name of the [=accessibility requirements document=], and -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, and -5. whether the requirement is a conformance requirement or a secondary requirement. - -### Outcome Mapping ### {#outcome-mapping} -For each conformance requirement in the mapping, an ACT Rule must 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 conditions are true: - -- Failed Outcomes: When one or more of the outcomes for a test subject is `failed`, the accessibility requirement is not satisfied for the test subject, and -- Passed or Inapplicable Outcomes: When all of the outcomes are `passed` or `inapplicable` for a test subject, the accessibility requirement could be satisfied or further testing is needed for the test subject. - -Rules that can be used to determine if an accessibility requirement is *satisfied* are called satisfying tests. - -- Passed: When all of the outcomes are `passed`, the accessibility requirement is satisfied for the test subject. - -
-

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

-
- - - -#### Secondary Requirements #### {#secondary-requirements} - -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 may 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**: the rule is not as strict as a requirement - -A rule was designed to test a minimum accessibility requirement and there exists a stricter requirement. 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 rule's outcomes are passed. The stricter requirement is a Secondary requirement. - - - -**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. - - - -**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. - - - - -**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. - - - - - -### Mapping Outside WCAG ### {#mapping-outside-wcag} - -ACT Rules can be used to test accessibility requirements that are not part of a W3C accessibility standard, such as accessibility requirements in [Hypertext Markup Language](https://www.w3.org/TR/html/) [[HTML]], or tests in a methodology like [RGAA 3 2016](https://disic.github.io/rgaa_referentiel_en/criteria.html). An ACT Rule must indicate 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 that includes both requirements and optional "best practices". The distinction between what is required and what is optional has to be clear. - - - - -### Rules Without Accessibility Requirements ### {#rules-without-accessibility-requirements} - -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. - - - -If the `failed` [=outcome=] cannot be mapped to an [=accessibility requirement=], there must not be an accessibility requirement in the accessibility requirements mapping. The optional [Background section](#background) could be used to list [=accessibility requirements documents=] when they are thematically related, but for which the rule is not a failure test. - - -### External Accessibility Requirements Mapping ### {#external-accessibility-requirements-mapping} - -This section is *non-normative*. - -While rules are often designed for one, or possibly a small collection of [=accessibility requirements documents=], it is likely that other accessibility requirements documents also map to those ACT Rules. For example, rules can be written for the [Web Content Accessibility Guidelines](https://www.w3.org/WAI/standards-guidelines/wcag/) [[WCAG]], but many of those could also 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 amends the accessibility requirements mapping of an ACT 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. - - -Rule Input {#input} -------------------- - -To evaluate content using an ACT Rule, the rule requires some information from the [=test subject=]. This is the input for the rule. What input is required is made explicit, to help testers understand what capabilities are required to use a rule. [=Atomic rules=] and [=composite rules=] have different input. - -- Atomic rules have [Input Aspects](#input-aspects) -- Composite rules have [Input Rules](#input-rules) - - -### Input Aspects (Atomic rules only) ### {#input-aspects} - -An input aspect is a distinct part of the [=test subject=]. Rendering a particular piece of content to an end user commonly involves different technologies, some or all of which are required as input for an [=atomic rule=]. For example, some rules need to operate directly on the [Hypertext Transfer Protocol](https://tools.ietf.org/html/rfc7230) [[http11]] messages exchanged between a server and a client, while others need to operate on the [Document Object Model](https://dom.spec.whatwg.org) [[DOM]] tree exposed by a web browser. - -[=Atomic rules=] must list the aspects used as input for the [applicability](#applicability-atomic) and [expectations](#expectations-atomic) of the atomic rule. Rules can operate on several aspects simultaneously, such as both the HTTP messages and the DOM tree. - -Some input aspects are well defined in a formal specification, such as HTTP messages, the DOM tree, and CSS styling [[css-2018]]. For these, a reference to the corresponding section in the [Common Input Aspects note](https://www.w3.org/TR/act-rules-aspects/) is sufficient as a description of the aspect. For input aspects that are not well defined, an ACT Rule must include either a detailed description of the aspect in question, or a reference to a well defined description. - - - - - - The method through which an input aspect is served is not relevant. For example a DOM tree can be served through HTTP as HTML, it can be bundled as several pages in an [EPUB publication](http://www.idpf.org/epub3/latest/), or it can be inferred from a [JSX source file](https://facebook.github.io/jsx/). All rules that have only DOM tree as an input aspect can be applied to those technologies. - - -### Input Rules (Composite rules only) ### {#input-rules} - -A [=composite rule=] uses [=outcomes=] from [=atomic rules=] and applies logic to them so that a single outcome can be determined for each [=test target=]. The [identifier](#rule-identifier) and [=descriptive title=] of all the atomic rules used in the [expectations](#expectations-composite) must be listed in the composite rule. The input rules describe the input for composite rules, similar to how [input aspects](#input-aspects) describe the input for atomic rules. - - -Applicability {#applicability} ------------------------------- - -The applicability describes what parts of the [=test subject=] are tested. - - -### Applicability for Atomic Rules ### {#applicability-atomic} - -The applicability section is a required part of an [=atomic rule=]. It must contain a precise description of the parts of the [=test subject=] to which the rule applies. For example, specific nodes in the DOM [[DOM]] tree, or tags that are incorrectly closed in an HTML [[HTML]] document. These are known as the [=test targets=]. The applicability must only use information made available through the listed [input aspects](#input-aspects) in the rule. No other information can be used in the applicability. Applicability must be described objectively, unambiguously and in plain language. - -An objective description is one that can be resolved without uncertainty, in a given technology. Examples of objective properties in HTML are tag names, their computed role, the distance between two elements, etc. Subjective properties on the other hand, are concepts like decorative, navigation mechanism and pre-recorded. - -Even concepts like headings and images can be misunderstood. These terms could refer to the tag name, the semantic role, or the element's purpose on the web page because they are ambiguous. The latter of which is almost impossible to define objectively. When used in applicability, potentially ambiguous concepts must be defined objectively. Definitions can be put in the rule [glossary](#glossary), or they can be defined in the section where they are used. - - - - - - - -### Applicability for Composite Rules ### {#applicability-composite} - -The applicability of a composite rule is defined as the union of all applicability definitions from the rules listed in the [input rules](#input-rules). Rule authors may omit a description of the applicability for composite rules. This can be useful if it is difficult to express the combined applicability in plain language. If the composite rule includes applicability, it must be the union of all the applicability in the [input rules](#input-rules). - -Note that input rules in a composite rule may have different applicability. Because of this, not every test target applicable within the composite rule is tested by every input rule. - - - - -Expectations {#expectations} ----------------------------- - -An ACT Rule must contain one or more expectations. The expectations describe what the requirements are for the [=test targets=] derived from the [applicability](#applicability). An expectation is an assertion about a [=test target=]. When a test target meets all expectations, the test target `passed` the rule. If the test target does not meet all expectations, the test target `failed` the rule. If there are no test targets, the [=outcome=] for the rule is `inapplicable`. - -Each expectation must be distinct, unambiguous, and be written in plain language. - - -### Expectations for Atomic Rules ### {#expectations-atomic} - -All expectations of an [=atomic rule=] must describe the logic that is used to determine a single `passed` or `failed` [=outcome=] for a [=test target=]. The expectation must only use information available in the [input aspects](#input-aspects), from the applicability, and other expectations of the same rule. No other information can be used in the expectation. So for instance, an expectation could be "Expectation 1 is true and ...", but it can't be "Rule XYZ passed and ...". This ensures that atomic rules are encapsulated. - - - - - -
-

**Note:** Sometimes there is the need for rules with more complex aggregation, for example that X% of all images on a web page are expected to have text alternatives. In this case, the page itself needs to become the test target. The expectation would then be "The test target (the page) has a text alternative for X% of all img elements". The logic for calculating the expectations in such rules is left to the implementations, to avoid over-complexity of this rules format.

-
- -### Expectations for Composite Rules ### {#expectations-composite} - -All expectations of a [=composite rule=] must describe the logic that is used to determine a single `passed` or `failed` [=outcome=] for a [=test target=], based on the outcomes of rules in its [input rules](#input-rules). A composite rule expectation must not use information from [input aspects](#input-aspects). The outcome for a composite rule is `inapplicable` when all input rules are inapplicable. - - - - - - -Assumptions {#assumptions} --------------------------- - -An ACT Rule must list any known assumptions, limitations or any exceptions for the evaluation, the test environment, technologies being used or the subject being tested. For example, a rule that would partially test [WCAG 2.1 success criterion 1.4.3 Contrast (Minimum)](https://www.w3.org/WAI/WCAG21/quickref/#contrast-minimum) based on the inspection of CSS properties could state that it is only applicable to HTML text content styleable with CSS, and that the rule does not support images of text. - -Sometimes there are multiple plausible ways that an accessibility requirement can be interpreted. For instance, it is not immediately obvious if emoji characters are "text" or "non-text content" in the [Web Content Accessibility Guidelines](https://www.w3.org/WAI/standards-guidelines/wcag/) [[WCAG]]. Whatever the interpretation is, this must be documented in the rule. - -While the assumptions must be included in the ACT Rule, it may be empty when there are no known assumptions, limitations or exceptions. - - -Accessibility Support {#accessibility-support} ----------------------------------------------- - -Content can be designed to rely on the support for particular accessibility features by different assistive technologies and user agents. For example, content using a particular [WAI-ARIA 1.1](https://www.w3.org/TR/wai-aria/) feature relies on that feature to be supported by assistive technologies and user agents. This content would not work for assistive technologies and user agents that do not support WAI-ARIA. See the WCAG definition for [accessibility supported](https://www.w3.org/TR/WCAG21/#dfn-accessibility-supported) use of a web technology. - -An ACT Rule must include known limitations on accessibility support. - - - -While an accessibility support section must be included in the ACT Rule, it may be empty when there are no known accessibility support issues. - -
-

**Note:** The Website Accessibility Conformance Evaluation Methodology (WCAG-EM) provides guidance on defining an [accessibility support baseline](https://www.w3.org/TR/WCAG-EM/#step1c) for test scenarios, which can help users of ACT Rules to select the appropriate rules for their own circumstance.

-
- - -Test Cases {#test-cases} ------------------------- - -Test cases are (snippets of) content that can be used to validate the implementation of ACT Rules. Each rule must have one or more test cases for `passed`, `failed`, and `inapplicable` [=outcomes=]. A test case consists of two pieces of data, a snippet of each [input aspect](#input-aspects) for a rule, and the expected outcome for that rule. Test cases serve two functions, firstly as example scenarios for readers to understand when the outcome of a rule is `passed`, `failed`, or `inapplicable`. It also serves developers and users of accessibility testing tools and methodologies to validate that a rule is correctly implemented. - - - - -Change Log {#change-log} ------------------------- - -It is important to keep track of changes to the ACT Rules so that users of the rules can understand if changes in test results are due to changes in the rules used when performing the tests, or from changes in the content itself. All changes to an ACT Rule that can change the [=outcomes=] of an evaluation must be recorded in a change log. The change log can either be part of the rule document itself or be referenced from it. - - -Glossary {#glossary} --------------------- - -ACT Rules must have a glossary section. The glossary must contain the [=outcome=] definition, as well as any definitions used in [applicability](#applicability) and [expectations](#expectations) sections in the rule. Since changes to the definition change the rule, those definitions cannot be maintained independently of the rule. If a shared glossary is used for rules, any definition changes must be included in the [change log](#change-log) of all rules that use that definition. - - -Issues List (optional) {#issues-list} -------------------------------------- - -An ACT Rule may include a list or a reference to a list of any known issues. The issues list would be used to record cases where an [=outcome=] of an ACT Rule was `failed` where it ought to have been `passed` or `inapplicable`, or vice versa. There are several reasons why this might occur. See [rule accuracy](#rule-accuracy) for more information. - -The issues list serves two purposes. For users of ACT Rules, the issues list gives insight into why an inaccurate result occurred, as well as provide confidence in the result of that rule. For the designer of the rule, the issues list is also useful to plan future updates to the rule. In a new version of the rule, resolved issues would be moved to the change log. - - -Background (optional) {#background} ------------------------------------ - -An ACT Rule may contain information about the background for the development of the rule, or references to relevant reading. The background information is optional, but whenever it is included in the rule, the relationship to the relevant reading can be specified. Examples of relevant background references for a rule for a [Web Content Accessibility Guidelines](https://www.w3.org/WAI/standards-guidelines/wcag/) [[WCAG]] success criterion could be [WCAG 2.1 Understanding documents](https://www.w3.org/WAI/WCAG21/Understanding/), [WCAG 2.1 Techniques](https://www.w3.org/WAI/WCAG21/Techniques/), or [WAI-ARIA 1.1](https://www.w3.org/TR/wai-aria/), CSS [[css-2018]], or HTML [[HTML]] specifications. - - -Acknowledgments (optional) {#acknowledgments} ------------------------------------------------ - -An ACT Rule may contain acknowledgments. This can include, but is not limited to: -* List of rule authors -* List of rule reviewers/contributors -* Funding or other support - - -Rule Accuracy {#rule-accuracy} -========================= - -This section is *non-normative*. - -While [test cases](#test-cases) can be used to determine if an ACT Rule was correctly implemented, they do not guarantee that implementations will never produce incorrect results. When writing ACT Rules, it is almost inevitable that edge cases will be overlooked. Technologies are always evolving, and content authors are constantly coming up with new and unexpected ways to use them. Some examples of causes for inaccuracy are: - -- [Assumptions](#assumptions) were made about the test subject that turned out to be untrue -- Technologies were used in an unusual and difficult to predict manner -- Technologies have changes, or aspects of the technologies were overlooked -- The accessibility requirement was not correctly interpreted - -There are two types of inaccuracies that can produce incorrect results. Inaccuracies in the **implementation** can be addressed with test cases, but inaccuracies in the **ACT Rule itself** cannot. After all, rule inaccuracies come from the rule author being unaware of a particular edge case. - -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 targets=], that were `failed` by the rule, but satisfy the [=accessibility requirements=]. - -- **False negatives:** This is the percentage of [=test targets=], that were `passed` by the rule, but do not satisfy the [=accessibility requirements=]. - -The ever present possibility of false positives and false negatives with ACT Rules means they will likely require ongoing maintenance. Designing a process for maintaining ACT Rules is outside the scope of the ACT Rules Format, which is limited to the rules themselves. Nevertheless, it is suggested that rule authors work out a process for maintaining their rules. - - -Harmonization {#harmonization} -============================== - -This section is *non-normative*. - -While the ACT Rules Format is designed to stimulate harmonization, there are no direct requirement in the ACT Rules Format that prevent a rule author from writing rules inconsistent with already established ACT Rules. Neither are there requirements for ACT Rules to have a certain number of implementations, or to have a certain level of accuracy. This allows quality requirements to be different for different rulesets, and allows them to develop over time. - -Harmonization occurs when a group of rule implementors collectively accept the validity of an ACT Rule. For example, a community group of accessibility testing tool vendors could declare they have harmonized on a particular set of ACT Rules. Such a group can set acceptance criteria for rules, and have quality requirements that go beyond the ACT Rules Format. - - - -An example of such a process is the [WCAG ACT Review Process](https://w3c.github.io/wcag-act-rules/review-process.html). - - -Definitions {#definitions} -========================== - -
-
Accessibility requirement
-
-

An accessibility requirement is a requirement aimed at improving access for people with disabilities to an ICT product. In the context of ACT rules mapping, a requirement can be compulsory or advisory. When compulsory, it has to be satisfied in order to conform to a standard, or to comply with a contract, policy or regulation. When advisory, it is recommended, but not satisfying it does not lead to non-conformance or non-compliance.

-

A common example of accessibility requirements are the WCAG success criteria. There are other standards, including W3C standards, that have recommendations for accessibility, such as WAI-ARIA and HTML. Accessibility requirements are also often found in company policies, regional standards or in legislation.

-
- -
Accessibility requirements document
-
-

A document, such as a standard, contract, policy or regulation, that includes [=accessibility requirements=]. For example, WCAG 2.1, WAI-ARIA 1.1, HTML 5.2, EPUB Accessibility 1.0, BBC HTML Accessibility Standards v2.0

-
- -
Outcome
-
-

A conclusion that comes from evaluating an ACT Rule on a [=test subject=] or one of its constituent [=test target=]. An outcome can be one of the three following types:

-
    -
  • **Inapplicable:** No part of the test subject matches the applicability
    • -
  • **Passed:** A [=test target=] meets all expectations
    • -
  • **Failed:** A [=test target=] does not meet all expectations
    • -
-
-

**Note:** A rule has one `passed` or `failed` outcome for every [=test target=]. When there are no test targets the rule has one `inapplicable` outcome. This means that each [=test subject=] will have one or more outcomes.

-
-
-

**Note:** 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 cannot 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. -

-
- -
Test Subject
-
-

A resource or collection of resources that can be evaluated by an ACT Rule.

- -
-

**Note:** Implementers using the [[EARL10-Schema]] can express the test subject with the [subject property](https://www.w3.org/TR/EARL10-Schema/#subject)

-
-
- -
Test Target
-
-

A distinct part of the [=test subject=], as defined by the [applicability](#applicability).

- -
-

**Note:** Implementers using the [[EARL10-Schema]] can express the test target with the [pointer property](https://www.w3.org/TR/EARL10-Schema/#pointer)

-
-
-
- - -Appendix 1: Expressing ACT Rule results with JSON-LD and EARL {#appendix-data-example} -================================================================================= - -This section is *non-normative*. - -This section provides examples of expressing results from carrying out ACT Rules using EARL and JSON-LD (See [Evaluation and Report Language](https://www.w3.org/WAI/standards-guidelines/earl/) and [A JSON-based Serialization for Linked Data (JSON-LD)](https://www.w3.org/TR/json-ld/)). More examples and background is proivided on the [JSON-LD serialization of EARL](https://github.com/w3c/earl) GitHub repository. - -Examples in this section include: - -- Example 1: Minimal outcome from one 'Assertion' -- Example 2: Results from more than one 'Assertion' -- Example 3: Aggregating based on 'Requirement' -- Example 4: Aggregating based on 'Test Subject' -- Example 5: Assumed 'Context' for this section - -**Example 1:** Minimal outcome for one 'Assertion' - -```javascript -{ - "@context": "context.json", - "@type": "Assertion", - "assertedBy": "https://example.org/MyTool", - "subject": "https://example.org/page1.html", - "test": "ACT-CG:rules/23a2a8", - "result": { - "outcome": "earl:failed", - "pointer": "html > body > h1:first-child" - } -} -``` - -**Example 2:** Results for more than one 'Assertion' - -```javascript -{ - "@context": "context.json", - "@graph": [{ - "@type": "Assertion", - "assertedBy": "https://example.org/MyTool", - "subject": "https://example.org/page1.html", - "test": "ACT-CG:rules/23a2a8", - "result": { - "outcome": "earl:failed", - "pointer": "html > body > h1:first-child" - } - }, { - "@type": "Assertion", - "assertedBy": "https://example.org/AnotherTool", - "subject": "https://example.org/page1.html", - "test": "ACT-CG:rules/23a2a8", - "result": { - "outcome": "earl:passed", - "pointer": "html > body > h1:nth-child(2)" - } - }] -} -``` - -**Example 3:** Aggregating based on 'Requirement' (eg. WCAG Success Criteria) - -```javascript -{ - "@context": "context.json", - "@type": "Assertion", - "assertedBy": "https://example.org/MyTool", - "subject": "https://example.org/page1.html", - "test": { - "@type": "earl:TestRequirement", - "@id": "WCAG21:non-text-content" - }, - "result": { - "outcome": "earl:failed", - "source": [{ - "test": "ACT-CG:rules/23a2a8", - "result": { - "outcome": "earl:failed", - "pointer": "html > body > h1:first-child" - } - }, { - "test": "ACT-RULES-CG:rules/23a2a8", - "result" : { - "outcome": "earl:passed", - "pointer": "html > body > h1:nth-child(2)" - } - }] - } -} -``` - -**Example 4:** Aggregating based on 'Test Subject' (eg. for a website) - -```javascript -{ - "@context": "context.json", - "@type": "Assertion", - "assertedBy": { - "@type": "Organization", - "@id": "_:myOrg", - "title": "My Organization", - "description" : "Accessibility testing service", - "homepage" : "http://example.org/myOrg/" - }, - "subject": { - "@type": ["WebSite", "TestSubject"], - "@id": "https://example.org/" - }, - "test": { - "@type": "earl:TestRequirement", - "@id": "http://www.w3.org/WAI/WCAG2A-Conformance" - }, - "result": { - "outcome": "earl:failed", - "source": [{ - "test": { - "@type": "earl:TestRequirement", - "@id": "WCAG21:non-text-content" - }, - "result": { - "outcome": "earl:failed", - "source": [ … ] - } - }, { - "test": { - "@type": "earl:TestRequirement", - "@id": "WCAG21:audio-only-and-video-only-prerecorded" - }, - "result": { - "outcome": "earl:passed", - "source": [ … ] - } - }, { - "test": { - "@type": "earl:TestRequirement", - "@id": "WCAG21:captions-prerecorded" - }, - "result" : { - "outcome": "earl:passed", - "source": [ … ] - } - }, … ] - } -} -``` - -**Example 5:** Assumed 'Context' for this section - -```javascript -{ - "@vocab": "http://www.w3.org/ns/earl#", - - "cnt": "http://www.w3.org/2011/content#", - "dct": "http://purl.org/dc/terms/", - "earl": "http://www.w3.org/ns/earl#", - "foaf": "http://xmlns.com/foaf/0.1/", - "htp": "http://www.w3.org/2011/http#", - "ptr": "https://www.w3.org/2009/pointers#", - "schema": "http://schema.org/", - "xsd": "https://www.w3.org/2001/XMLSchema#", - - "WCAG20": "https://www.w3.org/TR/WCAG20#", - "WCAG21": "https://www.w3.org/TR/WCAG21#", - "ACT-RULES-CG": "https://act-rules.github.io/", - - "WebSite": "schema:WebSite", - "WebPage": "schema:WebPage", - - "title": "dct:title", - "description": "dct:description", - "date": "dct:date", - "hasVersion": "dct:hasVesion", - "isPartOf": "dct:isPartOf", - "hasPart": "dct:hasPart", - "source": "dct:source", - - "Agent": "foaf:Agent", - "Person": "foaf:Person", - "Organization": "foaf:Organization", - "Group": "foaf:Group", - "Document": "foaf:Document", - "name": "foaf:name", - "firstName": "foaf:firstName", - "surname": "foaf:surname", - "mbox": "foaf:mbox", - "mbox_sha1sum": "foaf:mbox_sha1sum", - "member": "foaf:member", - "homepage": "foaf:homepage", - - "assertedBy": { "@type": "@id" }, - "subject": { "@type": "@id" }, - "test": { "@type": "@id" }, - "mode": { "@type": "@id" }, - "outcome": { "@type": "@id" }, - "pointer": { - "@id": "earl:pointer", - "@type": "ptr:CSSSelectorPointer" - } -} -``` - -Appendix 2: Acknowledgments {#Acknowledgments} -=========================== - -This section is *non-normative*. - - -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} ----------------- - -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. - - -Appendix 3: Change History {#Change_History} -========================== - -This section is *non-normative*. - -No substantial changes have been made since the previous [Candidate Recommendation draft of 16 April 2019](https://www.w3.org/TR/2019/CR-act-rules-format-1.0-20190416/). The following editorial changes have been made since the previous draft: - -
    -
  • 1. Introduction: Added relationship of ACT Rules to WCAG 2 Techniques
    • -
  • 1. Introduction: Removed unintended word "must" (was never a requirement)
    • -
  • 4. Rule Structure: Clarified that optional parts are a MAY requirement
    • -
  • 4.1. Rule Identifier: Moved requirements on versioning here from 4.11. Changelog
    • -
  • 4.1. Rule Identifier: Clarified scope of uniqueness of an identifier
    • -
  • 4.5.1. Input Aspects: Moved description of serving methods further down
    • -
  • 4.7.1. Expectations for Atomic Rules: Expanded note on complex aggregation
    • -
  • 4.14. Background: Removed unintended word "should" (was never a requirement)
    • -
  • Appendix 1. Expressing ACT Results: Major revision (non-normative examples)
    • -
  • Overall: Edits to align and clarify examples throughout the document
    • -
  • Overall: Fixing typographical, grammatical, and spelling mistakes throughout
    • -
  • Overall: Changed coding of RFC 2119 terms to improve accessibility/semantic
    • -
- -All changes from the previous published version can be viewed using the [April 2019 to July 2019 diff link](https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FTR%2F2019%2FCR-act-rules-format-1.0-20190416%2F&doc2=https%3A%2F%2Fw3c.github.io%2Fwcag-act%2Fact-rules-format.html) From 6fb98a996543407b2da8fd67ea04802f59c35806 Mon Sep 17 00:00:00 2001 From: Daniel Date: Tue, 20 Jun 2023 12:36:46 +0200 Subject: [PATCH 52/54] Creates subdirectory --- act-rules-format/act-rules-format.bs | 948 +++++++++++++++++++++++++++ 1 file changed, 948 insertions(+) create mode 100644 act-rules-format/act-rules-format.bs diff --git a/act-rules-format/act-rules-format.bs b/act-rules-format/act-rules-format.bs new file mode 100644 index 00000000..c5807ce6 --- /dev/null +++ b/act-rules-format/act-rules-format.bs @@ -0,0 +1,948 @@ +
+Title: Accessibility Conformance Testing (ACT) Rules Format 1.1
+Shortname: ACT-Rules-Format
+URL: https://w3c.github.io/wcag-act/act-rules-format.html
+Previous Version: https://w3c.github.io/wcag-act/archive_act-format/2019-07-22.html
+Level: 1.1
+Status: w3c/ED
+Group: act-rules-format
+Editor: Wilco Fiers, Deque Systems
+Editor: Katherine Eng, US Access Board
+Editor: Trevor Bostic, MITRE Corp.
+Former Editor: Maureen Kraft, IBM Corp.
+Former Editor: Mary Jo Mueller, IBM Corp.
+Former Editor: Shadi Abou-Zahra, W3C
+Abstract: The Accessibility Conformance Testing (ACT) Rules Format 1.1 defines a format for writing accessibility test rules. These test rules can be used for developing automated testing tools and manual testing methodologies. It provides a common format that allows any party involved in accessibility testing to document and share their testing procedures in a robust and understandable manner. This enables transparency and harmonization of testing methods, including methods implemented by accessibility test tools.
+Markup Shorthands: markdown yes
+
+ + +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](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 conformance to WCAG and other [=accessibility requirements documents=] and promote consistent results in accessibility testing. The rules format is designed to describe both manual accessibility tests, as well as automated tests as performed by accessibility testing tools. + +Documenting how to test [=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). + +An ACT Rule is a plain language description of how to test a specific type of content for a specific aspect of an accessibility requirement. An ACT Rule describes what kind of content it applies to and which conditions are true about the applicable elements for them to meet all expectations of the rule. In the context of WCAG, ACT Rules test for failures in satisfying Success Criteria. Such failures are often described in [common failures](https://www.w3.org/TR/WCAG21/#wcag-2-layers-of-guidance) documented for WCAG. ACT Rules are written for the testing process and are usually more specific than common failures. + +The ACT Rules Format defines the requirements and rule structure for the types of information each rule needs to include to be called an ACT Rule. The structure of the ACT rule is defined in the [ACT Rule Structure](#act-rule-structure) section. Each ACT Rule also contains a plain language description of the type of content under test, the test to perform, and the expected result. Where the test result affects conformance, the rule documents the particular requirement being tested. The resulting outcomes from the test can be used to help determine conformance or non-conformance to the requirement. Test cases are also written as part of the ACT rule to provide a way to verify that implementations of the rule can successfully determine the expected outcomes. + + +Scope {#scope} +============== + +The ACT Rules Format defined in this specification is designed for 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]], [Scalable Vector Graphics](https://www.w3.org/TR/SVG/) [[SVG2]], [EPUB 3](http://www.idpf.org/epub3/latest/), and more. 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=] defined in the 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} +============================ + +In accessibility, there are often different technical solutions to make the same type of content accessible. For example, there are multiple methods for giving an `img` element in HTML an accessible name. Multiple solutions could be tested in a single rule; however, such a rule tends to be quite complex, making it difficult to understand and maintain. The ACT Rules Format solves this by providing two types of rules: + +- Atomic rules describe how to test a specific type of solution. It contains a precise definition of what elements, nodes or other "parts" of a [=test subject=] are to be tested, and when those test targets are considered to pass or fail the rule. These rules are to be kept small and *atomic*. This means that atomic rules test a single "condition" and do so without using the [=outcomes=] from other rules. + +- Composite rules describe how the [=outcomes=] of multiple [=atomic rules=] can be combined into a single outcome for each [=test target=]. A composite rule can have multiple "conditions", each of these tested in a separate atomic rule. The logic in the composite rule describes how any one of these satisfying conditions, or some combination of them, is used to determine a single outcome. + +Composite rules cannot contain other composite rules. Any time a nested composite rule would be needed, all of the relevant atomic rules can be combined directly into the new composite rule. + + + +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 to determine if a [=test subject=] does not satisfy an [=accessibility requirement=]. + +The separation between atomic rules and composite rules creates a division of responsibilities. Atomic rules test if web content is correctly implemented in a particular solution. Composite rules can test if a combination of [=outcomes=] from other atomic rules satisfy the accessibility requirement, in part or as a whole. + + +ACT Rule Structure {#act-rule-structure} +=============================== + +An ACT Rule must consist of at least the following items: + +* Descriptive Title +* [Rule Identifier](#rule-identifier) +* [Rule Description](#rule-description) +* [Rule Type](#rule-type) +* [Accessibility Requirements Mapping](#accessibility-requirements-mapping) +* [Rule Input](#input), which is one of the following: + * [Input Aspects](#input-aspects) (for atomic rules) OR + * [Input Rules](#input-rules) (for composite rules) +* [Applicability](#applicability) +* [Expectations](#expectations) +* [Assumptions](#assumptions) +* [Accessibility Support](#accessibility-support) +* [Test Cases](#test-cases) +* [Change Log](#change-log) +* [Glossary](#glossary) + +An ACT Rule MAY also contain: + +* [Issues List](#issues-list) (optional) +* [Background](#background) (optional) +* [Acknowledgments](#acknowldgements) (optional) + +The ACT Rules format does not prescribe what format ACT Rules can be written in (e.g. HTML, DOCX, PDF, etc.). However, ACT Rules must be written in a document that conforms to the Web Content Accessibility Guidelines [[WCAG]] or a comparable accessibility standard. This ensures that ACT Rules are accessible to people with disabilities. ACT Rule [test cases](#test-cases) are allowed to contain inaccessible content. If any test case contains accessibility issues listed in [WCAG 2.1 Section 5.2.5 Non-Interference](https://www.w3.org/TR/WCAG21/#cc5), users must be warned of this in advance. In addition to supporting people with disabilities, using an accessible format also makes internationalization of ACT Rules easier. + + +Rule Identifier {#rule-identifier} +---------------------------------- + +An ACT Rule must have an identifier. This identifier must be unique when the rule is part of a ruleset. The identifier can be any text, such as plain text, URL, or a database identifier. + + + +In addition to the identifier, each new release of an ACT Rule must be versioned with either a date or a number. A reference to the previous version of that rule must be available. The identifier must not be changed when the rule is updated. For substantial changes, a new rule should be created with a new identifier, and the old rule should be deprecated. + + + + +Rule Description {#rule-description} +------------------------------------ + +An ACT Rule must have a description that is in plain language which provides a brief explanation of what the rule does. + + + + +Rule Type {#rule-type} +------------------------------------ + +An ACT Rule must have a rule type which is one of the following: +
    +
  • Atomic rule
    • +
  • Composite rule
    • +
+ +Refer to the [Rule Type](#rule-types) section for detailed definitions of the rule types. + + +Accessibility Requirements Mapping {#accessibility-requirements-mapping} +------------------------------------------------------------------------ + +When an ACT Rule is designed to test conformance to one or more [=Accessibility requirements documents=], the rule must 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 may list accessibility requirements that could be not satisfied when the rule outcome is failed. There are two types of accessibility requirements: +- [Conformance Requirements](#conformance-requirements) +- [Secondary Requirements](#secondary-requirements) + +Each [=accessibility requirement=] in the mapping must include the following: + +1. either the name, title, identifier or summary of the accessibility requirement, and +2. the name of the [=accessibility requirements document=], and +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, and +5. whether the requirement is a conformance requirement or a secondary requirement. + +### Outcome Mapping ### {#outcome-mapping} +For each conformance requirement in the mapping, an ACT Rule must 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 conditions are true: + +- Failed Outcomes: When one or more of the outcomes for a test subject is `failed`, the accessibility requirement is not satisfied for the test subject, and +- Passed or Inapplicable Outcomes: When all of the outcomes are `passed` or `inapplicable` for a test subject, the accessibility requirement could be satisfied or further testing is needed for the test subject. + +Rules that can be used to determine if an accessibility requirement is *satisfied* are called satisfying tests. + +- Passed: When all of the outcomes are `passed`, the accessibility requirement is satisfied for the test subject. + +
+

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

+
+ + + +#### Secondary Requirements #### {#secondary-requirements} + +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 may 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**: the rule is not as strict as a requirement + +A rule was designed to test a minimum accessibility requirement and there exists a stricter requirement. 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 rule's outcomes are passed. The stricter requirement is a Secondary requirement. + + + +**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. + + + +**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. + + + + +**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. + + + + + +### Mapping Outside WCAG ### {#mapping-outside-wcag} + +ACT Rules can be used to test accessibility requirements that are not part of a W3C accessibility standard, such as accessibility requirements in [Hypertext Markup Language](https://www.w3.org/TR/html/) [[HTML]], or tests in a methodology like [RGAA 3 2016](https://disic.github.io/rgaa_referentiel_en/criteria.html). An ACT Rule must indicate 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 that includes both requirements and optional "best practices". The distinction between what is required and what is optional has to be clear. + + + + +### Rules Without Accessibility Requirements ### {#rules-without-accessibility-requirements} + +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. + + + +If the `failed` [=outcome=] cannot be mapped to an [=accessibility requirement=], there must not be an accessibility requirement in the accessibility requirements mapping. The optional [Background section](#background) could be used to list [=accessibility requirements documents=] when they are thematically related, but for which the rule is not a failure test. + + +### External Accessibility Requirements Mapping ### {#external-accessibility-requirements-mapping} + +This section is *non-normative*. + +While rules are often designed for one, or possibly a small collection of [=accessibility requirements documents=], it is likely that other accessibility requirements documents also map to those ACT Rules. For example, rules can be written for the [Web Content Accessibility Guidelines](https://www.w3.org/WAI/standards-guidelines/wcag/) [[WCAG]], but many of those could also 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 amends the accessibility requirements mapping of an ACT 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. + + +Rule Input {#input} +------------------- + +To evaluate content using an ACT Rule, the rule requires some information from the [=test subject=]. This is the input for the rule. What input is required is made explicit, to help testers understand what capabilities are required to use a rule. [=Atomic rules=] and [=composite rules=] have different input. + +- Atomic rules have [Input Aspects](#input-aspects) +- Composite rules have [Input Rules](#input-rules) + + +### Input Aspects (Atomic rules only) ### {#input-aspects} + +An input aspect is a distinct part of the [=test subject=]. Rendering a particular piece of content to an end user commonly involves different technologies, some or all of which are required as input for an [=atomic rule=]. For example, some rules need to operate directly on the [Hypertext Transfer Protocol](https://tools.ietf.org/html/rfc7230) [[http11]] messages exchanged between a server and a client, while others need to operate on the [Document Object Model](https://dom.spec.whatwg.org) [[DOM]] tree exposed by a web browser. + +[=Atomic rules=] must list the aspects used as input for the [applicability](#applicability-atomic) and [expectations](#expectations-atomic) of the atomic rule. Rules can operate on several aspects simultaneously, such as both the HTTP messages and the DOM tree. + +Some input aspects are well defined in a formal specification, such as HTTP messages, the DOM tree, and CSS styling [[css-2018]]. For these, a reference to the corresponding section in the [Common Input Aspects note](https://www.w3.org/TR/act-rules-aspects/) is sufficient as a description of the aspect. For input aspects that are not well defined, an ACT Rule must include either a detailed description of the aspect in question, or a reference to a well defined description. + + + + + + The method through which an input aspect is served is not relevant. For example a DOM tree can be served through HTTP as HTML, it can be bundled as several pages in an [EPUB publication](http://www.idpf.org/epub3/latest/), or it can be inferred from a [JSX source file](https://facebook.github.io/jsx/). All rules that have only DOM tree as an input aspect can be applied to those technologies. + + +### Input Rules (Composite rules only) ### {#input-rules} + +A [=composite rule=] uses [=outcomes=] from [=atomic rules=] and applies logic to them so that a single outcome can be determined for each [=test target=]. The [identifier](#rule-identifier) and [=descriptive title=] of all the atomic rules used in the [expectations](#expectations-composite) must be listed in the composite rule. The input rules describe the input for composite rules, similar to how [input aspects](#input-aspects) describe the input for atomic rules. + + +Applicability {#applicability} +------------------------------ + +The applicability describes what parts of the [=test subject=] are tested. + + +### Applicability for Atomic Rules ### {#applicability-atomic} + +The applicability section is a required part of an [=atomic rule=]. It must contain a precise description of the parts of the [=test subject=] to which the rule applies. For example, specific nodes in the DOM [[DOM]] tree, or tags that are incorrectly closed in an HTML [[HTML]] document. These are known as the [=test targets=]. The applicability must only use information made available through the listed [input aspects](#input-aspects) in the rule. No other information can be used in the applicability. Applicability must be described objectively, unambiguously and in plain language. + +An objective description is one that can be resolved without uncertainty, in a given technology. Examples of objective properties in HTML are tag names, their computed role, the distance between two elements, etc. Subjective properties on the other hand, are concepts like decorative, navigation mechanism and pre-recorded. + +Even concepts like headings and images can be misunderstood. These terms could refer to the tag name, the semantic role, or the element's purpose on the web page because they are ambiguous. The latter of which is almost impossible to define objectively. When used in applicability, potentially ambiguous concepts must be defined objectively. Definitions can be put in the rule [glossary](#glossary), or they can be defined in the section where they are used. + + + + + + + +### Applicability for Composite Rules ### {#applicability-composite} + +The applicability of a composite rule is defined as the union of all applicability definitions from the rules listed in the [input rules](#input-rules). Rule authors may omit a description of the applicability for composite rules. This can be useful if it is difficult to express the combined applicability in plain language. If the composite rule includes applicability, it must be the union of all the applicability in the [input rules](#input-rules). + +Note that input rules in a composite rule may have different applicability. Because of this, not every test target applicable within the composite rule is tested by every input rule. + + + + +Expectations {#expectations} +---------------------------- + +An ACT Rule must contain one or more expectations. The expectations describe what the requirements are for the [=test targets=] derived from the [applicability](#applicability). An expectation is an assertion about a [=test target=]. When a test target meets all expectations, the test target `passed` the rule. If the test target does not meet all expectations, the test target `failed` the rule. If there are no test targets, the [=outcome=] for the rule is `inapplicable`. + +Each expectation must be distinct, unambiguous, and be written in plain language. + + +### Expectations for Atomic Rules ### {#expectations-atomic} + +All expectations of an [=atomic rule=] must describe the logic that is used to determine a single `passed` or `failed` [=outcome=] for a [=test target=]. The expectation must only use information available in the [input aspects](#input-aspects), from the applicability, and other expectations of the same rule. No other information can be used in the expectation. So for instance, an expectation could be "Expectation 1 is true and ...", but it can't be "Rule XYZ passed and ...". This ensures that atomic rules are encapsulated. + + + + + +
+

**Note:** Sometimes there is the need for rules with more complex aggregation, for example that X% of all images on a web page are expected to have text alternatives. In this case, the page itself needs to become the test target. The expectation would then be "The test target (the page) has a text alternative for X% of all img elements". The logic for calculating the expectations in such rules is left to the implementations, to avoid over-complexity of this rules format.

+
+ +### Expectations for Composite Rules ### {#expectations-composite} + +All expectations of a [=composite rule=] must describe the logic that is used to determine a single `passed` or `failed` [=outcome=] for a [=test target=], based on the outcomes of rules in its [input rules](#input-rules). A composite rule expectation must not use information from [input aspects](#input-aspects). The outcome for a composite rule is `inapplicable` when all input rules are inapplicable. + + + + + + +Assumptions {#assumptions} +-------------------------- + +An ACT Rule must list any known assumptions, limitations or any exceptions for the evaluation, the test environment, technologies being used or the subject being tested. For example, a rule that would partially test [WCAG 2.1 success criterion 1.4.3 Contrast (Minimum)](https://www.w3.org/WAI/WCAG21/quickref/#contrast-minimum) based on the inspection of CSS properties could state that it is only applicable to HTML text content styleable with CSS, and that the rule does not support images of text. + +Sometimes there are multiple plausible ways that an accessibility requirement can be interpreted. For instance, it is not immediately obvious if emoji characters are "text" or "non-text content" in the [Web Content Accessibility Guidelines](https://www.w3.org/WAI/standards-guidelines/wcag/) [[WCAG]]. Whatever the interpretation is, this must be documented in the rule. + +While the assumptions must be included in the ACT Rule, it may be empty when there are no known assumptions, limitations or exceptions. + + +Accessibility Support {#accessibility-support} +---------------------------------------------- + +Content can be designed to rely on the support for particular accessibility features by different assistive technologies and user agents. For example, content using a particular [WAI-ARIA 1.1](https://www.w3.org/TR/wai-aria/) feature relies on that feature to be supported by assistive technologies and user agents. This content would not work for assistive technologies and user agents that do not support WAI-ARIA. See the WCAG definition for [accessibility supported](https://www.w3.org/TR/WCAG21/#dfn-accessibility-supported) use of a web technology. + +An ACT Rule must include known limitations on accessibility support. + + + +While an accessibility support section must be included in the ACT Rule, it may be empty when there are no known accessibility support issues. + +
+

**Note:** The Website Accessibility Conformance Evaluation Methodology (WCAG-EM) provides guidance on defining an [accessibility support baseline](https://www.w3.org/TR/WCAG-EM/#step1c) for test scenarios, which can help users of ACT Rules to select the appropriate rules for their own circumstance.

+
+ + +Test Cases {#test-cases} +------------------------ + +Test cases are (snippets of) content that can be used to validate the implementation of ACT Rules. Each rule must have one or more test cases for `passed`, `failed`, and `inapplicable` [=outcomes=]. A test case consists of two pieces of data, a snippet of each [input aspect](#input-aspects) for a rule, and the expected outcome for that rule. Test cases serve two functions, firstly as example scenarios for readers to understand when the outcome of a rule is `passed`, `failed`, or `inapplicable`. It also serves developers and users of accessibility testing tools and methodologies to validate that a rule is correctly implemented. + + + + +Change Log {#change-log} +------------------------ + +It is important to keep track of changes to the ACT Rules so that users of the rules can understand if changes in test results are due to changes in the rules used when performing the tests, or from changes in the content itself. All changes to an ACT Rule that can change the [=outcomes=] of an evaluation must be recorded in a change log. The change log can either be part of the rule document itself or be referenced from it. + + +Glossary {#glossary} +-------------------- + +ACT Rules must have a glossary section. The glossary must contain the [=outcome=] definition, as well as any definitions used in [applicability](#applicability) and [expectations](#expectations) sections in the rule. Since changes to the definition change the rule, those definitions cannot be maintained independently of the rule. If a shared glossary is used for rules, any definition changes must be included in the [change log](#change-log) of all rules that use that definition. + + +Issues List (optional) {#issues-list} +------------------------------------- + +An ACT Rule may include a list or a reference to a list of any known issues. The issues list would be used to record cases where an [=outcome=] of an ACT Rule was `failed` where it ought to have been `passed` or `inapplicable`, or vice versa. There are several reasons why this might occur. See [rule accuracy](#rule-accuracy) for more information. + +The issues list serves two purposes. For users of ACT Rules, the issues list gives insight into why an inaccurate result occurred, as well as provide confidence in the result of that rule. For the designer of the rule, the issues list is also useful to plan future updates to the rule. In a new version of the rule, resolved issues would be moved to the change log. + + +Background (optional) {#background} +----------------------------------- + +An ACT Rule may contain information about the background for the development of the rule, or references to relevant reading. The background information is optional, but whenever it is included in the rule, the relationship to the relevant reading can be specified. Examples of relevant background references for a rule for a [Web Content Accessibility Guidelines](https://www.w3.org/WAI/standards-guidelines/wcag/) [[WCAG]] success criterion could be [WCAG 2.1 Understanding documents](https://www.w3.org/WAI/WCAG21/Understanding/), [WCAG 2.1 Techniques](https://www.w3.org/WAI/WCAG21/Techniques/), or [WAI-ARIA 1.1](https://www.w3.org/TR/wai-aria/), CSS [[css-2018]], or HTML [[HTML]] specifications. + + +Acknowledgments (optional) {#acknowledgments} +----------------------------------------------- + +An ACT Rule may contain acknowledgments. This can include, but is not limited to: +* List of rule authors +* List of rule reviewers/contributors +* Funding or other support + + +Rule Accuracy {#rule-accuracy} +========================= + +This section is *non-normative*. + +While [test cases](#test-cases) can be used to determine if an ACT Rule was correctly implemented, they do not guarantee that implementations will never produce incorrect results. When writing ACT Rules, it is almost inevitable that edge cases will be overlooked. Technologies are always evolving, and content authors are constantly coming up with new and unexpected ways to use them. Some examples of causes for inaccuracy are: + +- [Assumptions](#assumptions) were made about the test subject that turned out to be untrue +- Technologies were used in an unusual and difficult to predict manner +- Technologies have changes, or aspects of the technologies were overlooked +- The accessibility requirement was not correctly interpreted + +There are two types of inaccuracies that can produce incorrect results. Inaccuracies in the **implementation** can be addressed with test cases, but inaccuracies in the **ACT Rule itself** cannot. After all, rule inaccuracies come from the rule author being unaware of a particular edge case. + +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 targets=], that were `failed` by the rule, but satisfy the [=accessibility requirements=]. + +- **False negatives:** This is the percentage of [=test targets=], that were `passed` by the rule, but do not satisfy the [=accessibility requirements=]. + +The ever present possibility of false positives and false negatives with ACT Rules means they will likely require ongoing maintenance. Designing a process for maintaining ACT Rules is outside the scope of the ACT Rules Format, which is limited to the rules themselves. Nevertheless, it is suggested that rule authors work out a process for maintaining their rules. + + +Harmonization {#harmonization} +============================== + +This section is *non-normative*. + +While the ACT Rules Format is designed to stimulate harmonization, there are no direct requirement in the ACT Rules Format that prevent a rule author from writing rules inconsistent with already established ACT Rules. Neither are there requirements for ACT Rules to have a certain number of implementations, or to have a certain level of accuracy. This allows quality requirements to be different for different rulesets, and allows them to develop over time. + +Harmonization occurs when a group of rule implementors collectively accept the validity of an ACT Rule. For example, a community group of accessibility testing tool vendors could declare they have harmonized on a particular set of ACT Rules. Such a group can set acceptance criteria for rules, and have quality requirements that go beyond the ACT Rules Format. + + + +An example of such a process is the [WCAG ACT Review Process](https://w3c.github.io/wcag-act-rules/review-process.html). + + +Definitions {#definitions} +========================== + +
+
Accessibility requirement
+
+

An accessibility requirement is a requirement aimed at improving access for people with disabilities to an ICT product. In the context of ACT rules mapping, a requirement can be compulsory or advisory. When compulsory, it has to be satisfied in order to conform to a standard, or to comply with a contract, policy or regulation. When advisory, it is recommended, but not satisfying it does not lead to non-conformance or non-compliance.

+

A common example of accessibility requirements are the WCAG success criteria. There are other standards, including W3C standards, that have recommendations for accessibility, such as WAI-ARIA and HTML. Accessibility requirements are also often found in company policies, regional standards or in legislation.

+
+ +
Accessibility requirements document
+
+

A document, such as a standard, contract, policy or regulation, that includes [=accessibility requirements=]. For example, WCAG 2.1, WAI-ARIA 1.1, HTML 5.2, EPUB Accessibility 1.0, BBC HTML Accessibility Standards v2.0

+
+ +
Outcome
+
+

A conclusion that comes from evaluating an ACT Rule on a [=test subject=] or one of its constituent [=test target=]. An outcome can be one of the three following types:

+
    +
  • **Inapplicable:** No part of the test subject matches the applicability
    • +
  • **Passed:** A [=test target=] meets all expectations
    • +
  • **Failed:** A [=test target=] does not meet all expectations
    • +
+
+

**Note:** A rule has one `passed` or `failed` outcome for every [=test target=]. When there are no test targets the rule has one `inapplicable` outcome. This means that each [=test subject=] will have one or more outcomes.

+
+
+

**Note:** 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 cannot 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. +

+
+ +
Test Subject
+
+

A resource or collection of resources that can be evaluated by an ACT Rule.

+ +
+

**Note:** Implementers using the [[EARL10-Schema]] can express the test subject with the [subject property](https://www.w3.org/TR/EARL10-Schema/#subject)

+
+
+ +
Test Target
+
+

A distinct part of the [=test subject=], as defined by the [applicability](#applicability).

+ +
+

**Note:** Implementers using the [[EARL10-Schema]] can express the test target with the [pointer property](https://www.w3.org/TR/EARL10-Schema/#pointer)

+
+
+
+ + +Appendix 1: Expressing ACT Rule results with JSON-LD and EARL {#appendix-data-example} +================================================================================= + +This section is *non-normative*. + +This section provides examples of expressing results from carrying out ACT Rules using EARL and JSON-LD (See [Evaluation and Report Language](https://www.w3.org/WAI/standards-guidelines/earl/) and [A JSON-based Serialization for Linked Data (JSON-LD)](https://www.w3.org/TR/json-ld/)). More examples and background is proivided on the [JSON-LD serialization of EARL](https://github.com/w3c/earl) GitHub repository. + +Examples in this section include: + +- Example 1: Minimal outcome from one 'Assertion' +- Example 2: Results from more than one 'Assertion' +- Example 3: Aggregating based on 'Requirement' +- Example 4: Aggregating based on 'Test Subject' +- Example 5: Assumed 'Context' for this section + +**Example 1:** Minimal outcome for one 'Assertion' + +```javascript +{ + "@context": "context.json", + "@type": "Assertion", + "assertedBy": "https://example.org/MyTool", + "subject": "https://example.org/page1.html", + "test": "ACT-CG:rules/23a2a8", + "result": { + "outcome": "earl:failed", + "pointer": "html > body > h1:first-child" + } +} +``` + +**Example 2:** Results for more than one 'Assertion' + +```javascript +{ + "@context": "context.json", + "@graph": [{ + "@type": "Assertion", + "assertedBy": "https://example.org/MyTool", + "subject": "https://example.org/page1.html", + "test": "ACT-CG:rules/23a2a8", + "result": { + "outcome": "earl:failed", + "pointer": "html > body > h1:first-child" + } + }, { + "@type": "Assertion", + "assertedBy": "https://example.org/AnotherTool", + "subject": "https://example.org/page1.html", + "test": "ACT-CG:rules/23a2a8", + "result": { + "outcome": "earl:passed", + "pointer": "html > body > h1:nth-child(2)" + } + }] +} +``` + +**Example 3:** Aggregating based on 'Requirement' (eg. WCAG Success Criteria) + +```javascript +{ + "@context": "context.json", + "@type": "Assertion", + "assertedBy": "https://example.org/MyTool", + "subject": "https://example.org/page1.html", + "test": { + "@type": "earl:TestRequirement", + "@id": "WCAG21:non-text-content" + }, + "result": { + "outcome": "earl:failed", + "source": [{ + "test": "ACT-CG:rules/23a2a8", + "result": { + "outcome": "earl:failed", + "pointer": "html > body > h1:first-child" + } + }, { + "test": "ACT-RULES-CG:rules/23a2a8", + "result" : { + "outcome": "earl:passed", + "pointer": "html > body > h1:nth-child(2)" + } + }] + } +} +``` + +**Example 4:** Aggregating based on 'Test Subject' (eg. for a website) + +```javascript +{ + "@context": "context.json", + "@type": "Assertion", + "assertedBy": { + "@type": "Organization", + "@id": "_:myOrg", + "title": "My Organization", + "description" : "Accessibility testing service", + "homepage" : "http://example.org/myOrg/" + }, + "subject": { + "@type": ["WebSite", "TestSubject"], + "@id": "https://example.org/" + }, + "test": { + "@type": "earl:TestRequirement", + "@id": "http://www.w3.org/WAI/WCAG2A-Conformance" + }, + "result": { + "outcome": "earl:failed", + "source": [{ + "test": { + "@type": "earl:TestRequirement", + "@id": "WCAG21:non-text-content" + }, + "result": { + "outcome": "earl:failed", + "source": [ … ] + } + }, { + "test": { + "@type": "earl:TestRequirement", + "@id": "WCAG21:audio-only-and-video-only-prerecorded" + }, + "result": { + "outcome": "earl:passed", + "source": [ … ] + } + }, { + "test": { + "@type": "earl:TestRequirement", + "@id": "WCAG21:captions-prerecorded" + }, + "result" : { + "outcome": "earl:passed", + "source": [ … ] + } + }, … ] + } +} +``` + +**Example 5:** Assumed 'Context' for this section + +```javascript +{ + "@vocab": "http://www.w3.org/ns/earl#", + + "cnt": "http://www.w3.org/2011/content#", + "dct": "http://purl.org/dc/terms/", + "earl": "http://www.w3.org/ns/earl#", + "foaf": "http://xmlns.com/foaf/0.1/", + "htp": "http://www.w3.org/2011/http#", + "ptr": "https://www.w3.org/2009/pointers#", + "schema": "http://schema.org/", + "xsd": "https://www.w3.org/2001/XMLSchema#", + + "WCAG20": "https://www.w3.org/TR/WCAG20#", + "WCAG21": "https://www.w3.org/TR/WCAG21#", + "ACT-RULES-CG": "https://act-rules.github.io/", + + "WebSite": "schema:WebSite", + "WebPage": "schema:WebPage", + + "title": "dct:title", + "description": "dct:description", + "date": "dct:date", + "hasVersion": "dct:hasVesion", + "isPartOf": "dct:isPartOf", + "hasPart": "dct:hasPart", + "source": "dct:source", + + "Agent": "foaf:Agent", + "Person": "foaf:Person", + "Organization": "foaf:Organization", + "Group": "foaf:Group", + "Document": "foaf:Document", + "name": "foaf:name", + "firstName": "foaf:firstName", + "surname": "foaf:surname", + "mbox": "foaf:mbox", + "mbox_sha1sum": "foaf:mbox_sha1sum", + "member": "foaf:member", + "homepage": "foaf:homepage", + + "assertedBy": { "@type": "@id" }, + "subject": { "@type": "@id" }, + "test": { "@type": "@id" }, + "mode": { "@type": "@id" }, + "outcome": { "@type": "@id" }, + "pointer": { + "@id": "earl:pointer", + "@type": "ptr:CSSSelectorPointer" + } +} +``` + +Appendix 2: Acknowledgments {#Acknowledgments} +=========================== + +This section is *non-normative*. + + +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} +---------------- + +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. + + +Appendix 3: Change History {#Change_History} +========================== + +This section is *non-normative*. + +No substantial changes have been made since the previous [Candidate Recommendation draft of 16 April 2019](https://www.w3.org/TR/2019/CR-act-rules-format-1.0-20190416/). The following editorial changes have been made since the previous draft: + +
    +
  • 1. Introduction: Added relationship of ACT Rules to WCAG 2 Techniques
    • +
  • 1. Introduction: Removed unintended word "must" (was never a requirement)
    • +
  • 4. Rule Structure: Clarified that optional parts are a MAY requirement
    • +
  • 4.1. Rule Identifier: Moved requirements on versioning here from 4.11. Changelog
    • +
  • 4.1. Rule Identifier: Clarified scope of uniqueness of an identifier
    • +
  • 4.5.1. Input Aspects: Moved description of serving methods further down
    • +
  • 4.7.1. Expectations for Atomic Rules: Expanded note on complex aggregation
    • +
  • 4.14. Background: Removed unintended word "should" (was never a requirement)
    • +
  • Appendix 1. Expressing ACT Results: Major revision (non-normative examples)
    • +
  • Overall: Edits to align and clarify examples throughout the document
    • +
  • Overall: Fixing typographical, grammatical, and spelling mistakes throughout
    • +
  • Overall: Changed coding of RFC 2119 terms to improve accessibility/semantic
    • +
+ +All changes from the previous published version can be viewed using the [April 2019 to July 2019 diff link](https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FTR%2F2019%2FCR-act-rules-format-1.0-20190416%2F&doc2=https%3A%2F%2Fw3c.github.io%2Fwcag-act%2Fact-rules-format.html) From c9b2608e9df3c6bffd87700e8def4a43da3a972a Mon Sep 17 00:00:00 2001 From: Daniel Date: Tue, 20 Jun 2023 22:55:44 +0200 Subject: [PATCH 53/54] Bikeshed cleanup --- act-rules-format/act-rules-format.bs | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/act-rules-format/act-rules-format.bs b/act-rules-format/act-rules-format.bs index eac0f571..4e379ca4 100644 --- a/act-rules-format/act-rules-format.bs +++ b/act-rules-format/act-rules-format.bs @@ -186,7 +186,7 @@ When a rule is designed to test a specific accessibility requirement, the access Rules that can be used to determine if an accessibility requirement is *satisfied* are called satisfying tests. -- Passed: When all of the outcomes are `passed`, the accessibility requirement is satisfied for the test subject. +- Passed: When all of the outcomes are `passed`, the accessibility requirement is [=satisfied=] for the test subject.

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

@@ -239,7 +239,7 @@ A rule was designed to test a minimum accessibility requirement and there exists
  • Conformance Requirement: Success Criterion 1.4.3 Contrast (Minimum)
  • Secondary Requirement: Success Criterion 1.4.6 Contrast (Enhanced)
    • -
    • Background Section: Success Criterion 1.4.6 is mapped as a Secondary requirement because the SC may be not satisfiedwhen the rule’s outcomes are `passed`.
    +
    • 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`.
@@ -250,7 +250,7 @@ A rule was designed to test a specific type of solution for an accessibility req @@ -715,13 +715,13 @@ This section provides examples of expressing results from carrying out ACT Rules Examples in this section include: -- Example 1: Minimal outcome from one 'Assertion' -- Example 2: Results from more than one 'Assertion' -- Example 3: Aggregating based on 'Requirement' +- Example 1: Minimal outcome from one assertion +- Example 2: Results from more than one assertion +- Example 3: Aggregating based on requirement - Example 4: Aggregating based on 'Test Subject' -- Example 5: Assumed 'Context' for this section +- Example 5: Assumed context for this section -**Example 1:** Minimal outcome for one 'Assertion' +**Example 1:** Minimal outcome for one assertion ```javascript { @@ -737,7 +737,7 @@ Examples in this section include: } ``` -**Example 2:** Results for more than one 'Assertion' +**Example 2:** Results for more than one assertion ```javascript { @@ -764,7 +764,7 @@ Examples in this section include: } ``` -**Example 3:** Aggregating based on 'Requirement' (eg. WCAG Success Criteria) +**Example 3:** Aggregating based on requirement (eg. WCAG Success Criteria) ```javascript { @@ -850,7 +850,7 @@ Examples in this section include: } ``` -**Example 5:** Assumed 'Context' for this section +**Example 5:** Assumed context for this section ```javascript { From 6b9c18790f14000fce53c66a4a707e44778ebaba Mon Sep 17 00:00:00 2001 From: Kathy Eng Date: Thu, 6 Jul 2023 12:13:21 -0400 Subject: [PATCH 54/54] Update act-rules-format/act-rules-format.bs --- act-rules-format/act-rules-format.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format/act-rules-format.bs b/act-rules-format/act-rules-format.bs index 4e379ca4..811b3b56 100644 --- a/act-rules-format/act-rules-format.bs +++ b/act-rules-format/act-rules-format.bs @@ -7,7 +7,7 @@ Level: 1.1 Status: w3c/ED Group: act-rules-format Editor: Wilco Fiers, Deque Systems -Editor: Katherine Eng, US Access Board +Editor: Kathy Eng, US Access Board Editor: Trevor Bostic, MITRE Corp. Former Editor: Maureen Kraft, IBM Corp. Former Editor: Mary Jo Mueller, IBM Corp.