Skip to content

Commit

Permalink
Editorial Updates to rules format (#561)
Browse files Browse the repository at this point in the history
* ACT Rules Format FPWD

* Fix previous version

* Fix boilerplate typo

* Back to ED metadata

* Update metaddata
  • Loading branch information
daniel-montalvo authored Jul 1, 2024
1 parent fb3de5e commit 6760691
Show file tree
Hide file tree
Showing 3 changed files with 54 additions and 21 deletions.
49 changes: 28 additions & 21 deletions act-rules-format/act-rules-format.bs
Original file line number Diff line number Diff line change
@@ -1,20 +1,27 @@
<pre class='metadata'>
Title: Accessibility Conformance Testing (ACT) Rules Format 1.1
Shortname: ACT-Rules-Format-1.1
URL: https://w3c.github.io/wcag-act/act-rules-format.html
Previous Version: https://w3c.github.io/wcag-act/archive_act-format/2019-07-22.html
Shortname: act-rules-format
ED: https://w3c.github.io/wcag-act/act-rules-format.html
TR: https://www.w3.org/TR/act-rules-format/
Previous Version: https://www.w3.org/TR/act-rules-format-1.0/
Level: 1.1
Status: w3c/ED
Prepare For TR: yes
Status: ED
Status Text:
Deadline: 2024-08-18
Group: act-rules-format
Editor: Wilco Fiers, Deque Systems
Editor: Kathy Eng, US Access Board
Editor: Trevor Bostic, MITRE Corp.
Editor: Wilco Fiers, Deque Systems, w3cid 43334
Editor: Kathy Eng, US Access Board, w3cid 107871
Editor: Trevor Bostic, MITRE Corp., w3cid 105887
Editor: Daniel Montalvo, W3C, w3cid 114058
Former Editor: Maureen Kraft, IBM Corp.
Former Editor: Mary Jo Mueller, IBM Corp.
Former Editor: Shadi Abou-Zahra, W3C
Abstract: The Accessibility Conformance Testing (ACT) Rules Format 1.1 defines a format for writing accessibility test rules. These test rules can be used for developing automated testing tools and manual testing methodologies. It provides a common format that allows any party involved in accessibility testing to document and share their testing procedures in a robust and understandable manner. This enables transparency and harmonization of testing methods, including methods implemented by accessibility test tools.
Abstract: The Accessibility Conformance Testing (ACT) Rules Format 1.1 defines a format for writing accessibility test rules. These test rules can be used for developing automated testing tools and manual testing methodologies. It provides a common format that allows any party involved in accessibility testing to document and share their testing procedures in a robust and understandable manner. This enables transparency and harmonization of testing methods, including methods implemented by accessibility test tools.
Markup Shorthands: markdown yes
Local Boilerplate: abstract yes, status yes, copyright yes
</pre>

<style>
.rfc2119 {
text-transform: uppercase;
Expand Down Expand Up @@ -53,7 +60,7 @@ The ACT Rules Format defines the requirements and rule structure for the types o
Scope {#scope}
==============

The ACT Rules Format defined in this specification is designed for rules that can be used in testing content created using web technologies, such as [Hypertext Markup Language](https://www.w3.org/TR/html/) [[HTML]], [Cascading Style Sheets](https://www.w3.org/TR/CSS/) [[css-2018]], [Accessible Rich Internet Applications](https://www.w3.org/WAI/standards-guidelines/aria/) [[WAI-ARIA]], [Scalable Vector Graphics](https://www.w3.org/TR/SVG/) [[SVG2]], [EPUB 3](http://www.idpf.org/epub3/latest/), and more. The ACT Rules Format is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies.
The ACT Rules Format defined in this specification is designed for rules that can be used in testing content created using web technologies, such as [Hypertext Markup Language](https://www.w3.org/TR/html/) [[HTML]], [Cascading Style Sheets](https://www.w3.org/TR/CSS/) [[css-2018]], [Accessible Rich Internet Applications](https://www.w3.org/WAI/standards-guidelines/aria/) [[WAI-ARIA]], [Scalable Vector Graphics](https://www.w3.org/TR/SVG/) [[SVG2]], [EPUB 3](httpss://www.idpf.org/) [[epub-33]], and more. The ACT Rules Format is designed to be technology agnostic, meaning that it can conceivably be used to describe test rules for other technologies.

The ACT Rules Format can be used to describe ACT Rules dedicated to testing the [=accessibility requirements=] defined in the Web Content Accessibility Guidelines [[WCAG22]], which are specifically designed for web content. Other accessibility requirements applicable to web technologies can also be testable with ACT Rules. For example, ACT Rules could be developed to test the conformance of web-based user agents to the [User Agent Accessibility Guidelines](https://www.w3.org/WAI/standards-guidelines/uaag/) [[UAAG20]]. The ACT Rules Format might not always be suitable to describe tests for other types of accessibility requirements.

Expand Down Expand Up @@ -111,8 +118,8 @@ An ACT Rule <em class="rfc2119">must</em> consist of at least the following item

An ACT Rule MAY also contain:

* [Related Rules](related-rules) (optional) under Background
* [Other Resources](other-resources) (optional) under Background
* [Related Rules](#related-rules) (optional) under Background
* [Other Resources](#other-resources) (optional) under Background
* [Issues List](#issues-list) (optional)
* [Implementations](#implementations) (optional)
* [Acknowledgments](#acknowledgments) (optional)
Expand Down Expand Up @@ -183,7 +190,7 @@ Each [=accessibility requirement=] in the mapping <em class="rfc2119">must</em>
### Outcome Mapping ### {#outcome-mapping}
For each conformance requirement in the mapping, an ACT Rule <em class="rfc2119">must</em> indicate what the [=outcomes=] of the rule mean for satisfying an accessibility requirement for that [=test subject=].

#### Conformance Requirements #### {#conformance-requirements}
#### <dfn>Conformance Requirements</dfn> #### {#conformance-requirements}

When a rule is designed to test a specific accessibility requirement, the accessibility requirement is mapped as a Conformance Requirement when both of the following conditions are true:

Expand Down Expand Up @@ -226,7 +233,7 @@ Rules that can be used to determine if an accessibility requirement is *satisfie
</ul></blockquote>
</aside>

#### Secondary Requirements #### {#secondary-requirements}
#### <dfn>Secondary Requirements</dfn> #### {#secondary-requirements}

A secondary accessibility requirement is a requirement that is correlated with the rule, but for which the rule is not designed to test. The outcome of the rule impacts the result of the accessibility requirement, but the rule is not intended to test the conformance of that requirement. This correlation often results in some of the rule's test cases not satisfying the secondary accessibility requirement.

Expand Down Expand Up @@ -368,7 +375,7 @@ To evaluate content using an ACT Rule, the rule requires some information from t

### Input Aspects (Atomic rules only) ### {#input-aspects}

An input aspect is a distinct part of the [=test subject=]. Rendering a particular piece of content to an end user commonly involves different technologies, some or all of which are required as input for an [=atomic rule=]. For example, some rules need to operate directly on the [Hypertext Transfer Protocol](https://tools.ietf.org/html/rfc7230) [[http11]] messages exchanged between a server and a client, while others need to operate on the [Document Object Model](https://dom.spec.whatwg.org) [[DOM]] tree exposed by a web browser.
An input aspect is a distinct part of the [=test subject=]. Rendering a particular piece of content to an end user commonly involves different technologies, some or all of which are required as input for an [=atomic rule=]. For example, some rules need to operate directly on the [Hypertext Transfer Protocol](https://datatracker.ietf.org/doc/html/rfc7230) [[http11]] messages exchanged between a server and a client, while others need to operate on the [Document Object Model](https://dom.spec.whatwg.org) [[DOM]] tree exposed by a web browser.

[=Atomic rules=] <em class="rfc2119">must</em> list the aspects used as input for the [applicability](#applicability-atomic) and [expectations](#expectations-atomic) of the atomic rule. Rules can operate on several aspects simultaneously, such as both the HTTP messages and the DOM tree.

Expand All @@ -393,7 +400,7 @@ Some input aspects are well defined in a formal specification, such as HTTP mess
</ul></blockquote>
</aside>

The method through which an input aspect is served is not relevant. For example a DOM tree can be served through HTTP as HTML, it can be bundled as several pages in an [EPUB publication](http://www.idpf.org/epub3/latest/), or it can be inferred from a [JSX source file](https://facebook.github.io/jsx/). All rules that have only DOM tree as an input aspect can be applied to those technologies.
The method through which an input aspect is served is not relevant. For example a DOM tree can be served through HTTP as HTML, it can be bundled as several pages in an [EPUB publication](http://www.idpf.org/), or it can be inferred from a [JSX source file](https://facebook.github.io/jsx/). All rules that have only DOM tree as an input aspect can be applied to those technologies.


### Input Rules (Composite rules only) ### {#input-rules}
Expand All @@ -420,7 +427,7 @@ Subjective properties are concepts like decorative, navigation mechanism, and pr
Definitions can be put in the rule [glossary](#glossary), or they can be defined in the section where they are used.

<aside class=example>
<header>Example objective applicability of an atomic rule testing [WCAG 2.2 success criterion 1.4.2 Audio Control](https://www.w3.org/WAI/WCAG21/quickref/#audio-control):</header>
<header>Example objective applicability of an atomic rule testing [WCAG 2.2 success criterion 1.4.2 Audio Control](https://www.w3.org/WAI/WCAG22/quickref/#audio-control):</header>
<blockquote>
<p>Applicability: Each `video` or `audio` element with the `autoplay` attribute, as well as each `object` element that is used for automatically playing video or audio when the web page loads.</p>
<p>Note: A web page is considered "loaded" when the `document.readyState` is set to `complete`.</p>
Expand Down Expand Up @@ -455,7 +462,7 @@ Definitions can be put in the rule [glossary](#glossary), or they can be defined
</blockquote>
</aside>

#### Applicability Type Designation (optional)
#### Applicability Type Designation (optional) {#applicability-type-designation-atomic-optional}

Rules can optionally include an applicability type identifier signifying whether the rule contains an objective or a subjective applicability. This identifier is intended to benefit rule readers and implementers by clearly stating the rule author's intention of the applicability and reducing confusion due to different reader and implementer interpretations.

Expand All @@ -478,7 +485,7 @@ Note that input rules in a composite rule <em class="rfc2119">may</em> have diff
</blockquote>
</aside>

#### Applicability Type Designation (optional)
#### Applicability Type Designation (optional) {#applicability-type-designation-composite-optional}

Composite rules can optionally include an applicability type identifier signifying whether the rule contains an objective or a subjective applicability. The applicability type of a composite rule is calculated as subjective if any of the input rules contain a subjective applicability or objective otherwise.

Expand All @@ -498,7 +505,7 @@ All expectations of an [=atomic rule=] <em class="rfc2119">must</em> describe th
<aside class=example>
<header>Example expectations of a rule to test for accessible names of HTML `input` elements:</header>
<blockquote><ol>
<li>Each HTML `input` element 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]]</li>
<li>Each HTML `input` element has an accessible name (as described in [Accessible Name and Description: Computation and API Mappings 1.1](https://www.w3.org/TR/accname-1.1/#mapping_additional_nd_te)). [[accname-aam-1.1]]</li>
<li>The accessible name describes the purpose of each HTML `input` element.</li>
</ol></blockquote>
</aside>
Expand Down Expand Up @@ -665,7 +672,7 @@ Consistency describes how well a [=check=] is aligned with the intent of an ACT

3. <dfn>Rule Mapping</dfn>: The accessibility requirements are reported consistently, meaning:
1. The [=check=] is reported as testing for all the rule's [=conformance requirements=], except requirements of a level or standard not supported by the implementation; and
2. All accessibility requirements the rule reports to be a part of are either [=conformance requirements=] or [=secondary requirements=], except for requirements of [=accessibility requirement documents=] not mentioned in the rule.
2. All accessibility requirements the rule reports to be a part of are either [=conformance requirements=] or [=secondary requirements=], except for requirements of [=accessibility requirements documents=] not mentioned in the rule.

When a [=check=] reports more than one outcomes for a test case, the first outcome that appears on the following ordered list is considered for determining consistency:

Expand Down Expand Up @@ -744,7 +751,7 @@ Harmonization occurs when a group of rule implementors collectively accept the v
</ul></blockquote>
</aside>

An example of such a process is the [WCAG ACT Review Process](https://w3c.github.io/wcag-act-rules/review-process.html).
An example of such a process is the [WCAG ACT Review Process](https://w3c.github.io/wcag-act/wcag-ruleset-review-process).


Definitions {#definitions}
Expand Down
1 change: 1 addition & 0 deletions act-rules-format/copyright.include
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
<a href="https://www.w3.org/policies/#copyright">Copyright</a> © 2024 <a href="https://www.w3.org/">World Wide Web Consortium</a>. <abbr title="World Wide Web Consortium">W3C</abbr><sup>®</sup> <a href="https://www.w3.org/policies/#Legal_Disclaimer">liability</a>, <a href="https://www.w3.org/policies/#W3C_Trademarks">trademark</a> and <a href="https://www.w3.org/copyright/document-license/">document use</a> rules apply.
25 changes: 25 additions & 0 deletions act-rules-format/status.include
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
<p><em>This section describes the status of this document at the time of its publication. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the latest revision of this technical report can be found in the <a href="https://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at https://www.w3.org/TR/.</em></p>

<p include-if="ED">This is an Editor Draft of Accessibility Conformance Testing (ACT) Rules Format [LEVEL], prepared by the <a href="http://www.w3.org/wai/gl/task-forces/conformance-testing/">Accessibility Conformance Testing (ACT) Task Force</a> of the <a href="https://www.w3.org/WAI/GL/">Accessibility Guidelines Working Group (AGWG)</a>. This document is an Editor Draft and does not represent consensus of the <a href="https://www.w3.org/WAI/GL/">Accessibility Guidelines Working Group</a>. This document is intended to become a <abbr title="World Wide Web Consortium">W3C</abbr> Recommendation after further review and refinement.</p>

<p include-if="ED">This is an Editor Draft for review and refinement within ACT TF and AGWG. It is not ready for public comments. Before commenting, please first review the <a href="https://github.com/w3c/wcag-act/"><abbr title="World Wide Web Consortium">W3C</abbr> ACT TF GitHub repository</a> for related comments. New comments can be submitted as <a href="https://github.com/w3c/wcag-act/issues/new">new GitHub issues</a> or by email to <a href="mailto:[email protected]?subject=ACT%20Fomrmat%201.1%20public%20comment">[email protected]</a> (<a href="https://lists.w3.org/Archives/Public/public-wcag-act-comments/">public list archive</a>).</p>

<p include-if="ED">Publication as an Editor Draft does not imply endorsement by
<abbr title="World Wide Web Consortium">W3C</abbr> and its Members. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p>

<p include-if="FPWD">This is a First Public Working Draft of Accessibility Conformance Testing (ACT) Rules Format [LEVEL] by the <a href="https://www.w3.org/groups/wg/ag/">Accessibility Guidelines Working Group</a>. ACT-Rules Format [LEVEL] is a complete draft, addressing all of the <a href="https://w3c.github.io/wcag-act/act-fr-reqs.html">requirements</a> the ACT Task Force believes are important to cover when writing rules. The ACT-Rules Format is based on rules developed by the <a href="https://act-rules.github.io/">ACT-Rules Community Group</a>.</p>

<p>[STATUSTEXT]

<p>To comment, <a href="https://github.com/w3c/wcag-act/issues/new">file an issue in the <abbr title="World Wide Web Consortium">W3C</abbr> ACT GitHub repository</a>. It is free to create a GitHub account to file issues. If filing issues in GitHub is not feasible, send email to <a href="mailto:[email protected]?subject=ACT%20Format%201.1%20public%20comment">[email protected]</a> (<a href="https://lists.w3.org/Archives/Public/public-wcag-act-comments/">comment archive</a>). Comments are requested by <strong>[DEADLINE]</strong>. In-progress updates to the document may be viewed in the <a href="https://w3c.github.io/wcag-act/act-rules-format.html">publicly visible editors' draft</a>.</p>

<p include-if="FPWD">This document was published by the <a href="https://www.w3.org/groups/wg/ag/">Accessibility Guidelines Working Group</a> as a First Public Working Draft using the <a
href='https://www.w3.org/2023/Process-20231103/#recs-and-notes'>Recommendation
track</a>. This document is intended to become a <abbr title="World Wide Web Consortium">W3C</abbr> Recommendation.</p>

<p include-if="FPWD">Publication as a First Public Working Draft does not imply endorsement by
<abbr title="World Wide Web Consortium">W3C</abbr> and its Members. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p>

<p>This document was produced by a group operating under the <a href="https://www.w3.org/Consortium/Patent-Policy/">W3C Patent Policy</a>. W3C maintains a <a rel="disclosure" href="https://www.w3.org/groups/wg/ag/ipr/">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="https://www.w3.org/Consortium/Patent-Policy/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="https://www.w3.org/Consortium/Patent-Policy/#sec-Disclosure">section 6 of the W3C Patent Policy</a>.</p>

<p>This document is governed by the <a id="w3c_process_revision" href="https://www.w3.org/2023/Process-20231103/">03 November 2023 W3C Process Document</a>.

0 comments on commit 6760691

Please sign in to comment.