From 981b32a75fbf351ce7aed777f5634746dc54716c Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 16 Apr 2018 10:50:15 -0400 Subject: [PATCH 01/34] Update act-rules-format.bs --- act-rules-format.bs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 8639633f..ea244dad 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -15,7 +15,7 @@ Markup Shorthands: markdown yes Introduction {#intro} ===================== -There are currently many products available which aid their users in testing web content for conformance to accessibility standards such as the Web Content Accessibility Guidelines (WCAG) 2.0. As the web develops and grows in both size and complexity, these tools are essential for managing the accessibility of resources available on the web. +There are currently many products available which aid their users in testing web content for conformance to accessibility standards such as the Web Content Accessibility Guidelines (WCAG) 2.0 [[WCAG20]]. As the web develops and grows in both size and complexity, these tools are essential for managing the accessibility of resources available on the web. This format is intended to enable a consistent interpretation of how to test for accessibility requirements to avoid conflicting results of accessibility tests. It is intended to be used to describe both manual accessibility tests as well as automated tests performed by accessibility test tools (ATTs). @@ -29,7 +29,7 @@ The ACT Rules Format defined in this specification is focused on the description For instance, the ACT Rules Format can be used to describe ACT Rules dedicated to testing the accessibility requirements defined in 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. However, the ACT Rules Format would not necessarily be suitable to describe tests for the conformance of a non-web-based user agent. +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 [[UAAG20]]. However, the ACT Rules Format would not necessarily be suitable to describe tests for the conformance of a non-web-based user agent. ACT Rule Structure {#structure} From 3c7d066417562acf2ce1d563b240c114e54e71b8 Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 16 Apr 2018 11:00:44 -0400 Subject: [PATCH 02/34] Update act-rules-format.bs --- act-rules-format.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index ea244dad..b8ea7f44 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -47,7 +47,7 @@ An ACT Rule MUST be written in plain language. It MUST consist of the following * [Limitations, Assumptions or Exceptions](#structure-limitations-assumptions-exceptions), if any * [Accessibility Support](#acc-support) (optional) * [Aspects Under Test](#input-aspects) -* [Test Procedure](#test-proc) +* [Test Definition](#test-def) Unique Identifier {#unique-identifier} ---------------------------------------- From 4501eb642ef13f5b45a00b2398199285c4f6ade9 Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 16 Apr 2018 11:23:14 -0400 Subject: [PATCH 03/34] Update act-rules-format.bs --- act-rules-format.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index b8ea7f44..e062cf69 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -25,7 +25,7 @@ Describing how to test certain accessibility requirements will result in accessi Scope {#scope} ============== -The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as HTML, CSS, WAI-ARIA, SVG and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. +The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as HTML [[HTML5]], CSS [[CSS21]], WAI-ARIA [[ARIA11]], SVG [[SVG11]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. For instance, the ACT Rules Format can be used to describe ACT Rules dedicated to testing the accessibility requirements defined in WCAG, which are specifically designed for web content. From bf1e882e21cf4a83159541312dcd81a3f8622819 Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 16 Apr 2018 11:26:25 -0400 Subject: [PATCH 04/34] Update act-rules-format.bs --- act-rules-format.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index e062cf69..985fcb79 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -25,7 +25,7 @@ Describing how to test certain accessibility requirements will result in accessi Scope {#scope} ============== -The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as HTML [[HTML5]], CSS [[CSS21]], WAI-ARIA [[ARIA11]], SVG [[SVG11]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. +The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as HTML [[HTML5]], CSS [[CSS21]], WAI-ARIA [[WAI-ARIA11]], SVG [[SVG11]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. For instance, the ACT Rules Format can be used to describe ACT Rules dedicated to testing the accessibility requirements defined in WCAG, which are specifically designed for web content. From d6a2a6fc332b7835f0570bb689fffea5157beb3f Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 16 Apr 2018 11:32:00 -0400 Subject: [PATCH 05/34] Update act-rules-format.bs --- act-rules-format.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 985fcb79..310b9277 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -25,7 +25,7 @@ Describing how to test certain accessibility requirements will result in accessi Scope {#scope} ============== -The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as HTML [[HTML5]], CSS [[CSS21]], WAI-ARIA [[WAI-ARIA11]], SVG [[SVG11]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. +The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as HTML [[HTML5]], CSS [[CSS21]], WAI-ARIA, SVG [[SVG11]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. For instance, the ACT Rules Format can be used to describe ACT Rules dedicated to testing the accessibility requirements defined in WCAG, which are specifically designed for web content. From 9f88b8b9fa573cbe0e7d7a9a31a9f1db17c26f5f Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 23 Apr 2018 09:13:02 -0400 Subject: [PATCH 06/34] Update act-rules-format.bs --- act-rules-format.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 310b9277..5936e035 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -25,7 +25,7 @@ Describing how to test certain accessibility requirements will result in accessi Scope {#scope} ============== -The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as HTML [[HTML5]], CSS [[CSS21]], WAI-ARIA, SVG [[SVG11]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. +The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as HTML [[HTML5]], CSS [[CSS21]], WAI-ARIA{wai-aria-1.1], SVG [[SVG11]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. For instance, the ACT Rules Format can be used to describe ACT Rules dedicated to testing the accessibility requirements defined in WCAG, which are specifically designed for web content. From 162d0a77091cf5003938443d978707d184d04a2e Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 23 Apr 2018 09:14:17 -0400 Subject: [PATCH 07/34] Update act-rules-format.bs --- act-rules-format.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 5936e035..d5d53687 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -25,7 +25,7 @@ Describing how to test certain accessibility requirements will result in accessi Scope {#scope} ============== -The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as HTML [[HTML5]], CSS [[CSS21]], WAI-ARIA{wai-aria-1.1], SVG [[SVG11]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. +The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as HTML [[HTML5]], CSS [[CSS21]], WAI-ARIA[wai-aria-1.1], SVG [[SVG11]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. For instance, the ACT Rules Format can be used to describe ACT Rules dedicated to testing the accessibility requirements defined in WCAG, which are specifically designed for web content. From 633af2c7a7d3a61b2fbf8a155da1ca71b1c04cda Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 23 Apr 2018 09:18:44 -0400 Subject: [PATCH 08/34] Update act-rules-format.bs --- act-rules-format.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index d5d53687..66a65aec 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -25,7 +25,7 @@ Describing how to test certain accessibility requirements will result in accessi Scope {#scope} ============== -The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as HTML [[HTML5]], CSS [[CSS21]], WAI-ARIA[wai-aria-1.1], SVG [[SVG11]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. +The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as HTML [[HTML5]], CSS [[CSS21]], WAI-ARIA [[wai-aria-1.1]], SVG [[SVG11]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. For instance, the ACT Rules Format can be used to describe ACT Rules dedicated to testing the accessibility requirements defined in WCAG, which are specifically designed for web content. From 8cd2ffce01cc7099c8378faada4ea33d3fa3780f Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 23 Apr 2018 10:19:13 -0400 Subject: [PATCH 09/34] Update act-rules-format.bs --- act-rules-format.bs | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 66a65aec..d327d857 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -25,7 +25,7 @@ Describing how to test certain accessibility requirements will result in accessi Scope {#scope} ============== -The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as HTML [[HTML5]], CSS [[CSS21]], WAI-ARIA [[wai-aria-1.1]], SVG [[SVG11]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. +The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as Hypertext Markup Language (HTML) [[HTML5]], Cascading Style Sheets (CSS) [[CSS21]], Accessible Rich Internet Applications (WAI-ARIA) [[wai-aria-1.1]], Scaleable Vector Graphics (SVG) [[SVG11]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. For instance, the ACT Rules Format can be used to describe ACT Rules dedicated to testing the accessibility requirements defined in WCAG, which are specifically designed for web content. @@ -64,7 +64,7 @@ An ACT Rule MUST have a description that is in plain language and provides a bri Accessibility Requirements {#structure-accessibility-requirements} ------------------------------------------------------------------- -An ACT Rule MUST identify the accessibility requirements to which the rule maps. For example, WCAG 2.0 Success Criterion 1.1.1. An ACT Rule is a complete or partial test for one or more accessibility requirements. +An ACT Rule MUST identify the accessibility requirements to which the rule maps. For example, [WCAG 2.0 Success Criterion 1.1.1](https://www.w3.org/TR/2008/REC-WCAG20-20081211/#text-equiv-all). An ACT Rule is a complete or partial test for one or more accessibility requirements. Outcomes from an ACT Rule MUST be consistent with the accessibility requirement, e.g. a rule only returns the outcome Fail when the content fails the accessibility requirement. This means that the rule maps to the accessibility requirement, as opposed to it merely being related to the requirement, thematically or otherwise. @@ -74,7 +74,7 @@ The actual definition of specific accessibility requirements is beyond the scope Limitations, Assumptions or Exceptions {#structure-limitations-assumptions-exceptions} ------------------------------------------------------------------- -An ACT Rule MUST list any limitations, assumptions or any exceptions for the test, the test environment, technologies being used or the subject being tested. For example, a rule for Success Criterion 1.4.1: Use of Color has to make an assumption that CSS is used to make a link visually evident - typically by using CSS background, border, color, font, or text-decoration properties. +An ACT Rule MUST list any limitations, assumptions or any exceptions for the test, the test environment, technologies being used or the subject being tested. For example, a rule for [WCAG 2.0 Success Criterion 1.4.1: Use of Color](https://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast-without-color) has to make an assumption that CSS is used to make a link visually evident - typically by using CSS background, border, color, font, or text-decoration properties. Accessibility Support {#acc-support} @@ -90,7 +90,7 @@ To support users of ACT Rules in properly defining their test scenarios, an ACT Aspects Under Test {#input-aspects} =================================== -ACT Rules can operate on different aspects of the subject being tested. An aspect is a distinct part of the test subject itself or its underlying implementation. For example, rendering a web page to an end user involves multiple different technologies, some or all of which may be of interest to an ACT Rule. Some rules need to operate directly on the HTTP messages exchanged between a server and a client, while others need to operate on the DOM tree exposed by a web browser. Some rules may even need to operate on several aspects simultaneously such as both the HTTP messages and the DOM tree. +ACT Rules can operate on different aspects of the subject being tested. An aspect is a distinct part of the test subject itself or its underlying implementation. For example, rendering a web page to an end user involves multiple different technologies, some or all of which may be of interest to an ACT Rule. Some rules need to operate directly on the Hypertext Transfer Protocol (HTTP) [[HTTP]] messages exchanged between a server and a client, while others need to operate on the Document Object Model (DOM) [[DOM]] tree exposed by a web browser. Some rules may even need to operate on several aspects simultaneously such as both the HTTP messages and the DOM tree. An ACT Rule MUST include a description of all the aspects under test by the rule. Each aspect MUST be discrete with no overlap between the aspects. Some aspects are already well defined within the context of web content, such as HTTP messages, DOM tree, and CSS styling, and do not warrant a detailed description. Other aspects may not be well defined or even specific to web content. In these cases, an ACT Rule SHOULD include either a detailed description of the aspect in question or a reference to that description. @@ -130,12 +130,12 @@ The means by which the language is assessed, whether by a person or a machine, i ACT Test Definition {#test-def} =============================== -Applicability +Applicability {#test-applicability} ------------- -The applicability section is a required part of an ACT 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 tree, or tags that are incorrectly closed in an HTML document. These are known as the *test targets*. The applicability MUST only use information provided through test aspects of the same rule. No other information should be used in the applicability. +The applicability section is a required part of an ACT rule. It MUST contain a precise description of the parts of the [test subject](#output-test-subject) to which the rule applies. For example, specific nodes in the DOM tree, or tags that are incorrectly closed in an HTML document. These are known as the [test targets](#output-test-target). The applicability MUST only use information provided through test aspects of the same rule. No other information should be used in the applicability. -Applicability MUST be described objectively, unambiguously and in plain language. When a formal syntax (such as a CSS selector or XPATH) can be used, that (part of the) applicability MAY use that syntax in addition to the plain language description. While testing, if nothing within the test subject matches the applicability of the rule, the result is `inapplicable`. +Applicability MUST be described objectively, unambiguously and in plain language. When a formal syntax, such as a CSS selector [[[css3-selectors]] or XPATH [[XPATH]], can be used, that (part of the) applicability MAY use that syntax in addition to the plain language description. While testing, if nothing within the test subject matches the applicability of the rule, the result is `inapplicable`. An objective description is one that can be resolved without uncertainty in a given technology. Examples of objective properties in HTML are element names, their computed role, the spacing 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. Is this talking about the tag name, the accessibility role, it's purpose in the web page - the latter of which is almost impossible to define with objectivity. When used in applicability, these concepts MUST have an objective definition. This definition can be part of a larger glossary shared between rules. @@ -151,14 +151,14 @@ An objective description is one that can be resolved without uncertainty in a gi Expectations ------------ -An ACT Rule MUST contain one or more expectations. An expectation is an assertion that must be true about each test target (see Applicability). Each expectation MUST be distinct, unambiguous, and be written in plain language. Unlike in applicability, a certain level of subjectivity is allowed in expectations. Meaning that the expectation has only one possible meaning, but that meaning isn't fully quantifiable. +An ACT Rule MUST contain one or more expectations. An expectation is an assertion that must be true about each test target (see [Applicability](#test-applicability)). Each expectation MUST be distinct, unambiguous, and be written in plain language. Unlike in applicability, a certain level of subjectivity is allowed in expectations. Meaning that the expectation has only one possible meaning, but that meaning isn't fully quantifiable.

Editor note - The task force is looking for feedback about whether expectations should be allowed to reference each other, or if each must be testable independently of the others. For details, see [Github issue #173](https://github.com/w3c/wcag-act/issues/173).

-When all expectations are true for a *test target* it `passed` the rule. If one or more expectations is false, the *test target* `failed` the rule. If the rule is part of a rule group, a *test target* that `failed` a rule may still meet the requirement (see Rule Grouping for details). +When all expectations are true for a test target it `passed` the rule. If one or more expectations is false, the test target `failed` the rule. If the rule is part of a rule group, a *test target* that `failed` a rule may still meet the requirement (see Rule Grouping for details).

A rule for labels of HTML `input` elements may have the following expectations:

From a84b7015cdd2174141f80c61cc0ed92a01f4471b Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 23 Apr 2018 10:21:24 -0400 Subject: [PATCH 10/34] Update act-rules-format.bs --- act-rules-format.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index d327d857..416888b8 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -90,7 +90,7 @@ To support users of ACT Rules in properly defining their test scenarios, an ACT Aspects Under Test {#input-aspects} =================================== -ACT Rules can operate on different aspects of the subject being tested. An aspect is a distinct part of the test subject itself or its underlying implementation. For example, rendering a web page to an end user involves multiple different technologies, some or all of which may be of interest to an ACT Rule. Some rules need to operate directly on the Hypertext Transfer Protocol (HTTP) [[HTTP]] messages exchanged between a server and a client, while others need to operate on the Document Object Model (DOM) [[DOM]] tree exposed by a web browser. Some rules may even need to operate on several aspects simultaneously such as both the HTTP messages and the DOM tree. +ACT Rules can operate on different aspects of the subject being tested. An aspect is a distinct part of the test subject itself or its underlying implementation. For example, rendering a web page to an end user involves multiple different technologies, some or all of which may be of interest to an ACT Rule. Some rules need to operate directly on the Hypertext Transfer Protocol (HTTP) [[http11]] messages exchanged between a server and a client, while others need to operate on the Document Object Model (DOM) [[DOM]] tree exposed by a web browser. Some rules may even need to operate on several aspects simultaneously such as both the HTTP messages and the DOM tree. An ACT Rule MUST include a description of all the aspects under test by the rule. Each aspect MUST be discrete with no overlap between the aspects. Some aspects are already well defined within the context of web content, such as HTTP messages, DOM tree, and CSS styling, and do not warrant a detailed description. Other aspects may not be well defined or even specific to web content. In these cases, an ACT Rule SHOULD include either a detailed description of the aspect in question or a reference to that description. From 36d9bfdd365836811f146a7b1633c09f4633ffc0 Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 23 Apr 2018 10:31:50 -0400 Subject: [PATCH 11/34] Update act-rules-format.bs --- act-rules-format.bs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 416888b8..31bc67b4 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -133,9 +133,9 @@ ACT Test Definition {#test-def} Applicability {#test-applicability} ------------- -The applicability section is a required part of an ACT rule. It MUST contain a precise description of the parts of the [test subject](#output-test-subject) to which the rule applies. For example, specific nodes in the DOM tree, or tags that are incorrectly closed in an HTML document. These are known as the [test targets](#output-test-target). The applicability MUST only use information provided through test aspects of the same rule. No other information should be used in the applicability. +The applicability section is a required part of an ACT rule. It MUST contain a precise description of the parts of the [test subject](#output-test-subject) to which the rule applies. For example, specific nodes in the DOM tree, or tags that are incorrectly closed in an HTML document. These are known as the [test targets](#output-test-target). The applicability MUST only use information provided through [test aspects](#input-aspects) of the same rule. No other information should be used in the applicability. -Applicability MUST be described objectively, unambiguously and in plain language. When a formal syntax, such as a CSS selector [[[css3-selectors]] or XPATH [[XPATH]], can be used, that (part of the) applicability MAY use that syntax in addition to the plain language description. While testing, if nothing within the test subject matches the applicability of the rule, the result is `inapplicable`. +Applicability MUST be described objectively, unambiguously and in plain language. When a formal syntax, such as a CSS selector [[css3-selectors]] or XPATH [[XPATH]], can be used, that (part of the) applicability MAY use that syntax in addition to the plain language description. While testing, if nothing within the test subject matches the applicability of the rule, the result is `inapplicable`. An objective description is one that can be resolved without uncertainty in a given technology. Examples of objective properties in HTML are element names, their computed role, the spacing 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. Is this talking about the tag name, the accessibility role, it's purpose in the web page - the latter of which is almost impossible to define with objectivity. When used in applicability, these concepts MUST have an objective definition. This definition can be part of a larger glossary shared between rules. From 8cb3848515f14493328931d26e06d02b4d5f3bff Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 30 Apr 2018 09:30:51 -0400 Subject: [PATCH 12/34] updating links to be consistent --- act-rules-format.bs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 31bc67b4..986c9938 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -137,7 +137,7 @@ The applicability section is a required part of an ACT rule. It MUST contain a p Applicability MUST be described objectively, unambiguously and in plain language. When a formal syntax, such as a CSS selector [[css3-selectors]] or XPATH [[XPATH]], can be used, that (part of the) applicability MAY use that syntax in addition to the plain language description. While testing, if nothing within the test subject matches the applicability of the rule, the result is `inapplicable`. -An objective description is one that can be resolved without uncertainty in a given technology. Examples of objective properties in HTML are element names, their computed role, the spacing 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. Is this talking about the tag name, the accessibility role, it's purpose in the web page - the latter of which is almost impossible to define with objectivity. When used in applicability, these concepts MUST have an objective definition. This definition can be part of a larger glossary shared between rules. +An objective description is one that can be resolved without uncertainty in a given technology. Examples of objective properties in HTML are element names, their computed role, the spacing 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. Is this talking about the tag name, the accessibility role, it's purpose in the web page? The latter of which is almost impossible to define with objectivity. When used in applicability, these concepts MUST have an objective definition. This definition can be part of a larger glossary shared between rules.

A rule for labels of HTML `input` elements may have the following expectations:

@@ -158,7 +158,7 @@ An ACT Rule MUST contain one or more expectations. An expectation is an assertio For details, see [Github issue #173](https://github.com/w3c/wcag-act/issues/173).

-When all expectations are true for a test target it `passed` the rule. If one or more expectations is false, the test target `failed` the rule. If the rule is part of a rule group, a *test target* that `failed` a rule may still meet the requirement (see Rule Grouping for details). +When all expectations are true for a test target (#output-test-subject), the tes target `passed` the rule. If one or more expectations is false, the test target `failed` the rule. If the rule is part of a rule group, a test target that `failed` a rule may still meet the requirement (see Rule Grouping for details).

A rule for labels of HTML `input` elements may have the following expectations:

From 3c2b792d7eb8863e31fa658ec2786252cac7bbee Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 30 Apr 2018 10:17:02 -0400 Subject: [PATCH 13/34] Consistent linking for Expectations --- act-rules-format.bs | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 986c9938..4274c69b 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -82,7 +82,7 @@ Accessibility Support {#acc-support} ACT Rules are designed to test accessible uses of a web technology. However, not every part of a web technology is implemented in all assistive technologies a website may need to support. The concept of [accessibility supported](https://www.w3.org/TR/WCAG20/#accessibility-supporteddef) use of a Web technology is defined in [[WCAG20]]. Because of this, ACT Rules are not necessarily applicable in all test scenarios. For instance, a web page that has to work in assistive technologies that have no WAI-ARIA support, wouldn’t be tested with an ACT Rule that relies on WAI-ARIA support, since this could lead to false positive results. -Even within a rules group, certain individual rules are not always applicable. This leaves one fewer solution for passing that particular rule group. Because of this, ACT Rules have to be atomic, meaning an ACT Rule MUST NOT rely on other rules to be part of the same test scenario. +Even within a [rules group][rule group](#grouping), certain individual rules are not always applicable. This leaves one fewer solution for passing that particular rule group. Because of this, ACT Rules have to be atomic, meaning an ACT Rule MUST NOT rely on other rules to be part of the same test scenario. To support users of ACT Rules in properly defining their test scenarios, an ACT Rule SHOULD include a warning if there are significant accessibility support concerns known about a rule. @@ -148,7 +148,7 @@ An objective description is one that can be resolved without uncertainty in a gi
-Expectations +Expectations {#expectations} ------------ An ACT Rule MUST contain one or more expectations. An expectation is an assertion that must be true about each test target (see [Applicability](#test-applicability)). Each expectation MUST be distinct, unambiguous, and be written in plain language. Unlike in applicability, a certain level of subjectivity is allowed in expectations. Meaning that the expectation has only one possible meaning, but that meaning isn't fully quantifiable. @@ -158,7 +158,7 @@ An ACT Rule MUST contain one or more expectations. An expectation is an assertio For details, see [Github issue #173](https://github.com/w3c/wcag-act/issues/173).

-When all expectations are true for a test target (#output-test-subject), the tes target `passed` the rule. If one or more expectations is false, the test target `failed` the rule. If the rule is part of a rule group, a test target that `failed` a rule may still meet the requirement (see Rule Grouping for details). +When all expectations are true for a test target (#output-test-subject), the test target `passed` the rule. If one or more expectations is false, the test target `failed` the rule. If the rule is part of a rule group, a test target that `failed` a rule may still meet the requirement (see [Rule Grouping](#grouping) for details).

A rule for labels of HTML `input` elements may have the following expectations:

From dc674a9e5e83f25545cdc9568395526f65d84514 Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 30 Apr 2018 11:07:57 -0400 Subject: [PATCH 14/34] Consistent linking - Rule grouping --- act-rules-format.bs | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 4274c69b..2c863489 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -140,7 +140,7 @@ 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 element names, their computed role, the spacing 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. Is this talking about the tag name, the accessibility role, it's purpose in the web page? The latter of which is almost impossible to define with objectivity. When used in applicability, these concepts MUST have an objective definition. This definition can be part of a larger glossary shared between rules.
-

A rule for labels of HTML `input` elements may have the following expectations:

+

A rule for labels of HTML `input` elements may have the following [expectations](#expectations):

  1. The test target has an accessible name (as described in [Accessible Name and Description: Computation and API Mappings 1.1](https://www.w3.org/TR/accname-aam-1.1/#mapping_additional_nd_te)).
  2. The accessible name describes the purpose of the test target.
    3. @@ -151,14 +151,14 @@ An objective description is one that can be resolved without uncertainty in a gi Expectations {#expectations} ------------ -An ACT Rule MUST contain one or more expectations. An expectation is an assertion that must be true about each test target (see [Applicability](#test-applicability)). Each expectation MUST be distinct, unambiguous, and be written in plain language. Unlike in applicability, a certain level of subjectivity is allowed in expectations. Meaning that the expectation has only one possible meaning, but that meaning isn't fully quantifiable. +An ACT Rule MUST contain one or more expectations. An expectation is an assertion that must be true about each [test target](#output-test-target) (see [Applicability](#test-applicability)). Each expectation MUST be distinct, unambiguous, and be written in plain language. Unlike in applicability, a certain level of subjectivity is allowed in expectations. Meaning that the expectation has only one possible meaning, but that meaning isn't fully quantifiable.

    Editor note - The task force is looking for feedback about whether expectations should be allowed to reference each other, or if each must be testable independently of the others. For details, see [Github issue #173](https://github.com/w3c/wcag-act/issues/173).

    -When all expectations are true for a test target (#output-test-subject), the test target `passed` the rule. If one or more expectations is false, the test target `failed` the rule. If the rule is part of a rule group, a test target that `failed` a rule may still meet the requirement (see [Rule Grouping](#grouping) for details). +When all expectations are true for a test target, the test target `passed` the rule. If one or more expectations is false, the test target `failed` the rule. If the rule is part of a rule group, a test target that `failed` a rule may still meet the requirement (see [Rule Grouping](#grouping) for details).

    A rule for labels of HTML `input` elements may have the following expectations:

    @@ -173,18 +173,18 @@ An expectation MUST only use information available in the test aspects, and from Rule Grouping {#grouping} =================== -In accessibility testing, there are often multiple ways to solve the same problem. For instance, header cells in HTML tables can be indicated through the `scope` attribute, by using the `headers` attribute, or by using ARIA labels. All of these separate techniques could be described in one big rule. But this creates a large, and often difficult to maintain rule. To ensure rules are kept small and atomic, they SHOULD be put into a rule-group instead. +In accessibility testing, there are often multiple ways to solve the same problem. For instance, header cells in HTML tables can be indicated through the `scope` attribute, by using the `headers` attribute, or by using ARIA labels. All of these separate techniques could be described in one big rule. But this creates a large, and often difficult to maintain rule. To ensure rules are kept small and atomic, they SHOULD be put into a rule group instead. -To meet the accessibility requirement, only one rule in a rule group has to pass. For our table example, one could write three separate rules, one for scope, one for headers+id and one ARIA labels. If a table meets any of these rules, it automatically passes the group. The failed results of the other rules can be ignored. +To meet the accessibility requirement, only one rule in a rule group has to pass. For our table example, one could write three separate rules, one for `scope`, one for `headers` + `id` and one for ARIA labels. If a table meets any of these rules, it automatically passes the group. The failed results of the other rules can be ignored.

    Editor note - The ACT Task Force is looking for feedback about the use of Rule groups. We are considering whether a group should be allowed to have a single rule. Though it adds some complexity, it minimizes change if rules are added in the future. Additionally, we are considering allowing a group to require more than one pass, before the group passes. As an example, this may be particularly useful for WCAG 2.0 Success Criterion 2.4.5 Multiple ways. For details, see [Github issue #161](https://github.com/w3c/wcag-act/issues/161).

    -A *test target* will pass a rule group if it passes at least one of the applicable rules within that group. Likewise, a *test target* will fail the rule group, if it does not pass any of the applicable rules in the group. In the example of HTML Tables, passing the table scope rule, and failing the ARIA label and headers+id rule, would mean the *test target* passed this group of rules. +A [test target](#output-test-target) will pass a rule group if it passes at least one of the applicable rules within that group. Likewise, a test target will fail the rule group, if it does not pass any of the applicable rules in the group. In the example of HTML Tables, passing the table `scope` rule, and failing the ARIA label and `headers` + `id` rule, would mean the test target passed this group of rules. -Note that rules in a group MAY have different applicability. Because of this, not every element applicable within the group is tested by every rule. Rules MAY also be disabled during a test run due to accessibility support concerns. See [Accessibility support](#acc-support) for details. +Note that rules in a group MAY have different [applicability](#test-applicability). Because of this, not every element applicable within the group is tested by every rule. Rules MAY also be disabled during a test run due to accessibility support concerns. See [Accessibility Support](#acc-support) for details. ACT Data Format (Output Data) {#output} @@ -192,7 +192,7 @@ ACT Data Format (Output Data) {#output} With ACT Rules, it is important that data coming from different sources can be compared. By having a shared vocabulary, accessibility data that is produced by different auditors can be compared and, where necessary, aggregated. Therefore, every ACT Rule MUST express the output in a format that has all of the features described in the ACT Data Format. -Rules are tested in two steps. Firstly, the applicability is used to find a list of *Test Targets* (elements, tags or other "components") within the web page or other test subject. Then each *test target* is tested to see if all of the expectations are true. This will give the *outcome* for each *test target*. For contextual information, the output data must also include *test subject* and the *rule identifier*. +Rules are tested in two steps. Firstly, the applicability is used to find a list of Test Targets (elements, tags or other "components") within the web page or other test subject. Then each test target is tested to see if all of the [expectations](#expectations) are true. This will give the outcome for each test target. For contextual information, the output data must also include *test subject* and the *rule identifier*.

    Editor note - The ACT Task Force is investigating to what extent a shared data format may From 3dbf2101aca09fca62bf3a990e67c03a97d4e483 Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 7 May 2018 09:10:26 -0400 Subject: [PATCH 15/34] Update internal reference links --- act-rules-format.bs | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 2c863489..5e162022 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -192,7 +192,7 @@ ACT Data Format (Output Data) {#output} With ACT Rules, it is important that data coming from different sources can be compared. By having a shared vocabulary, accessibility data that is produced by different auditors can be compared and, where necessary, aggregated. Therefore, every ACT Rule MUST express the output in a format that has all of the features described in the ACT Data Format. -Rules are tested in two steps. Firstly, the applicability is used to find a list of Test Targets (elements, tags or other "components") within the web page or other test subject. Then each test target is tested to see if all of the [expectations](#expectations) are true. This will give the outcome for each test target. For contextual information, the output data must also include *test subject* and the *rule identifier*. +Rules are tested in two steps. Firstly, the applicability is used to find a list of [Test Targets](#output-test-target) (elements, tags or other "components") within the web page or other [test subject](#output-test-subject). Then each test target is tested to see if all of the [expectations](#expectations) are true. This will give the outcome for each test target. For contextual information, the output data must also include test subject and the [rule identifier](#unique-identifier).

    Editor note - The ACT Task Force is investigating to what extent a shared data format may @@ -202,10 +202,10 @@ Rules are tested in two steps. Firstly, the applicability is used to find a list This will mean that every time a rule is executed on a page, it will return a set with zero or more results, each of which MUST have at least the following properties: -- Rule Identifier (test) -- Test Subject (Web page) -- Test Target (pointer) -- Outcome (`Passed`, `Failed`, or `Inapplicable`) +- [Rule Identifier](#unique-identifier) (test) +- [Test Subject](#output-test-subject) (Web page) +- [Test Target](#output-test-target) (pointer) +- [Outcome](#output-outcome) (`Passed`, `Failed`, or `Inapplicable`)

    Output data using EARL and JSON-LD @@ -234,7 +234,7 @@ When a single URL can be used to reference the web page, or other test subject, Test Target {#output-test-target} ------------------------------ -When representing the *test target* in the output data, it is often impractical or impossible to serialize the *test target* as a whole. Instead of this, a pointer can be used to indicate where the *test target* exists within the web page or other *test subject*. There are a variety of pointer methods available, such as those defined in [Pointer Methods in RDF 1.0](https://www.w3.org/TR/Pointers-in-RDF/). +When representing the test target in the output data, it is often impractical or impossible to serialize the test target as a whole. Instead of this, a pointer can be used to indicate where the *test target* exists within the web page or other *test subject*. There are a variety of pointer methods available, such as those defined in [Pointer Methods in RDF 1.0](https://www.w3.org/TR/Pointers-in-RDF/). The pointer method used in the output data of an ACT Rule MUST include the pointer method used in [Implementation Validation](#quality-implement). @@ -244,9 +244,9 @@ Outcome {#output-outcome} The procedure of a rule MUST always return one of the following outcomes: -- **Passed**: All *expectations* for the Test Target were true -- **Failed**: One or more *expectations* for the Test Target was false -- **Inapplicable**: There were no Test Targets in the Test Subject +- **Passed**: All [expectations](#expectations) for the [Test Target](#output-test-target) were true +- **Failed**: One or more expectations for the Test Target was false +- **Inapplicable**: There were no Test Targets in the [Test Subject](#output-test-subject)
    While *inapplicable* is a valid result for ACT Rules, it may not be a valid result for all accessibility requirements. Notably the success criteria of WCAG 2.0 and WCAG 2.1 can only be evaluated to true (passed) or false (failed). This translation of results is part of [output aggregation](#output-aggregation) @@ -255,10 +255,10 @@ The procedure of a rule MUST always return one of the following outcomes: Ensure Comparable Results {#output-comparable} ------------------------- -In addition to the Test Target and the Outcome, ACT Rule output data MUST include the following contextual information: +In addition to the [Test Target](#output-test-target) and the [Outcome](#output-outcome), ACT Rule output data MUST include the following contextual information: -- the Web page, file or other test subject the rule was applied to and -- an identifier of the rule itself. +- the Web page, file or other [test subject](#output-test-subject) the rule was applied to and +- an [identifier](#unique-identifier) of the rule itself. Rule Quality Assurance {#quality} @@ -267,7 +267,7 @@ Rule Quality Assurance {#quality} Implementation Validation {#quality-implement} ---------------------------------------------- -Implementation tests are tests for accessibility test tools. These tests enable the developers and users of ATTs to validate the implementation of an ACT Rule. An ACT rule MUST have implementation tests for the *applicability*, as well as for each *expectation* in the rule. +Implementation tests are tests for accessibility test tools. These tests enable the developers and users of ATTs to validate the implementation of an ACT Rule. An ACT rule MUST have implementation tests for the [applicability](#test-applicability), as well as for each [expectation](#expectations) in the rule. An implementation test consists of two parts: a piece of input data and an expected result. When applying the test, the piece of input data, for instance an HTML code snippet, is evaluated by following the rule's test procedure. The result is then compared to the expected result of the test. The expected result consists of a list of [pointers](#output-test-target) and the expected [outcome](#output-outcome) (Passed, Failed, Inapplicable) of the evaluation. @@ -281,23 +281,23 @@ This makes it important to be able to regularly test if the rule has the accurac The accuracy of a rule is the average between the false positives and false negatives, which are in turn calculated as follows: -- **False positives**: This is the percentage of *test targets*, that were failed by the rule, but were not failed by an accessibility expert. +- **False positives**: This is the percentage of [test targets](#output-test-target), that were failed by the rule, but were not failed by an accessibility expert. -- **False negatives**: This is the percentage of *test targets*, that were passed by the rule, but were failed by an accessibility expert. +- **False negatives**: This is the percentage of test targets, that were passed by the rule, but were failed by an accessibility expert. -There are several ways this can be done. For instance, accessibility test tools can implement a feature which lets users indicate that a result is in error, or pages that for which accessibility results are known, can be tested using ATT, and the results are compared. To compare results from ACT Rules to those of expert evaluations, data aggregation may be necessary. +There are several ways this can be done. For instance, accessibility test tools can implement a feature which lets users indicate that a result is in error, or pages that for which accessibility results are known, can be tested using ATT, and the results are compared. To compare results from ACT Rules to those of expert evaluations, [data aggregation](#output-aggregation) may be necessary. Rule Aggregation {#output-aggregation} -------------------------------------- -As described in section [[#output]] a rule will return a list of results, each of which contain 1) the Rule ID, 2) the test subject, 3) the *test target*, and 4) an outcome (Passed, Failed, Inapplicable). Data expressed this way has a great deal of detail, as it gives multiple pass / fail results for each rule. +As described in section [[#output]] a rule will return a list of results, each of which contain 1) the [Rule ID](#unique-identifier), 2) the test subject(#output-test-subject), 3) the [test target](#output-test-target), and 4) an [outcome](#output-outcome) (Passed, Failed, Inapplicable). Data expressed this way has a great deal of detail, as it gives multiple pass / fail results for each rule. Most expert evaluations do not report results at this level of detail. Often reports are limited to giving a single outcome (Passed, Failed, Inapplicable) per page, for each success criteria (or other accessibility requirement). To compare the data, results from rules should be combined, so that they are at the same level. When all rules pass, that does not mean that all accessibility requirements are met. Only if the rules can test 100% of what should be tested, can this claim be made. Otherwise the outcome for a criterion is inconclusive. -**Example:** An expert evaluates a success criterion to fail on a specific page. When testing that page using ACT Rules, there are two rules that map to this criterion. The first rule returns no results. The second rule finds 2 *test targets* that pass, and a 3rd *test target* that fails. +**Example:** An expert evaluates a success criterion to fail on a specific page. When testing that page using ACT Rules, there are two rules that map to this criterion. The first rule returns no results. The second rule finds 2 test targets that pass, and a 3rd test target that fails. In this example, the first rule is inapplicable (0 results), and the second rule has failed (1 fail, 2 pass). Combining this inapplicable and fail, means the success criterion has failed. @@ -309,11 +309,11 @@ Update Management {#quality-updates} ### Change Log ### {#quality-updates-changes} -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, rather than changes in the content itself. All changes to an ACT Rule that can change the outcome of a test MUST be recorded in a change log. The change log can either be part of the rule document itself or be referenced from it. +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, rather than changes in the content itself. All changes to an ACT Rule that can change the [outcome](#output-outcome) of a test MUST be recorded in a change log. The change log can either be part of the rule document itself or be referenced from it. Each new release of an ACT Rule MUST be identifiable with either a date or a version number. Additionally, a reference to the previous version of that rule MUST be available. For extensive changes, a new rule SHOULD be created and the old rule SHOULD be deprecated. -An example of when a new rule should be created is when a rule that tests for the use of a blink element changes to instead look for any animated style changes. This potentially adds several new failures that were previously out of scope. Using that same rule as an example, adding an exception to allow blink elements positioned off screen should be done by updating the existing rule. +**Example:** An example of when a new rule should be created is when a rule that tests for the use of a `blink` element changes to instead look for any animated style changes. This potentially adds several new failures that were previously out of scope. Using that same rule as an example, adding an exception to allow `blink` elements positioned off screen should be done by updating the existing rule. ### Issues List ### {#quality-updates-issues} From 532aef2bd522d374dbbecda0ef5f3d473a0b19fb Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 7 May 2018 10:01:47 -0400 Subject: [PATCH 16/34] Updating normative and informative references Add direct link for first reference. Using ARIA 1.1 spec as inspiration --- act-rules-format.bs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 5e162022..0f505e7c 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -15,7 +15,7 @@ Markup Shorthands: markdown yes Introduction {#intro} ===================== -There are currently many products available which aid their users in testing web content for conformance to accessibility standards such as the Web Content Accessibility Guidelines (WCAG) 2.0 [[WCAG20]]. As the web develops and grows in both size and complexity, these tools are essential for managing the accessibility of resources available on the web. +There are currently many products available which aid their users in testing web content for conformance to accessibility standards such as the [Web Content Accessibility Guidelines (WCAG) 2.0](https://www.w3.org/TR/WCAG20/) [[WCAG20]]. As the web develops and grows in both size and complexity, these tools are essential for managing the accessibility of resources available on the web. This format is intended to enable a consistent interpretation of how to test for accessibility requirements to avoid conflicting results of accessibility tests. It is intended to be used to describe both manual accessibility tests as well as automated tests performed by accessibility test tools (ATTs). @@ -25,7 +25,7 @@ Describing how to test certain accessibility requirements will result in accessi Scope {#scope} ============== -The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as Hypertext Markup Language (HTML) [[HTML5]], Cascading Style Sheets (CSS) [[CSS21]], Accessible Rich Internet Applications (WAI-ARIA) [[wai-aria-1.1]], Scaleable Vector Graphics (SVG) [[SVG11]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. +The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as [Hypertext Markup Language](https://www.w3.org/TR/html5/) (HTML) [[HTML5]], [Cascading Style Sheets](https://www.w3.org/TR/CSS2/) (CSS) [[CSS21]], [Accessible Rich Internet Applications](https://www.w3.org/TR/wai-aria-1.1/) (WAI-ARIA) [[wai-aria-1.1]], [Scaleable Vector Graphics](https://www.w3.org/TR/SVG2/) (SVG) [[SVG2]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. For instance, the ACT Rules Format can be used to describe ACT Rules dedicated to testing the accessibility requirements defined in WCAG, which are specifically designed for web content. From 479c650dd945494402f601f733c6e0603aaa062a Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 7 May 2018 11:27:01 -0400 Subject: [PATCH 17/34] Update informative reference links accordingly Left off at Test Target definition. --- act-rules-format.bs | 46 ++++++++++++++++++++++----------------------- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 0f505e7c..44db9cba 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -25,11 +25,11 @@ Describing how to test certain accessibility requirements will result in accessi Scope {#scope} ============== -The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as [Hypertext Markup Language](https://www.w3.org/TR/html5/) (HTML) [[HTML5]], [Cascading Style Sheets](https://www.w3.org/TR/CSS2/) (CSS) [[CSS21]], [Accessible Rich Internet Applications](https://www.w3.org/TR/wai-aria-1.1/) (WAI-ARIA) [[wai-aria-1.1]], [Scaleable Vector Graphics](https://www.w3.org/TR/SVG2/) (SVG) [[SVG2]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. +The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as [Hypertext Markup Language](https://www.w3.org/TR/html5/) [[HTML5]], [Cascading Style Sheets](https://www.w3.org/TR/CSS2/) [[CSS21]], [Accessible Rich Internet Applications](https://www.w3.org/TR/wai-aria-1.1/) [[wai-aria-1.1]], [Scaleable Vector Graphics](https://www.w3.org/TR/SVG2/) [[SVG2]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. For instance, the ACT Rules Format can be used to describe ACT Rules dedicated to testing the accessibility requirements defined in 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 [[UAAG20]]. However, the ACT Rules Format would not necessarily be suitable to describe tests for the conformance of a non-web-based user agent. +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/TR/UAAG20/) [[UAAG20]]. However, the ACT Rules Format would not necessarily be suitable to describe tests for the conformance of a non-web-based user agent. ACT Rule Structure {#structure} @@ -64,7 +64,7 @@ An ACT Rule MUST have a description that is in plain language and provides a bri Accessibility Requirements {#structure-accessibility-requirements} ------------------------------------------------------------------- -An ACT Rule MUST identify the accessibility requirements to which the rule maps. For example, [WCAG 2.0 Success Criterion 1.1.1](https://www.w3.org/TR/2008/REC-WCAG20-20081211/#text-equiv-all). An ACT Rule is a complete or partial test for one or more accessibility requirements. +An ACT Rule MUST identify the accessibility requirements to which the rule maps. For example, [WCAG 2.0 Success Criterion 1.1.1](https://www.w3.org/TR/2008/REC-WCAG20-20081211/#text-equiv-all)[[WCAG20]]. An ACT Rule is a complete or partial test for one or more accessibility requirements. Outcomes from an ACT Rule MUST be consistent with the accessibility requirement, e.g. a rule only returns the outcome Fail when the content fails the accessibility requirement. This means that the rule maps to the accessibility requirement, as opposed to it merely being related to the requirement, thematically or otherwise. @@ -74,7 +74,7 @@ The actual definition of specific accessibility requirements is beyond the scope Limitations, Assumptions or Exceptions {#structure-limitations-assumptions-exceptions} ------------------------------------------------------------------- -An ACT Rule MUST list any limitations, assumptions or any exceptions for the test, the test environment, technologies being used or the subject being tested. For example, a rule for [WCAG 2.0 Success Criterion 1.4.1: Use of Color](https://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast-without-color) has to make an assumption that CSS is used to make a link visually evident - typically by using CSS background, border, color, font, or text-decoration properties. +An ACT Rule MUST list any limitations, assumptions or any exceptions for the test, the test environment, technologies being used or the subject being tested. For example, a rule for [WCAG 2.0 Success Criterion 1.4.1: Use of Color](https://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast-without-color) [[WCAG20]] has to make an assumption that CSS is used to make a link visually evident - typically by using CSS background, border, color, font, or text-decoration properties. Accessibility Support {#acc-support} @@ -82,7 +82,7 @@ Accessibility Support {#acc-support} ACT Rules are designed to test accessible uses of a web technology. However, not every part of a web technology is implemented in all assistive technologies a website may need to support. The concept of [accessibility supported](https://www.w3.org/TR/WCAG20/#accessibility-supporteddef) use of a Web technology is defined in [[WCAG20]]. Because of this, ACT Rules are not necessarily applicable in all test scenarios. For instance, a web page that has to work in assistive technologies that have no WAI-ARIA support, wouldn’t be tested with an ACT Rule that relies on WAI-ARIA support, since this could lead to false positive results. -Even within a [rules group][rule group](#grouping), certain individual rules are not always applicable. This leaves one fewer solution for passing that particular rule group. Because of this, ACT Rules have to be atomic, meaning an ACT Rule MUST NOT rely on other rules to be part of the same test scenario. +Even within a [rules group](#grouping), certain individual rules are not always applicable. This leaves one fewer solution for passing that particular rule group. Because of this, ACT Rules have to be atomic, meaning an ACT Rule MUST NOT rely on other rules to be part of the same test scenario. To support users of ACT Rules in properly defining their test scenarios, an ACT Rule SHOULD include a warning if there are significant accessibility support concerns known about a rule. @@ -90,9 +90,9 @@ To support users of ACT Rules in properly defining their test scenarios, an ACT Aspects Under Test {#input-aspects} =================================== -ACT Rules can operate on different aspects of the subject being tested. An aspect is a distinct part of the test subject itself or its underlying implementation. For example, rendering a web page to an end user involves multiple different technologies, some or all of which may be of interest to an ACT Rule. Some rules need to operate directly on the Hypertext Transfer Protocol (HTTP) [[http11]] messages exchanged between a server and a client, while others need to operate on the Document Object Model (DOM) [[DOM]] tree exposed by a web browser. Some rules may even need to operate on several aspects simultaneously such as both the HTTP messages and the DOM tree. +ACT Rules can operate on different aspects of the subject being tested. An aspect is a distinct part of the test subject itself or its underlying implementation. For example, rendering a web page to an end user involves multiple different technologies, some or all of which may be of interest to an ACT Rule. 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. Some rules may even need to operate on several aspects simultaneously such as both the HTTP messages [[http11]] and the DOM tree [[DOM]]. -An ACT Rule MUST include a description of all the aspects under test by the rule. Each aspect MUST be discrete with no overlap between the aspects. Some aspects are already well defined within the context of web content, such as HTTP messages, DOM tree, and CSS styling, and do not warrant a detailed description. Other aspects may not be well defined or even specific to web content. In these cases, an ACT Rule SHOULD include either a detailed description of the aspect in question or a reference to that description. +An ACT Rule MUST include a description of all the aspects under test by the rule. Each aspect MUST be discrete with no overlap between the aspects. Some aspects are already well defined within the context of web content, such as HTTP messages [[http11]], DOM [[DOM]] tree, and CSS styling [[CSS21]], and do not warrant a detailed description. Other aspects may not be well defined or even specific to web content. In these cases, an ACT Rule SHOULD include either a detailed description of the aspect in question or a reference to that description. Common Aspects {#input-aspects-common} @@ -100,31 +100,31 @@ Common Aspects {#input-aspects-common} ### HTTP Messages ### {#input-aspects-http} -The HTTP messages exchanged between a client and a server as part of requesting a web page may be of interest to ACT Rules. For example, analyzing HTTP messages to perform validation of HTTP headers or unparsed HTML and CSS. +The HTTP messages [[http11]] exchanged between a client and a server as part of requesting a web page may be of interest to ACT Rules. For example, analyzing HTTP messages to perform validation of HTTP headers or unparsed HTML [[HTML5]] and CSS [[CSS21]]. ### DOM Tree ### {#input-aspects-dom} -The DOM tree constructed from parsing HTML, and optionally executing DOM manipulating JavaScript, may be of interest to ACT Rules to test the structure of web pages. In the DOM tree, information about individual elements of a web page, and their relations, becomes available. +The DOM [[DOM]] tree constructed from parsing HTML [[HTML5]], and optionally executing DOM manipulating JavaScript, may be of interest to ACT Rules to test the structure of web pages. In the DOM tree, information about individual elements of a web page, and their relations, becomes available. -The means by which the DOM tree is constructed, be it by a web browser or not, is not of importance as long as the construction follows any applicable specifications that might exist, such as [[DOM]]. +The means by which the DOM tree is constructed, be it by a web browser or not, is not of importance as long as the construction follows any applicable specifications that might exist, such as the [Document Object Model](https://dom.spec.whatwg.org) [[DOM]]. ### CSS Styling ### {#input-aspects-css} -The computed CSS styling resulting from parsing CSS and applying it to the DOM may be of interest to ACT Rules that wish to test the web page as presented to the user. Through CSS styling, information about the position, the foreground and background colors, the visibility, and more, of elements becomes available. +The computed CSS [[CSS21]] styling resulting from parsing CSS and applying it to the DOM [[DOM]] may be of interest to ACT Rules that wish to test the web page as presented to the user. Through CSS styling, information about the position, the foreground and background colors, the visibility, and more, of elements becomes available. -The means by which the CSS styling is computed, be it by a web browser or not, is not of importance as long as the computation follows any applicable specifications that might exist, such as [[CSSOM]]. +The means by which the CSS styling is computed, be it by a web browser or not, is not of importance as long as the computation follows any applicable specifications that might exist, such as the [CSS Object Model](https://www.w3.org/TR/cssom/) [[CSSOM]]. ### Accessibility Tree ### {#input-aspects-accessibility} -The accessibility tree constructed from extracting information from both the DOM tree and the CSS styling may be of interest to ACT Rules. This can be used to test the web page as presented to assistive technologies such as screen readers. Through the accessibility tree, information about the semantic roles, accessible names and descriptions, and more, of elements becomes available. +The accessibility tree constructed from extracting information from both the DOM [[DOM]] tree and the CSS [[CSS21]] styling may be of interest to ACT Rules. This can be used to test the web page as presented to assistive technologies such as screen readers. Through the accessibility tree, information about the semantic roles, accessible names and descriptions, and more, of elements becomes available. -The means by which the accessibility tree is constructed, be it by a web browser or not, is not of importance as long as the construction follows any applicable specifications that might exist, such as [[CORE-AAM-1.1]]. +The means by which the accessibility tree is constructed, be it by a web browser or not, is not of importance as long as the construction follows any applicable specifications that might exist, such as the [Core Accessibility API Mappings 1.1](https://www.w3.org/TR/core-aam-1.1/) [[CORE-AAM-1.1]]. ### Language ### {#input-aspects-text} -Language, either written or spoken, contained in nodes of the DOM or accessibility trees may be of interest to ACT Rules that intend to test things like complexity or intention of the language. For example, an ACT Rule might test that paragraphs of text within the DOM tree do not exceed a certain readability score or that the text alternative of an image provides a sufficient description. +Language, either written or spoken, contained in nodes of the DOM [[DOM]] or accessibility trees may be of interest to ACT Rules that intend to test things like complexity or intention of the language. For example, an ACT Rule might test that paragraphs of text within the DOM tree do not exceed a certain readability score or that the text alternative of an image provides a sufficient description. -The means by which the language is assessed, whether by a person or a machine, is not of importance as long as the assessment meets the criteria defined in [[wcag2-tech-req#humantestable]]. +The means by which the language is assessed, whether by a person or a machine, is not of importance as long as the assessment meets the criteria defined in [[wcag2-tech-req#humantestable]] [[WCAG20]]. ACT Test Definition {#test-def} @@ -133,16 +133,16 @@ ACT Test Definition {#test-def} Applicability {#test-applicability} ------------- -The applicability section is a required part of an ACT rule. It MUST contain a precise description of the parts of the [test subject](#output-test-subject) to which the rule applies. For example, specific nodes in the DOM tree, or tags that are incorrectly closed in an HTML document. These are known as the [test targets](#output-test-target). The applicability MUST only use information provided through [test aspects](#input-aspects) of the same rule. No other information should be used in the applicability. +The applicability section is a required part of an ACT rule. It MUST contain a precise description of the parts of the [test subject](#output-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 [[HTML5]] document. These are known as the [test targets](#output-test-target). The applicability MUST only use information provided through [test aspects](#input-aspects) of the same rule. No other information should be used in the applicability. -Applicability MUST be described objectively, unambiguously and in plain language. When a formal syntax, such as a CSS selector [[css3-selectors]] or XPATH [[XPATH]], can be used, that (part of the) applicability MAY use that syntax in addition to the plain language description. While testing, if nothing within the test subject matches the applicability of the rule, the result is `inapplicable`. +Applicability MUST be described objectively, unambiguously and in plain language. When a formal syntax, such as a [CSS selector](https://www.w3.org/TR/selectors-3/) [[css3-selectors]] or [XML Path Language](https://www.w3.org/TR/xpath/) [[XPATH]], can be used, that (part of the) applicability MAY use that syntax in addition to the plain language description. While testing, if nothing within the test subject matches the applicability of the rule, the result is `inapplicable`. An objective description is one that can be resolved without uncertainty in a given technology. Examples of objective properties in HTML are element names, their computed role, the spacing 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. Is this talking about the tag name, the accessibility role, it's purpose in the web page? The latter of which is almost impossible to define with objectivity. When used in applicability, these concepts MUST have an objective definition. This definition can be part of a larger glossary shared between rules.

    A rule for labels of HTML `input` elements may have the following [expectations](#expectations):

      -
    1. The test target has an accessible name (as described in [Accessible Name and Description: Computation and API Mappings 1.1](https://www.w3.org/TR/accname-aam-1.1/#mapping_additional_nd_te)).
      2. +
    2. The test target has an accessible name (as described in [Accessible Name and Description: Computation and API Mappings 1.1](https://www.w3.org/TR/accname-aam-1.1/#mapping_additional_nd_te)) [[accname-aam-1.1]].
    3. The accessible name describes the purpose of the test target.
    @@ -163,7 +163,7 @@ When all expectations are true for a test target, the test target `passed` the r

    A rule for labels of HTML `input` elements may have the following expectations:

      -
    1. The test target has an accessible name (as described in [Accessible Name and Description: Computation and API Mappings 1.1](https://www.w3.org/TR/accname-aam-1.1/#mapping_additional_nd_te)).
      2. +
    2. The test target has an accessible name (as described in [Accessible Name and Description: Computation and API Mappings 1.1](https://www.w3.org/TR/accname-aam-1.1/#mapping_additional_nd_te)). [[accname-aam-1.1]]
    3. The accessible name describes the purpose of the test target.
    @@ -173,7 +173,7 @@ An expectation MUST only use information available in the test aspects, and from Rule Grouping {#grouping} =================== -In accessibility testing, there are often multiple ways to solve the same problem. For instance, header cells in HTML tables can be indicated through the `scope` attribute, by using the `headers` attribute, or by using ARIA labels. All of these separate techniques could be described in one big rule. But this creates a large, and often difficult to maintain rule. To ensure rules are kept small and atomic, they SHOULD be put into a rule group instead. +In accessibility testing, there are often multiple ways to solve the same problem. For instance, header cells in HTML [[HTML5]] tables can be indicated through the `scope` attribute, by using the `headers` attribute, or by using ARIA [[WAI-ARIA-1.1]] labels. All of these separate techniques could be described in one big rule. But this creates a large, and often difficult to maintain rule. To ensure rules are kept small and atomic, they SHOULD be put into a rule group instead. To meet the accessibility requirement, only one rule in a rule group has to pass. For our table example, one could write three separate rules, one for `scope`, one for `headers` + `id` and one for ARIA labels. If a table meets any of these rules, it automatically passes the group. The failed results of the other rules can be ignored. @@ -208,7 +208,7 @@ This will mean that every time a rule is executed on a page, it will return a se - [Outcome](#output-outcome) (`Passed`, `Failed`, or `Inapplicable`)
    -Output data using EARL and JSON-LD +Output data using EARL and JSON-LD. (See [Evaluation and Report Language (EARL) 1.0](https://www.w3.org/TR/EARL10-Schema/) [[EARL10-Schema]] and [Java Script Object Notation (JSON)](https://www.json.org).) ```javascript { @@ -234,7 +234,7 @@ When a single URL can be used to reference the web page, or other test subject, Test Target {#output-test-target} ------------------------------ -When representing the test target in the output data, it is often impractical or impossible to serialize the test target as a whole. Instead of this, a pointer can be used to indicate where the *test target* exists within the web page or other *test subject*. There are a variety of pointer methods available, such as those defined in [Pointer Methods in RDF 1.0](https://www.w3.org/TR/Pointers-in-RDF/). +When representing the test target in the output data, it is often impractical or impossible to serialize the test target as a whole. Instead of this, a pointer can be used to indicate where the test target exists within the web page or other [test subject](#output-test-subject). There are a variety of pointer methods available, such as those defined in [Pointer Methods in RDF 1.0](https://www.w3.org/TR/Pointers-in-RDF/) [[Pointers-in-RDF]]. The pointer method used in the output data of an ACT Rule MUST include the pointer method used in [Implementation Validation](#quality-implement). From 92adf835ac1bed71fe854f4fe0acaceca8972946 Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 7 May 2018 13:32:17 -0400 Subject: [PATCH 18/34] Fix WAI-ARIA-1.1 alias --- act-rules-format.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 44db9cba..1d033482 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -25,7 +25,7 @@ Describing how to test certain accessibility requirements will result in accessi Scope {#scope} ============== -The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as [Hypertext Markup Language](https://www.w3.org/TR/html5/) [[HTML5]], [Cascading Style Sheets](https://www.w3.org/TR/CSS2/) [[CSS21]], [Accessible Rich Internet Applications](https://www.w3.org/TR/wai-aria-1.1/) [[wai-aria-1.1]], [Scaleable Vector Graphics](https://www.w3.org/TR/SVG2/) [[SVG2]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. +The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as [Hypertext Markup Language](https://www.w3.org/TR/html5/) [[HTML5]], [Cascading Style Sheets](https://www.w3.org/TR/CSS2/) [[CSS21]], [Accessible Rich Internet Applications](https://www.w3.org/TR/wai-aria-1.1/) [[WAI-ARIA-1.1]], [Scaleable Vector Graphics](https://www.w3.org/TR/SVG2/) [[SVG2]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. For instance, the ACT Rules Format can be used to describe ACT Rules dedicated to testing the accessibility requirements defined in WCAG, which are specifically designed for web content. From f372d42b658c6a25d987dbc5d66e1f688960b736 Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 7 May 2018 14:24:25 -0400 Subject: [PATCH 19/34] Fix links to ARIA and A11y Requirements --- act-rules-format.bs | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 1d033482..d2823659 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -17,7 +17,7 @@ Introduction {#intro} There are currently many products available which aid their users in testing web content for conformance to accessibility standards such as the [Web Content Accessibility Guidelines (WCAG) 2.0](https://www.w3.org/TR/WCAG20/) [[WCAG20]]. As the web develops and grows in both size and complexity, these tools are essential for managing the accessibility of resources available on the web. -This format is intended to enable a consistent interpretation of how to test for accessibility requirements to avoid conflicting results of accessibility tests. It is intended to be used to describe both manual accessibility tests as well as automated tests performed by accessibility test tools (ATTs). +This format is intended to enable a consistent interpretation of how to test for [accessibility requirements](#structure-accessibility-requirements) to avoid conflicting results of accessibility tests. It is intended to be used to describe both manual accessibility tests as well as automated tests performed by accessibility test tools (ATTs). Describing how to test certain accessibility requirements will result in accessibility tests that are transparent with test results that are reproducible. The Accessibility Conformance Testing (ACT) Rules Format defines the requirements for these test descriptions, known as Accessibility Conformance Testing Rules (ACT Rules). @@ -27,7 +27,7 @@ Scope {#scope} The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as [Hypertext Markup Language](https://www.w3.org/TR/html5/) [[HTML5]], [Cascading Style Sheets](https://www.w3.org/TR/CSS2/) [[CSS21]], [Accessible Rich Internet Applications](https://www.w3.org/TR/wai-aria-1.1/) [[WAI-ARIA-1.1]], [Scaleable Vector Graphics](https://www.w3.org/TR/SVG2/) [[SVG2]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. -For instance, the ACT Rules Format can be used to describe ACT Rules dedicated to testing the accessibility requirements defined in WCAG, which are specifically designed for web content. +For instance, the ACT Rules Format can be used to describe ACT Rules dedicated to testing the [accessibility requirements](#structure-accessibility-requirements) defined in 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/TR/UAAG20/) [[UAAG20]]. However, the ACT Rules Format would not necessarily be suitable to describe tests for the conformance of a non-web-based user agent. @@ -80,7 +80,7 @@ An ACT Rule MUST list any limitations, assumptions or any exceptions for the tes Accessibility Support {#acc-support} =========================== -ACT Rules are designed to test accessible uses of a web technology. However, not every part of a web technology is implemented in all assistive technologies a website may need to support. The concept of [accessibility supported](https://www.w3.org/TR/WCAG20/#accessibility-supporteddef) use of a Web technology is defined in [[WCAG20]]. Because of this, ACT Rules are not necessarily applicable in all test scenarios. For instance, a web page that has to work in assistive technologies that have no WAI-ARIA support, wouldn’t be tested with an ACT Rule that relies on WAI-ARIA support, since this could lead to false positive results. +ACT Rules are designed to test accessible uses of a web technology. However, not every part of a web technology is implemented in all assistive technologies a website may need to support. The concept of [accessibility supported](https://www.w3.org/TR/WCAG20/#accessibility-supporteddef) use of a Web technology is defined in [[WCAG20]]. Because of this, ACT Rules are not necessarily applicable in all test scenarios. For instance, a web page that has to work in assistive technologies that have no WAI-ARIA [[WAI-ARIA-1.1]] support, wouldn’t be tested with an ACT Rule that relies on WAI-ARIA support, since this could lead to false positive results. Even within a [rules group](#grouping), certain individual rules are not always applicable. This leaves one fewer solution for passing that particular rule group. Because of this, ACT Rules have to be atomic, meaning an ACT Rule MUST NOT rely on other rules to be part of the same test scenario. @@ -249,7 +249,7 @@ The procedure of a rule MUST always return one of the following outcomes: - **Inapplicable**: There were no Test Targets in the [Test Subject](#output-test-subject)
    - While *inapplicable* is a valid result for ACT Rules, it may not be a valid result for all accessibility requirements. Notably the success criteria of WCAG 2.0 and WCAG 2.1 can only be evaluated to true (passed) or false (failed). This translation of results is part of [output aggregation](#output-aggregation) + While *inapplicable* is a valid result for ACT Rules, it may not be a valid result for all [accessibility requirements](#structure-accessibility-requirements). Notably the success criteria of WCAG 2.0 and WCAG 2.1 can only be evaluated to true (passed) or false (failed). This translation of results is part of [output aggregation](#output-aggregation)
    Ensure Comparable Results {#output-comparable} @@ -295,7 +295,7 @@ As described in section [[#output]] a rule will return a list of results, each o Most expert evaluations do not report results at this level of detail. Often reports are limited to giving a single outcome (Passed, Failed, Inapplicable) per page, for each success criteria (or other accessibility requirement). To compare the data, results from rules should be combined, so that they are at the same level. -When all rules pass, that does not mean that all accessibility requirements are met. Only if the rules can test 100% of what should be tested, can this claim be made. Otherwise the outcome for a criterion is inconclusive. +When all rules pass, that does not mean that all [accessibility requirements](#structure-accessibility-requirements) are met. Only if the rules can test 100% of what should be tested, can this claim be made. Otherwise the outcome for a criterion is inconclusive. **Example:** An expert evaluates a success criterion to fail on a specific page. When testing that page using ACT Rules, there are two rules that map to this criterion. The first rule returns no results. The second rule finds 2 test targets that pass, and a 3rd test target that fails. From 4793a0bd8713338458e2b551c0451d1ff48b4e70 Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 7 May 2018 14:41:18 -0400 Subject: [PATCH 20/34] Removed some redundant links Redundant links for http11 and DOM removed. --- act-rules-format.bs | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index d2823659..d94b2529 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -64,7 +64,7 @@ An ACT Rule MUST have a description that is in plain language and provides a bri Accessibility Requirements {#structure-accessibility-requirements} ------------------------------------------------------------------- -An ACT Rule MUST identify the accessibility requirements to which the rule maps. For example, [WCAG 2.0 Success Criterion 1.1.1](https://www.w3.org/TR/2008/REC-WCAG20-20081211/#text-equiv-all)[[WCAG20]]. An ACT Rule is a complete or partial test for one or more accessibility requirements. +An ACT Rule MUST identify the accessibility requirements to which the rule maps. For example, [WCAG 2.0 Success Criterion 1.1.1](https://www.w3.org/TR/2008/REC-WCAG20-20081211/#text-equiv-all) [[WCAG20]]. An ACT Rule is a complete or partial test for one or more accessibility requirements. Outcomes from an ACT Rule MUST be consistent with the accessibility requirement, e.g. a rule only returns the outcome Fail when the content fails the accessibility requirement. This means that the rule maps to the accessibility requirement, as opposed to it merely being related to the requirement, thematically or otherwise. @@ -90,9 +90,9 @@ To support users of ACT Rules in properly defining their test scenarios, an ACT Aspects Under Test {#input-aspects} =================================== -ACT Rules can operate on different aspects of the subject being tested. An aspect is a distinct part of the test subject itself or its underlying implementation. For example, rendering a web page to an end user involves multiple different technologies, some or all of which may be of interest to an ACT Rule. 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. Some rules may even need to operate on several aspects simultaneously such as both the HTTP messages [[http11]] and the DOM tree [[DOM]]. +ACT Rules can operate on different aspects of the subject being tested. An aspect is a distinct part of the test subject itself or its underlying implementation. For example, rendering a web page to an end user involves multiple different technologies, some or all of which may be of interest to an ACT Rule. 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. Some rules may even need to operate on several aspects simultaneously such as both the HTTP messages and the DOM tree [[DOM]]. -An ACT Rule MUST include a description of all the aspects under test by the rule. Each aspect MUST be discrete with no overlap between the aspects. Some aspects are already well defined within the context of web content, such as HTTP messages [[http11]], DOM [[DOM]] tree, and CSS styling [[CSS21]], and do not warrant a detailed description. Other aspects may not be well defined or even specific to web content. In these cases, an ACT Rule SHOULD include either a detailed description of the aspect in question or a reference to that description. +An ACT Rule MUST include a description of all the aspects under test by the rule. Each aspect MUST be discrete with no overlap between the aspects. Some aspects are already well defined within the context of web content, such as HTTP messages, DOM tree, and CSS styling [[CSS21]], and do not warrant a detailed description. Other aspects may not be well defined or even specific to web content. In these cases, an ACT Rule SHOULD include either a detailed description of the aspect in question or a reference to that description. Common Aspects {#input-aspects-common} From 3ed1c9be7c6a19bc5242a0c176b30f85a64e8fd8 Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 7 May 2018 14:44:44 -0400 Subject: [PATCH 21/34] Removed redundant DOM link --- act-rules-format.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index d94b2529..f65221ff 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -90,7 +90,7 @@ To support users of ACT Rules in properly defining their test scenarios, an ACT Aspects Under Test {#input-aspects} =================================== -ACT Rules can operate on different aspects of the subject being tested. An aspect is a distinct part of the test subject itself or its underlying implementation. For example, rendering a web page to an end user involves multiple different technologies, some or all of which may be of interest to an ACT Rule. 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. Some rules may even need to operate on several aspects simultaneously such as both the HTTP messages and the DOM tree [[DOM]]. +ACT Rules can operate on different aspects of the subject being tested. An aspect is a distinct part of the test subject itself or its underlying implementation. For example, rendering a web page to an end user involves multiple different technologies, some or all of which may be of interest to an ACT Rule. 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. Some rules may even need to operate on several aspects simultaneously such as both the HTTP messages and the DOM tree. An ACT Rule MUST include a description of all the aspects under test by the rule. Each aspect MUST be discrete with no overlap between the aspects. Some aspects are already well defined within the context of web content, such as HTTP messages, DOM tree, and CSS styling [[CSS21]], and do not warrant a detailed description. Other aspects may not be well defined or even specific to web content. In these cases, an ACT Rule SHOULD include either a detailed description of the aspect in question or a reference to that description. From 31e5c0975ea71af180edee401d9d177a933396ec Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Wed, 9 May 2018 16:14:03 -0400 Subject: [PATCH 22/34] Changing link text from pointers Link goes to Test Target section but it's link text reads pointers. Changing to test targets. --- act-rules-format.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 24a82aae..deefaac6 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -269,7 +269,7 @@ Implementation Validation {#quality-implement} Implementation tests are tests for accessibility test tools. These tests enable the developers and users of ATTs to validate the implementation of an ACT Rule. An ACT rule MUST have implementation tests for the [applicability](#test-applicability), as well as for each [expectation](#expectations) in the rule. -An implementation test consists of two parts: a piece of input data and an expected result. When applying the test, the piece of input data, for instance an HTML code snippet, is evaluated by following the rule's test procedure. The result is then compared to the expected result of the test. The expected result consists of a list of [pointers](#output-test-target) and the expected [outcome](#output-outcome) (Passed, Failed, Inapplicable) of the evaluation. +An implementation test consists of two parts: a piece of input data and an expected result. When applying the test, the piece of input data, for instance an HTML code snippet, is evaluated by following the rule's test procedure. The result is then compared to the expected result of the test. The expected result consists of a list of [test targets](#output-test-target) and the expected [outcome](#output-outcome) (Passed, Failed, Inapplicable) of the evaluation. Accuracy Benchmarking {#quality-accuracy} From dfc36de2b47cd44cc7dc416e45ff20cfefb956a3 Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 14 May 2018 16:51:29 -0400 Subject: [PATCH 23/34] Removing version specific links Removed version specific links to informative and normative references WCAG 2.0, WAI-ARIA 1.1, SVG 2, CSS 2. Replaced with non-version specific links. --- act-rules-format.bs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index deefaac6..bca2f401 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -15,7 +15,7 @@ Markup Shorthands: markdown yes Introduction {#intro} ===================== -There are currently many tools available which aid their users in testing web content for conformance to accessibility standards such as the [Web Content Accessibility Guidelines (WCAG) 2.0](https://www.w3.org/TR/WCAG20/) [[WCAG20]]. As the web develops in both size and complexity, these tools are essential for managing the resources available on the web. +There are currently many tools available which aid their users in testing web content for conformance to accessibility standards such as the [Web Content Accessibility Guidelines (WCAG)](https://www.w3.org/TR/WCAG/) [[WCAG]]. As the web develops in both size and complexity, these tools are essential for managing the resources available on the web. This format is intended to enable a consistent interpretation of how to test for [accessibility requirements](#structure-accessibility-requirements) to avoid conflicting results of accessibility tests. It is intended to be used to describe both manual accessibility tests as well as automated tests performed by accessibility testing tools (ATTs). @@ -25,7 +25,7 @@ Describing how to test certain accessibility requirements will result in accessi Scope {#scope} ============== -The ACT Rules Format defined in this specification is focused on the description of rules applicable to content created using web technologies, such as [Hypertext Markup Language](https://www.w3.org/TR/html5/) [[HTML5]], [Cascading Style Sheets](https://www.w3.org/TR/CSS2/) [[CSS21]], [Accessible Rich Internet Applications](https://www.w3.org/TR/wai-aria-1.1/) [[WAI-ARIA-1.1]], [Scaleable Vector Graphics](https://www.w3.org/TR/SVG2/) [[SVG2]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. +The ACT Rules Format defined in this specification is focused on the description of rules applicable to 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]], [Accessible Rich Internet Applications](https://www.w3.org/TR/wai-aria/) [[WAI-ARIA]], [Scaleable Vector Graphics](https://www.w3.org/TR/SVG/) [[SVG]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. For instance, the ACT Rules Format can be used to describe ACT Rules dedicated to testing the [accessibility requirements](#structure-accessibility-requirements) defined in WCAG, which are specifically designed for web content. From cdb81c2ebcd451c5fb0d157b35865528db34cb46 Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 14 May 2018 16:59:45 -0400 Subject: [PATCH 24/34] CSS does not have a generic bibliography key/tag Keeping generic TR link, https://www.w3.org/TR/CSS/, but need specific preprocessor tag to add to reference. Using CSS 2. --- act-rules-format.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index bca2f401..f4486dd5 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -25,7 +25,7 @@ Describing how to test certain accessibility requirements will result in accessi Scope {#scope} ============== -The ACT Rules Format defined in this specification is focused on the description of rules applicable to 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]], [Accessible Rich Internet Applications](https://www.w3.org/TR/wai-aria/) [[WAI-ARIA]], [Scaleable Vector Graphics](https://www.w3.org/TR/SVG/) [[SVG]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. +The ACT Rules Format defined in this specification is focused on the description of rules applicable to 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/) [[CSS2]], [Accessible Rich Internet Applications](https://www.w3.org/TR/wai-aria/) [[WAI-ARIA]], [Scaleable Vector Graphics](https://www.w3.org/TR/SVG/) [[SVG]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. For instance, the ACT Rules Format can be used to describe ACT Rules dedicated to testing the [accessibility requirements](#structure-accessibility-requirements) defined in WCAG, which are specifically designed for web content. From 01164bfec65a29853b8d4a2a92454e2ca98a6ff3 Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 14 May 2018 17:04:10 -0400 Subject: [PATCH 25/34] SVG biblio reference is obsolete Reverting to SVG2 --- act-rules-format.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index f4486dd5..53d1d1ac 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -25,7 +25,7 @@ Describing how to test certain accessibility requirements will result in accessi Scope {#scope} ============== -The ACT Rules Format defined in this specification is focused on the description of rules applicable to 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/) [[CSS2]], [Accessible Rich Internet Applications](https://www.w3.org/TR/wai-aria/) [[WAI-ARIA]], [Scaleable Vector Graphics](https://www.w3.org/TR/SVG/) [[SVG]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. +The ACT Rules Format defined in this specification is focused on the description of rules applicable to 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/) [[CSS2]], [Accessible Rich Internet Applications](https://www.w3.org/TR/wai-aria/) [[WAI-ARIA]], [Scaleable Vector Graphics](https://www.w3.org/TR/SVG/) [[SVG2]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. For instance, the ACT Rules Format can be used to describe ACT Rules dedicated to testing the [accessibility requirements](#structure-accessibility-requirements) defined in WCAG, which are specifically designed for web content. From 6cc870e8dcc2d3905ef4ff73cac11275ec196fc0 Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 14 May 2018 17:10:30 -0400 Subject: [PATCH 26/34] Reverting CSS biblio reference to CSS2 Also remove version from HTML and UAAG and ARIA references. --- act-rules-format.bs | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 53d1d1ac..3bb62b10 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -29,7 +29,7 @@ The ACT Rules Format defined in this specification is focused on the description For instance, the ACT Rules Format can be used to describe ACT Rules dedicated to testing the [accessibility requirements](#structure-accessibility-requirements) defined in 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/TR/UAAG20/) [[UAAG20]]. However, the ACT Rules Format would not necessarily be suitable to describe tests for the conformance of a non-web-based user agent. +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/TR/UAAG/) [[UAAG]]. However, the ACT Rules Format would not necessarily be suitable to describe tests for the conformance of a non-web-based user agent. ACT Rule Structure {#structure} @@ -92,7 +92,7 @@ Aspects Under Test {#input-aspects} ACT Rules can operate on different aspects of the subject being tested. An aspect is a distinct part of the test subject itself or its underlying implementation. For example, rendering a web page to an end user involves multiple different technologies, some or all of which may be of interest to an ACT Rule. 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. Some rules may even need to operate on several aspects simultaneously such as both the HTTP messages and the DOM tree. -An ACT Rule MUST include a description of all the aspects under test by the rule. Each aspect MUST be discrete with no overlap between the aspects. Some aspects are already well defined within the context of web content, such as HTTP messages, DOM tree, and CSS styling [[CSS21]], and do not warrant a detailed description. Other aspects may not be well defined or even specific to web content. In these cases, an ACT Rule SHOULD include either a detailed description of the aspect in question or a reference to that description. +An ACT Rule MUST include a description of all the aspects under test by the rule. Each aspect MUST be discrete with no overlap between the aspects. Some aspects are already well defined within the context of web content, such as HTTP messages, DOM tree, and CSS styling [[CSS2]], and do not warrant a detailed description. Other aspects may not be well defined or even specific to web content. In these cases, an ACT Rule SHOULD include either a detailed description of the aspect in question or a reference to that description. Common Aspects {#input-aspects-common} @@ -100,23 +100,23 @@ Common Aspects {#input-aspects-common} ### HTTP Messages ### {#input-aspects-http} -The HTTP messages [[http11]] exchanged between a client and a server as part of requesting a web page may be of interest to ACT Rules. For example, analyzing HTTP messages to perform validation of HTTP headers or unparsed HTML [[HTML5]] and CSS [[CSS21]]. +The HTTP messages [[http11]] exchanged between a client and a server as part of requesting a web page may be of interest to ACT Rules. For example, analyzing HTTP messages to perform validation of HTTP headers or unparsed HTML [[HTML]] and CSS [[CSS2]]. ### DOM Tree ### {#input-aspects-dom} -The DOM [[DOM]] tree constructed from parsing HTML [[HTML5]], and optionally executing DOM manipulating JavaScript, may be of interest to ACT Rules to test the structure of web pages. In the DOM tree, information about individual elements of a web page, and their relations, becomes available. +The DOM [[DOM]] tree constructed from parsing HTML [[HTML]], and optionally executing DOM manipulating JavaScript, may be of interest to ACT Rules to test the structure of web pages. In the DOM tree, information about individual elements of a web page, and their relations, becomes available. The means by which the DOM tree is constructed, be it by a web browser or not, is not of importance as long as the construction follows any applicable specifications that might exist, such as the [Document Object Model](https://dom.spec.whatwg.org) [[DOM]]. ### CSS Styling ### {#input-aspects-css} -The computed CSS [[CSS21]] styling resulting from parsing CSS and applying it to the DOM [[DOM]] may be of interest to ACT Rules that wish to test the web page as presented to the user. Through CSS styling, information about the position, the foreground and background colors, the visibility, and more, of elements becomes available. +The computed CSS [[CSS2]] styling resulting from parsing CSS and applying it to the DOM [[DOM]] may be of interest to ACT Rules that wish to test the web page as presented to the user. Through CSS styling, information about the position, the foreground and background colors, the visibility, and more, of elements becomes available. The means by which the CSS styling is computed, be it by a web browser or not, is not of importance as long as the computation follows any applicable specifications that might exist, such as the [CSS Object Model](https://www.w3.org/TR/cssom/) [[CSSOM]]. ### Accessibility Tree ### {#input-aspects-accessibility} -The accessibility tree constructed from extracting information from both the DOM [[DOM]] tree and the CSS [[CSS21]] styling may be of interest to ACT Rules. This can be used to test the web page as presented to assistive technologies such as screen readers. Through the accessibility tree, information about the semantic roles, accessible names and descriptions, and more, of elements becomes available. +The accessibility tree constructed from extracting information from both the DOM [[DOM]] tree and the CSS [[CSS2]] styling may be of interest to ACT Rules. This can be used to test the web page as presented to assistive technologies such as screen readers. Through the accessibility tree, information about the semantic roles, accessible names and descriptions, and more, of elements becomes available. The means by which the accessibility tree is constructed, be it by a web browser or not, is not of importance as long as the construction follows any applicable specifications that might exist, such as the [Core Accessibility API Mappings 1.1](https://www.w3.org/TR/core-aam-1.1/) [[CORE-AAM-1.1]]. @@ -133,7 +133,7 @@ ACT Test Definition {#test-def} Applicability {#test-applicability} ------------- -The applicability section is a required part of an ACT rule. It MUST contain a precise description of the parts of the [test subject](#output-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 [[HTML5]] document. These are known as the [test targets](#output-test-target). The applicability MUST only use information provided through [test aspects](#input-aspects) of the same rule. No other information should be used in the applicability. +The applicability section is a required part of an ACT rule. It MUST contain a precise description of the parts of the [test subject](#output-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](#output-test-target). The applicability MUST only use information provided through [test aspects](#input-aspects) of the same rule. No other information should be used in the applicability. Applicability MUST be described objectively, unambiguously and in plain language. When a formal syntax, such as a [CSS selector](https://www.w3.org/TR/selectors-3/) [[css3-selectors]] or [XML Path Language](https://www.w3.org/TR/xpath/) [[XPATH]], can be used, that (part of the) applicability MAY use that syntax in addition to the plain language description. While testing, if nothing within the test subject matches the applicability of the rule, the result is `inapplicable`. @@ -173,7 +173,7 @@ An expectation MUST only use information available in the test aspects, and from Rule Grouping {#grouping} =================== -In accessibility testing, there are often multiple ways to solve the same problem. For instance, header cells in HTML [[HTML5]] tables can be indicated through the `scope` attribute, by using the `headers` attribute, or by using ARIA [[WAI-ARIA-1.1]] labels. All of these separate techniques could be described in one big rule. But this creates a large, and often difficult to maintain rule. To ensure rules are kept small and atomic, they SHOULD be put into a rule group instead. +In accessibility testing, there are often multiple ways to solve the same problem. For instance, header cells in HTML [[HTML]] tables can be indicated through the `scope` attribute, by using the `headers` attribute, or by using ARIA [[WAI-ARIA]] labels. All of these separate techniques could be described in one big rule. But this creates a large, and often difficult to maintain rule. To ensure rules are kept small and atomic, they SHOULD be put into a rule group instead. To meet the accessibility requirement, only one rule in a rule group has to pass. For our table example, one could write three separate rules, one for `scope`, one for `headers` + `id` and one for ARIA labels. If a table meets any of these rules, it automatically passes the group. The failed results of the other rules can be ignored. From 1371cd89b04969743b6e8cafca40d6eec61ddf9b Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 14 May 2018 17:16:46 -0400 Subject: [PATCH 27/34] Need specific version of UAAG biblio referenc Using UAAG20 --- act-rules-format.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 3bb62b10..1ced668c 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -29,7 +29,7 @@ The ACT Rules Format defined in this specification is focused on the description For instance, the ACT Rules Format can be used to describe ACT Rules dedicated to testing the [accessibility requirements](#structure-accessibility-requirements) defined in 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/TR/UAAG/) [[UAAG]]. However, the ACT Rules Format would not necessarily be suitable to describe tests for the conformance of a non-web-based user agent. +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/TR/UAAG/) [[UAAG20]]. However, the ACT Rules Format would not necessarily be suitable to describe tests for the conformance of a non-web-based user agent. ACT Rule Structure {#structure} From 79d1bac4e68ed0a17001528c85baa4bfc570bc26 Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 14 May 2018 17:27:20 -0400 Subject: [PATCH 28/34] Per Shadi's recommendation going to workgroup page Since generic TR link does not go to latest UAAG, using link working group home page instead. --- act-rules-format.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 1ced668c..90141427 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -29,7 +29,7 @@ The ACT Rules Format defined in this specification is focused on the description For instance, the ACT Rules Format can be used to describe ACT Rules dedicated to testing the [accessibility requirements](#structure-accessibility-requirements) defined in 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/TR/UAAG/) [[UAAG20]]. However, the ACT Rules Format would not necessarily be suitable to describe tests for the conformance of a non-web-based user agent. +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/intro/uaag) [[UAAG20]]. However, the ACT Rules Format would not necessarily be suitable to describe tests for the conformance of a non-web-based user agent. ACT Rule Structure {#structure} From fd2a270ec84ab4fe5f547f6157a83690c083ef30 Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 14 May 2018 17:32:00 -0400 Subject: [PATCH 29/34] Updating Earl link to go to WG home Per Shadi's recommendation going to https://www.w3.org/WAI/intro/earl --- act-rules-format.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 90141427..094ea45d 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -208,7 +208,7 @@ This will mean that every time a rule is executed on a page, it will return a se - [Outcome](#output-outcome) (`Passed`, `Failed`, or `Inapplicable`)
    -Output data using EARL and JSON-LD. (See [Evaluation and Report Language (EARL) 1.0](https://www.w3.org/TR/EARL10-Schema/) [[EARL10-Schema]] and [Java Script Object Notation (JSON)](https://www.json.org).) +Output data using EARL and JSON-LD. (See [Evaluation and Report Language](https://www.w3.org/WAI/intro/earl) [[EARL]] and [Java Script Object Notation (JSON)](https://www.json.org).) ```javascript { From 2a595c9f675577b4ed6e3c951f4f41ca507b2319 Mon Sep 17 00:00:00 2001 From: "Maureen (Moe) Kraft" Date: Mon, 14 May 2018 17:34:06 -0400 Subject: [PATCH 30/34] Earl biblio reference needs version Reverting to EARL10-Schema --- act-rules-format.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 094ea45d..8d225228 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -208,7 +208,7 @@ This will mean that every time a rule is executed on a page, it will return a se - [Outcome](#output-outcome) (`Passed`, `Failed`, or `Inapplicable`)
    -Output data using EARL and JSON-LD. (See [Evaluation and Report Language](https://www.w3.org/WAI/intro/earl) [[EARL]] and [Java Script Object Notation (JSON)](https://www.json.org).) +Output data using EARL and JSON-LD. (See [Evaluation and Report Language](https://www.w3.org/WAI/intro/earl) [[EARL10-Schema]] and [Java Script Object Notation (JSON)](https://www.json.org).) ```javascript { From 7b50676e4bee65d29c4bfc8be6576f23b8a89b97 Mon Sep 17 00:00:00 2001 From: Moe Kraft Date: Fri, 1 Jun 2018 18:33:51 -0400 Subject: [PATCH 31/34] Change WAI links to overview pages Updated WAI links to point to overview pages per ACT TF review during 5/24 & 5/31 meetings --- act-rules-format.bs | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 8d225228..031f6957 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -15,7 +15,7 @@ Markup Shorthands: markdown yes Introduction {#intro} ===================== -There are currently many tools available which aid their users in testing web content for conformance to accessibility standards such as the [Web Content Accessibility Guidelines (WCAG)](https://www.w3.org/TR/WCAG/) [[WCAG]]. As the web develops in both size and complexity, these tools are essential for managing the resources available on the web. +There are currently many tools available which aid their users in testing web content for conformance to accessibility standards such as the [Web Content Accessibility Guidelines (WCAG)](https://www.w3.org/WAI/standards-guidelines/wcag/) [[WCAG]]. As the web develops in both size and complexity, these tools are essential for managing the resources available on the web. This format is intended to enable a consistent interpretation of how to test for [accessibility requirements](#structure-accessibility-requirements) to avoid conflicting results of accessibility tests. It is intended to be used to describe both manual accessibility tests as well as automated tests performed by accessibility testing tools (ATTs). @@ -25,11 +25,11 @@ Describing how to test certain accessibility requirements will result in accessi Scope {#scope} ============== -The ACT Rules Format defined in this specification is focused on the description of rules applicable to 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/) [[CSS2]], [Accessible Rich Internet Applications](https://www.w3.org/TR/wai-aria/) [[WAI-ARIA]], [Scaleable Vector Graphics](https://www.w3.org/TR/SVG/) [[SVG2]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. +The ACT Rules Format defined in this specification is focused on the description of rules applicable to 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/) [[CSS2]], [Accessible Rich Internet Applications](https://www.w3.org/WAI/standards-guidelines/aria/) [[WAI-ARIA]], [Scaleable Vector Graphics](https://www.w3.org/TR/SVG/) [[SVG2]] and more, including digital publishing. The ACT Rules Format, however, is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies. For instance, the ACT Rules Format can be used to describe ACT Rules dedicated to testing the [accessibility requirements](#structure-accessibility-requirements) defined in 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/intro/uaag) [[UAAG20]]. However, the ACT Rules Format would not necessarily be suitable to describe tests for the conformance of a non-web-based user agent. +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]]. However, the ACT Rules Format would not necessarily be suitable to describe tests for the conformance of a non-web-based user agent. ACT Rule Structure {#structure} @@ -208,7 +208,7 @@ This will mean that every time a rule is executed on a page, it will return a se - [Outcome](#output-outcome) (`Passed`, `Failed`, or `Inapplicable`)
    -Output data using EARL and JSON-LD. (See [Evaluation and Report Language](https://www.w3.org/WAI/intro/earl) [[EARL10-Schema]] and [Java Script Object Notation (JSON)](https://www.json.org).) +Output data using EARL and JSON-LD. (See [Evaluation and Report Language](https://www.w3.org/WAI/standards-guidelines/earl/) [[EARL10-Schema]] and [Java Script Object Notation (JSON)](https://www.json.org).) ```javascript { From 57165a01f4f71a3ab9b18bfb0c80b1785248d5d7 Mon Sep 17 00:00:00 2001 From: Moe Kraft Date: Sun, 3 Jun 2018 08:40:27 -0400 Subject: [PATCH 32/34] Link to Quickref Link to Quickref for SC 1.1.1 and 1.4.3 --- act-rules-format.bs | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index 07feb928..c3e3246d 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -64,7 +64,7 @@ An ACT Rule MUST have a description that is in plain language and provides a bri Accessibility Requirements {#structure-accessibility-requirements} ------------------------------------------------------------------- -An ACT Rule MUST identify the accessibility requirements to which the rule maps. For example, [WCAG 2.0 Success Criterion 1.1.1](https://www.w3.org/TR/2008/REC-WCAG20-20081211/#text-equiv-all) [[WCAG20]]. An ACT Rule is a complete or partial test for one or more accessibility requirements. +An ACT Rule MUST identify the accessibility requirements to which the rule maps. For example, [WCAG 2.0 Success Criterion 1.1.1](https://www.w3.org/WAI/WCAG20/quickref/#text-equiv) [[WCAG]]. An ACT Rule is a complete or partial test for one or more accessibility requirements. Outcomes from an ACT Rule MUST be consistent with the accessibility requirement, e.g. a rule only returns the outcome Fail when the content fails the accessibility requirement. This means that the rule maps to the accessibility requirement, as opposed to it merely being related to the requirement, thematically or otherwise. @@ -74,7 +74,7 @@ The actual definition of specific accessibility requirements is beyond the scope Limitations, Assumptions or Exceptions {#structure-limitations-assumptions-exceptions} ------------------------------------------------------------------- -An ACT Rule MUST list any limitations, assumptions or any exceptions for the test, the test environment, technologies being used or the subject being tested. For example, a rule that would partially test WCAG 2.0 Success Criterion 1.4.3 Contrast (Minimum) based on the inspection of CSS properties could state that it is only applicable to HTML text content stylable with CSS and does not support images of text. +An ACT Rule MUST list any limitations, assumptions or any exceptions for the test, the test environment, technologies being used or the subject being tested. For example, a rule that would partially test [WCAG 2.0 Success Criterion 1.4.3 Contrast (Minimum)](https://www.w3.org/WAI/WCAG20/quickref/#visual-audio-contrast-contrast) based on the inspection of CSS properties could state that it is only applicable to HTML text content stylable with CSS and 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 should be considered "text" or "non-text content" under WCAG 2.0. Whatever the interpretation is, this MUST be documented in the rule. @@ -82,7 +82,7 @@ Sometimes there are multiple plausible ways that an accessibility requirement ca Accessibility Support {#acc-support} =========================== -ACT Rules are designed to test the conformance of content using web technologies to accessibility requirements. However, not every feature of a web technology is implemented in all assistive technologies or user agents that a website may need to support. The concept of [accessibility supported](https://www.w3.org/TR/WCAG20/#accessibility-supporteddef) use of a Web technology is defined in [[WCAG20]]. Because of this, ACT Rules are not necessarily applicable in all test scenarios. For instance, a web page that has to work in assistive technologies that have no WAI-ARIA [[WAI-ARIA-1.1]] support, wouldn’t be tested with an ACT Rule that relies on WAI-ARIA support, since this could lead to false positive results. +ACT Rules are designed to test the conformance of content using web technologies to accessibility requirements. However, not every feature of a web technology is implemented in all assistive technologies or user agents that a website may need to support. The concept of [accessibility supported](https://www.w3.org/TR/WCAG20/#accessibility-supporteddef) use of a Web technology is defined in WCAG [[WCAG]]. Because of this, ACT Rules are not necessarily applicable in all test scenarios. For instance, a web page that has to work in assistive technologies that have no WAI-ARIA [[WAI-ARIA-1.1]] support, wouldn’t be tested with an ACT Rule that relies on WAI-ARIA support, since this could lead to false positive results. Even within a [rules group](#grouping), certain individual rules are not always applicable. This leaves one fewer solution for passing that particular rule group. Because of this, ACT Rules have to be atomic, meaning an ACT Rule MUST NOT rely on other rules to be part of the same test scenario. @@ -126,7 +126,7 @@ The means by which the accessibility tree is constructed, be it by a web browser Language, either written or spoken, contained in nodes of the DOM [[DOM]] or accessibility trees may be of interest to ACT Rules that intend to test things like complexity or intention of the language. For example, an ACT Rule might test that paragraphs of text within the DOM tree do not exceed a certain readability score or that the text alternative of an image provides a sufficient description. -The means by which the language is assessed, whether by a person or a machine, is not of importance as long as the assessment meets the criteria defined in [[wcag2-tech-req#humantestable]] [[WCAG20]]. +The means by which the language is assessed, whether by a person or a machine, is not of importance as long as the assessment meets the criteria defined in [[wcag2-tech-req#humantestable]] [[WCAG]]. ACT Test Definition {#test-def} From 87734e265176d9936b21d3e8bb5ed346f6bc6686 Mon Sep 17 00:00:00 2001 From: Moe Kraft Date: Sun, 3 Jun 2018 08:57:05 -0400 Subject: [PATCH 33/34] Updated Biblio Reference WAI-ARIA Updated biblio reference to point to non-versioned WAI-ARIA --- act-rules-format.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index c3e3246d..bc420281 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -82,7 +82,7 @@ Sometimes there are multiple plausible ways that an accessibility requirement ca Accessibility Support {#acc-support} =========================== -ACT Rules are designed to test the conformance of content using web technologies to accessibility requirements. However, not every feature of a web technology is implemented in all assistive technologies or user agents that a website may need to support. The concept of [accessibility supported](https://www.w3.org/TR/WCAG20/#accessibility-supporteddef) use of a Web technology is defined in WCAG [[WCAG]]. Because of this, ACT Rules are not necessarily applicable in all test scenarios. For instance, a web page that has to work in assistive technologies that have no WAI-ARIA [[WAI-ARIA-1.1]] support, wouldn’t be tested with an ACT Rule that relies on WAI-ARIA support, since this could lead to false positive results. +ACT Rules are designed to test the conformance of content using web technologies to accessibility requirements. However, not every feature of a web technology is implemented in all assistive technologies or user agents that a website may need to support. The concept of [accessibility supported](https://www.w3.org/TR/WCAG20/#accessibility-supporteddef) use of a Web technology is defined in WCAG [[WCAG]]. Because of this, ACT Rules are not necessarily applicable in all test scenarios. For instance, a web page that has to work in assistive technologies that have no WAI-ARIA [[WAI-ARIA]] support, wouldn’t be tested with an ACT Rule that relies on WAI-ARIA support, since this could lead to false positive results. Even within a [rules group](#grouping), certain individual rules are not always applicable. This leaves one fewer solution for passing that particular rule group. Because of this, ACT Rules have to be atomic, meaning an ACT Rule MUST NOT rely on other rules to be part of the same test scenario. From 791c18cc1fb75f60cad66629ac56727d174a424d Mon Sep 17 00:00:00 2001 From: Moe Kraft Date: Sun, 3 Jun 2018 09:07:17 -0400 Subject: [PATCH 34/34] Fix broken link Fixed broken link for test subject under Rule Aggregation --- act-rules-format.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/act-rules-format.bs b/act-rules-format.bs index bc420281..19e0528d 100644 --- a/act-rules-format.bs +++ b/act-rules-format.bs @@ -293,7 +293,7 @@ There are several ways this can be done. For instance, accessibility test tools Rule Aggregation {#output-aggregation} -------------------------------------- -As described in section [[#output]] a rule will return a list of results, each of which contain 1) the [Rule ID](#unique-identifier), 2) the test subject(#output-test-subject), 3) the [test target](#output-test-target), and 4) an [outcome](#output-outcome) (Passed, Failed, Inapplicable). Data expressed this way has a great deal of detail, as it gives multiple pass / fail results for each rule. +As described in section [[#output]] a rule will return a list of results, each of which contain 1) the [Rule ID](#unique-identifier), 2) the [test subject](#output-test-subject), 3) the [test target](#output-test-target), and 4) an [outcome](#output-outcome) (Passed, Failed, Inapplicable). Data expressed this way has a great deal of detail, as it gives multiple pass / fail results for each rule. Most expert evaluations do not report results at this level of detail. Often reports are limited to giving a single outcome (Passed, Failed, Inapplicable) per page, for each success criteria (or other accessibility requirement). To compare the data, results from rules should be combined, so that they are at the same level.