From 41eeb6c56a7e0586bb9fa8c3019740b9c902f36b Mon Sep 17 00:00:00 2001 From: Wilco Fiers Date: Fri, 8 Sep 2023 12:51:02 +0200 Subject: [PATCH 01/14] Add optional Implementations section --- act-rules-format/act-rules-format.bs | 96 ++++++++++++++++++++++++++++ 1 file changed, 96 insertions(+) diff --git a/act-rules-format/act-rules-format.bs b/act-rules-format/act-rules-format.bs index 0db3191d..d4bfe4dc 100644 --- a/act-rules-format/act-rules-format.bs +++ b/act-rules-format/act-rules-format.bs @@ -109,6 +109,7 @@ An ACT Rule MAY also contain: * [Issues List](#issues-list) (optional) * [Background](#background) (optional) +* [Implementations](#implementations) (optional) * [Acknowledgments](#acknowledgments) (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. @@ -544,6 +545,8 @@ 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. +All `passed` and `inapplicable` test cases of an ACT Rule must satisfy at least one of that rule's [=accessibility requirements=]. For all `failed` test cases, all accessibility requirements must be *not satisfied*. +
@@ -595,35 +595,36 @@ An ACT Rule may contain information about the backgroun Implementations (optional) {#implementation} -------------------------------- -An ACT Rule may contain a list of implementations that are consistent or partially consistent with that rule. An [=implementation=] is an accessibility test methodology or test tool that can be used to produce [=outcomes=] of an ACT Rule. +An ACT Rule may contain a list of [=implementations=] with [=checks=] that are consistent or partially consistent with that rule. An implementation is an accessibility test methodology or test tool. An implementation includes with [=checks=]. These checks use automated and/or manual tests to come to [=outcomes=] for [=accessibility requirements=]. -An [=implementation=] consists of one or more [=implementation procedures=]. The [=Implementation procedures=] are not required to have a one-to-one mapping to an ACT Rule. A combination of implementation procedures can together be consistent with a single ACT Rule. A single implementation procedure can also be consistent with multiple ACT Rules. +[=Checks=] are not required to have a one-to-one mapping to an ACT Rule. A combination of checks can together be consistent with a single ACT Rule. A single check can also be consistent with multiple ACT Rules. -For each implementation the following data can be provided. If included, consistency must be determined as defined in this section. +For each implementation information such as the following can be provided. If included, consistency must be determined as defined in this section. +- Name, title or identifier of any consistent or partially consistent checks +- [Consistency](#impl-consistency) (Consistent or partially consistent) +- [test modes](https://www.w3.org/TR/EARL10-Schema/#TestMode) of the checks (e.g. automatic, manual, semiAuto) - Name of implementation -- Name of the vendor -- [Consistency](#impl-consistency) - Version used in testing consistency and coverage -- [test modes](https://www.w3.org/TR/EARL10-Schema/#TestMode) of the set implementation procedures (e.g. automatic, manual, semiAuto) +- Name of the vendor ### Consistency ### {#impl-consistency} -Consistency says how well one or more [=implementation procedure=] are aligned with the intent of an ACT Rule. A **consistent** implementation of an ACT Rule is one that can be used to identify some or all non-conformance issues as described by the rule. An implementation procedure is consistent when all the following are true: +Consistency says how well a [=check=] is aligned with the intent of an ACT Rule. A consistent check of an ACT Rule is one that can be used to identify some or all non-conformance issues as described by the rule. A check is consistent when all the following are true: 1. True positives: There are no inconsistencies with the test cases, meaning: 1. The `passed` and `inapplicable` test cases are **not** reported as `failed`; and 2. The `failed` test cases are **not** reported as `passed` or `inapplicable`; and 2. Completeness: There are no gaps in coverage, meaning: - 1. None of the [=implementation procedure=] outcomes are `untested`; and + 1. None of the [=check=]'s outcomes are `untested`; and 2. At least one of the `failed` test cases is reported as `failed`; and 3. Rule Mapping: The accessibility requirements are reported consistently, meaning: - 1. The [=implementation procedure=] is reported as testing for all the rule's[=conformance requirements=], except requirements of a level or standard not supported by the implementation; and + 1. The [=check=] is reported as testing for all the rule's[=conformance requirements=], except requirements of a level or standard not supported by the implementation; and 2. All accessibility requirements the rule reports to be a part of are either [=conformance requirements=] or [=secondary requirements=], except for requirements of [=accessibility requirement documents=] not mentioned in the rule. -When an [=implementation procedure=] reports more than one outcomes for a test case, the first outcome that appears on the following ordered list is considered for determining consistency: +When a [=check=] reports more than one outcomes for a test case, the first outcome that appears on the following ordered list is considered for determining consistency: 1. `untested` 2. `failed` @@ -633,9 +634,22 @@ When an [=implementation procedure=] reports more than one outcomes for a test c ### Partial Consistency ### {#impl-partial-consistency} -An [=implementation procedure=] that is not **consistent** is considered **partially consistent** if the [=true positive=] conditions are true, and not all outcomes it reports for the rule's test cases are `incomplete` or `untested`. +A [=check=] that is not [=consistent=] is considered partially consistent if the [=true positive=] condition is true and not all outcomes it reports for the rule's test cases are `incomplete` or `untested`. + +### Consistency with multiple checks ### {#impl-multi-check} + +[=Implementation=] can include [=checks=] that test only parts of a single ACT Rule. The combination of those checks can be consistent if all parts of the ACT Rule are covered. The consistency of a set of checks can be determined by treating all [=partially consistent=] checks as though they were a single check. -An implementation can have more than one partially consistent [=implementation procedures=]. The combination of [=implementation procedures=] can be **consistent** if the union of the outcomes and a union of the accessibility requirements meet the requirements for [=consistency=]. +A [=set of checks=] is [=consistent=] with an ACT Rule if it meets all requirements for a [=consistent|consistent check=]. The [=outcomes=] for this set of checks is a list of all outcomes of checks that are partially consistent with the ACT Rule. The accessibility requirements of this set of checks is a list of all accessibility requirements of checks that are partially consistent with the ACT rule. + + Acknowledgments (optional) {#acknowledgments} @@ -707,12 +721,12 @@ Definitions {#definitions}
Implementation
-

An accessibility test methodology or test tool, containing a set of [=implementation procedures=] that describes how to get the expected [=outcomes=] of an ACT Rule.

+

An accessibility test methodology or test tool, containing a set of [=checks=] that describes how to get the expected [=outcomes=] of an ACT Rule.

-
Implementation Procedure
+
Check
-

A procedure resulting in an [=outcome=]. The procedure can be a step by step description of how to manually perform the test, a fully automated test, or some combination of manual and automated testing.

+

A procedure resulting in an [=outcome=]. The procedure can be a step by step description of how to manually perform a test, a fully automated test, or some combination of manual and automated testing.

Outcome
From 6c50185487d493b729ad927750383457cf328bf4 Mon Sep 17 00:00:00 2001 From: Wilco Fiers Date: Thu, 12 Oct 2023 12:47:24 +0200 Subject: [PATCH 06/14] Apply suggestions from code review --- act-rules-format/act-rules-format.bs | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/act-rules-format/act-rules-format.bs b/act-rules-format/act-rules-format.bs index 22023d24..9fd62fc9 100644 --- a/act-rules-format/act-rules-format.bs +++ b/act-rules-format/act-rules-format.bs @@ -545,7 +545,7 @@ 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. -All `passed` and `inapplicable` test cases of an ACT Rule must satisfy at least one of that rule's [=conformance requirements=]. For all `failed` test cases, all conformance requirements must be *not satisfied*. +Every `passed` and `inapplicable` test cases of an ACT Rule must satisfy all the rule's [=conformance requirements=]. For every `failed` test cases, all conformance requirements must be *not satisfied*. @@ -721,7 +720,7 @@ Definitions {#definitions}
Implementation
-

An accessibility test methodology or test tool, containing a set of [=checks=] that describes how to get the expected [=outcomes=] of an ACT Rule.

+

An accessibility test methodology or test tool, containing a set of [=checks=] which can be used to determine (non-)conformance of [=accessibility requirements=].

Check
From 589429718e6797da4ee2abedcd6bc38e6d92418e Mon Sep 17 00:00:00 2001 From: Wilco Fiers Date: Thu, 12 Oct 2023 12:48:11 +0200 Subject: [PATCH 07/14] Update act-rules-format/act-rules-format.bs --- act-rules-format/act-rules-format.bs | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/act-rules-format/act-rules-format.bs b/act-rules-format/act-rules-format.bs index 9fd62fc9..a3d89c9b 100644 --- a/act-rules-format/act-rules-format.bs +++ b/act-rules-format/act-rules-format.bs @@ -718,14 +718,14 @@ Definitions {#definitions}

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

-
Implementation
+
Check
-

An accessibility test methodology or test tool, containing a set of [=checks=] which can be used to determine (non-)conformance of [=accessibility requirements=]. +

A procedure resulting in an [=outcome=]. The procedure can be a step by step description of how to manually perform a test, a fully automated test, or some combination of manual and automated testing.

-
Check
+
Implementation
-

A procedure resulting in an [=outcome=]. The procedure can be a step by step description of how to manually perform a test, a fully automated test, or some combination of manual and automated testing.

+

An accessibility test methodology or test tool, containing a set of [=checks=] which can be used to determine (non-)conformance of [=accessibility requirements=].

Outcome
From 706682831270981293819d3b0a5dd291bfcf4b7e Mon Sep 17 00:00:00 2001 From: Wilco Fiers Date: Thu, 12 Oct 2023 12:49:23 +0200 Subject: [PATCH 08/14] 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 a3d89c9b..7d4cc983 100644 --- a/act-rules-format/act-rules-format.bs +++ b/act-rules-format/act-rules-format.bs @@ -720,7 +720,7 @@ Definitions {#definitions}
Check
-

A procedure resulting in an [=outcome=]. The procedure can be a step by step description of how to manually perform a test, a fully automated test, or some combination of manual and automated testing.

+

A procedure resulting in one or more [=outcomes=] when used to evaluate the accessibility of a web page or other test subject. The procedure can be a step by step description of how to manually perform a test, a fully automated test, or some combination of manual and automated testing.

Implementation
From 5581a5da89954379a2ba8fe8b26a0babee8d1ca7 Mon Sep 17 00:00:00 2001 From: Wilco Fiers Date: Thu, 12 Oct 2023 15:06:20 +0200 Subject: [PATCH 09/14] 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 7d4cc983..108fb153 100644 --- a/act-rules-format/act-rules-format.bs +++ b/act-rules-format/act-rules-format.bs @@ -725,7 +725,7 @@ Definitions {#definitions}
Implementation
-

An accessibility test methodology or test tool, containing a set of [=checks=] which can be used to determine (non-)conformance of [=accessibility requirements=]. +

An accessibility test methodology or test tool, containing a set of [=checks=] which can be used to determine (non-)conformance of [=accessibility requirements=].

Outcome
From b1c6bdc7c8d4106a294c4f95d757e386b1f723db Mon Sep 17 00:00:00 2001 From: Wilco Fiers Date: Thu, 9 Nov 2023 14:03:21 +0100 Subject: [PATCH 10/14] Apply suggestions from code review Co-authored-by: Trevor R. Bostic <32486143+tbostic32@users.noreply.github.com> --- act-rules-format/act-rules-format.bs | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/act-rules-format/act-rules-format.bs b/act-rules-format/act-rules-format.bs index 108fb153..dec423df 100644 --- a/act-rules-format/act-rules-format.bs +++ b/act-rules-format/act-rules-format.bs @@ -595,9 +595,9 @@ An ACT Rule may contain information about the backgroun Implementations (optional) {#implementation} -------------------------------- -An ACT Rule may contain a list of [=implementations=] with [=checks=] that are consistent or partially consistent with that rule. An implementation is an accessibility test methodology or test tool that uses [=checks=] that give [=outcomes=] indicating whether [=accessibility requirement=] could be satisfied. These checks can be fully automated, completely manual, or some combination of the two. +An ACT Rule may contain a list of [=implementations=], where each [=implementation=] has one or more [=checks=] that are consistent or partially consistent with that rule. An implementation is an accessibility test methodology or test tool that uses [=checks=] to compute [=outcomes=] indicating whether an [=accessibility requirement=] could be satisfied. These checks can be fully automated, completely manual, or some combination of the two. -[=Checks=] are not required to have a one-to-one mapping to an ACT Rule. A single check can be consistent with multiple ACT Rules. A [combination of checks](#impl-partial-consistency) can together be consistent with a single ACT Rule. +[=Checks=] are not required to have a one-to-one mapping to an ACT Rule. A single check can be consistent with multiple ACT Rules or a [set of checks](#impl-partial-consistency) can together be consistent with a single ACT Rule. If implementations are included in an ACT Rule, consistency must be determined as defined in this section. Other information can also be included for an implementation, such as the following: @@ -609,7 +609,7 @@ If implementations are included in an ACT Rule, consistency ### Consistency ### {#impl-consistency} -Consistency says how well a [=check=] is aligned with the intent of an ACT Rule. A consistent check of an ACT Rule is one that can be used to identify some or all non-conformance issues as described by the rule. A check is consistent when all the following are true: +Consistency describes how well a [=check=] is aligned with the intent of an ACT Rule. A consistent check of an ACT Rule is one that can be used to identify some or all non-conformance issues as described by the rule. A check is consistent when all the following are true: 1. True positives: There are no inconsistencies with the test cases, meaning: 1. The `passed` and `inapplicable` test cases are **not** reported as `failed`; and @@ -637,16 +637,16 @@ A [=check=] that is not [=consistent=] is considered partially consistentset of checks can be determined by treating all [=partially consistent=] checks as though they were a single check. +An [=implementation=] can include [=checks=] that test only parts of a single ACT Rule. The combination of those checks can be consistent if all parts of the ACT Rule are covered. The consistency of a set of checks can be determined by treating all [=partially consistent=] checks as though they were a single check. A [=set of checks=] is [=consistent=] with an ACT Rule if it meets all requirements for a [=consistent|consistent check=]. The [=outcomes=] for this set of checks is a list of all outcomes of checks that are partially consistent with the ACT Rule. The accessibility requirements of this set of checks is a list of all accessibility requirements of checks that are partially consistent with the ACT rule. From 0a4cdd9c8644b31a5e30db45b52afa0358fb688c Mon Sep 17 00:00:00 2001 From: Wilco Fiers Date: Thu, 9 Nov 2023 14:32:04 +0100 Subject: [PATCH 11/14] Work through feedback --- act-rules-format/act-rules-format.bs | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/act-rules-format/act-rules-format.bs b/act-rules-format/act-rules-format.bs index dec423df..005317af 100644 --- a/act-rules-format/act-rules-format.bs +++ b/act-rules-format/act-rules-format.bs @@ -599,9 +599,10 @@ An ACT Rule may contain a list of [=implementations=], [=Checks=] are not required to have a one-to-one mapping to an ACT Rule. A single check can be consistent with multiple ACT Rules or a [set of checks](#impl-partial-consistency) can together be consistent with a single ACT Rule. -If implementations are included in an ACT Rule, consistency must be determined as defined in this section. Other information can also be included for an implementation, such as the following: +For each implementation, information such as the following could be included: - Name, title or identifier of any consistent or partially consistent checks +- [Consistency](#impl-consistency) - [test modes](https://www.w3.org/TR/EARL10-Schema/#TestMode) of the checks (e.g. automatic, manual, semiAuto) - Name of implementation - Version used in testing consistency and coverage @@ -609,7 +610,7 @@ If implementations are included in an ACT Rule, consistency ### Consistency ### {#impl-consistency} -Consistency describes how well a [=check=] is aligned with the intent of an ACT Rule. A consistent check of an ACT Rule is one that can be used to identify some or all non-conformance issues as described by the rule. A check is consistent when all the following are true: +Consistency describes how well a [=check=] is aligned with the intent of an ACT Rule. If consistency is included in an ACT Rule it must be determined as defined in this section. A consistent check of an ACT Rule is one that can be used to identify some or all non-conformance issues as described by the rule. A check is consistent when all the following are true: 1. True positives: There are no inconsistencies with the test cases, meaning: 1. The `passed` and `inapplicable` test cases are **not** reported as `failed`; and @@ -633,7 +634,7 @@ When a [=check=] reports more than one outcomes for a test case, the first outco ### Partial Consistency ### {#impl-partial-consistency} -A [=check=] that is not [=consistent=] is considered partially consistent if the [=true positive=] condition is true and not all outcomes it reports for the rule's test cases are `incomplete` or `untested`. +A [=check=] that is not [=consistent=] is considered partially consistent if the [=true positive=] condition is true and not all outcomes it reports for the rule's test cases are `cantTell` or `untested`. ### Consistency with multiple checks ### {#impl-multi-check} @@ -730,17 +731,18 @@ Definitions {#definitions}
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:

+

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 five 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
    • +
  • **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
    • +
  • **cantTell:** Whether the rule is applicable, or not all expectations were met could not be fully determined by the tester.
    • +
  • **Untested:** The tester has not attempted to evaluate the test subject.
-

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

**Note:** A rule has one `passed` or `failed` outcome for every [=test target=]. When a tester evaluates a test target it can also be reported as `cantTell` if the rule cannot be tested in its entirety. For example, when applicability was automated, but the expectations have to be evaluated manually.

+

When there are no test targets the rule has one `inapplicable` outcome. If the tester is unable to determine whether there are test targets there will be one `cantTell` outcome. And when no evaluation has occurred the test target has one `untested` outcome. This means that each [=test subject=] always has one or more outcomes.

+

Outcomes used in ACT Rules can be expressed using the [outcome property](https://www.w3.org/TR/EARL10-Schema/#outcome) of the [[EARL10-Schema]].

From 243710cb2944bc69bb89aae744fb972a774c881e Mon Sep 17 00:00:00 2001 From: Daniel Date: Fri, 17 Nov 2023 17:56:15 +0100 Subject: [PATCH 12/14] Add leading slashes for closing dt tags --- act-rules-format/act-rules-format.bs | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/act-rules-format/act-rules-format.bs b/act-rules-format/act-rules-format.bs index 005317af..fac61159 100644 --- a/act-rules-format/act-rules-format.bs +++ b/act-rules-format/act-rules-format.bs @@ -708,23 +708,23 @@ Definitions {#definitions} ==========================
-
Accessibility requirement
+
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
+
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

-
Check
+
Check

A procedure resulting in one or more [=outcomes=] when used to evaluate the accessibility of a web page or other test subject. The procedure can be a step by step description of how to manually perform a test, a fully automated test, or some combination of manual and automated testing.

-
Implementation
+
Implementation

An accessibility test methodology or test tool, containing a set of [=checks=] which can be used to determine (non-)conformance of [=accessibility requirements=].

From d78ea2fab792f93672a5a1b2188b48087aea05c6 Mon Sep 17 00:00:00 2001 From: Daniel Date: Fri, 17 Nov 2023 18:09:26 +0100 Subject: [PATCH 13/14] Fix wrong id fragment --- 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 fac61159..ed6d4bb0 100644 --- a/act-rules-format/act-rules-format.bs +++ b/act-rules-format/act-rules-format.bs @@ -592,7 +592,7 @@ 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. -Implementations (optional) {#implementation} +Implementations (optional) {#implementations} -------------------------------- An ACT Rule may contain a list of [=implementations=], where each [=implementation=] has one or more [=checks=] that are consistent or partially consistent with that rule. An implementation is an accessibility test methodology or test tool that uses [=checks=] to compute [=outcomes=] indicating whether an [=accessibility requirement=] could be satisfied. These checks can be fully automated, completely manual, or some combination of the two. From fe4ff6e9987f92a4137860a1e182a8afd3017335 Mon Sep 17 00:00:00 2001 From: Wilco Fiers Date: Tue, 21 Nov 2023 15:18:59 +0100 Subject: [PATCH 14/14] Apply suggestions from code review Co-authored-by: Trevor R. Bostic <32486143+tbostic32@users.noreply.github.com> --- 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 ed6d4bb0..5519bc2b 100644 --- a/act-rules-format/act-rules-format.bs +++ b/act-rules-format/act-rules-format.bs @@ -545,7 +545,7 @@ 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. -Every `passed` and `inapplicable` test cases of an ACT Rule must satisfy all the rule's [=conformance requirements=]. For every `failed` test cases, all conformance requirements must be *not satisfied*. +Each`passed` and `inapplicable` test case of an ACT Rule must satisfy all the rule's [=conformance requirements=]. For each `failed` test case, all conformance requirements must be *not satisfied*.