forked from w3c/wcag-act
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathNOTE-act-rules-common-aspects.bs
100 lines (67 loc) · 11.9 KB
/
NOTE-act-rules-common-aspects.bs
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
<pre class='metadata'>
Title: Accessibility Conformance Testing Rules: Common Input Aspects
Shortname: act-rules-aspects
ED: https://w3c.github.io/wcag-act/NOTE-act-rules-aspects
TR: https://www.w3.org/TR/act-rules-aspects/
Level: 1.0
Group: act-rules-format
Status: NOTE
Abstract: This document is a companion to the [Accessibility Conformance Testing (ACT) Rules Format 1.0](https://www.w3.org/TR/act-rules-format/) specification. It lists common input aspects as defined by the ACT Rules Format 1.0 specification. This document is informative. It provides a reference to well defined input aspects to assist authors in writing ACT Rules and to support the consistency of ACT Rules.
Editor: Wilco Fiers, Deque Systems, w3cid 43334
Editor: Maureen Kraft, IBM Corp, w3cid 53557
Editor: Mary Jo Mueller, IBM Corp, w3cid 46880
Editor: Shadi Abou-Zahra, Amazon, w3cid 34651
Markup Shorthands: css no, markdown yes
Repository: w3c/wcag-act
Issue Tracking: Public WCAG ACT Mailing List https://lists.w3.org/Archives/Public/public-wcag-act/
Prepare For TR: yes
Previous Version: https://www.w3.org/TR/2019/NOTE-act-rules-aspects-20190416/
Status Text:
<p><em>This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the <a href="https://www.w3.org/TR/">W3C technical reports index</a> at https://www.w3.org/TR/.</em></p>
<p data-deliverer="35422">This document was published by the <a href="https://www.w3.org/groups/wg/ag">Accessibility Guidelines Working Group</a> as a Group Note using the <a href="https://www.w3.org/2021/Process-20211102/#recs-and-notes">Note track</a>. Group Notes are not endorsed by W3C nor its Members. This informative document supports developers of Accessibility Conformance Testing (ACT) Rules to write rules more efficiently. It is a companion document to <a href="https://www.w3.org/TR/act-rules-format/">Accessibility Conformance Testing (ACT) Rules Format 1.0</a> and provides short-hand notation for some of the 'aspects' that ACT Rules may be testing.</p>
<p>The Accessibility Guidelines Working Group intends to publish updated versions of this Note to accompany further publications of ACT Rules Format 1.0, and when new 'aspects' are commonly used. This document is not intended to become a <abbr title="World Wide Web Consortium">W3C</abbr> Recommendation.</p>
<p>Comments on this informative Working Group Note are welcome. 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 TF 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%20Framework%201.0%20public%20comment">[email protected]</a> (<a href="https://lists.w3.org/Archives/Public/public-wcag-act-comments/">comment archive</a>).</p>
<p>Publication as a Working Group Note does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr> Membership. 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-20170801/">1 August 2017 W3C Patent Policy</a>. W3C maintains a <a rel="disclosure" href="https://www.w3.org/WAI/GL/disclosures.html">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-20170801/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="https://www.w3.org/Consortium/Patent-Policy-20170801/#sec-Disclosure">section 6 of the W3C Patent Policy</a>.</p>
<p>The <a href="https://www.w3.org/Consortium/Patent-Policy-20170801/">1 August 2017 W3C Patent Policy</a> does not carry any licensing requirements or commitments on this document.</p>
<p>This document is governed by the <a id="w3c_process_revision" href="https://www.w3.org/2021/Process-20211102/">2 November 2021 <abbr title="World Wide Web Consortium">W3C</abbr> Process Document</a>.</p>
</pre>
Introduction {#intro}
=====================
The term [Input Aspects](https://www.w3.org/TR/act-rules-format/#input-aspects) is defined by the [Accessibility Conformance Testing (ACT) Rules Format 1.0 Specification](https://www.w3.org/TR/act-rules-format/). An input aspect is a distinct part of a [test subject](https://www.w3.org/TR/act-rules-format/#test-subject). Atomic rules are required to list input aspects in the [applicability](https://www.w3.org/TR/act-rules-format/#applicability) and [expectations](https://www.w3.org/TR/act-rules-format/#expectations).
Some input aspects are already well defined in a formal specification within the context of web content, such as HTTP messages, DOM tree, and [CSS Styling](https://www.w3.org/TR/css/). These do not warrant a detailed description in ACT Rules Format 1.0 specification. Instead, these are listed in this informative document, which can be updated more easily. Atomic rules can refer to one of these common input aspects, however, these common input aspects are not required to conform to the ACT Rules Format 1.0 specification.
Examples of ACT Rules can be found in the [ACT Rules Repository](https://w3c.github.io/wcag-act-rules/).
The input aspects listed in this document can be used by authors of ACT Rules to refer to common types more easily. This improves the development process and supports consistency across rules. This list can be extended and refined at any time, for example, to include popular input aspects or to provide clarification. Existing input aspects can also be marked as obsoleted, if needed.
Common Input 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 [[HTML]] and [Cascading Style Sheets](https://www.w3.org/TR/css/).
DOM Tree {#input-aspects-dom}
----------------------------
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 the [Document Object Model](https://dom.spec.whatwg.org) [[DOM]].
CSS Styling {#input-aspects-css}
--------------------------------
The computed [CSS Styling](https://www.w3.org/TR/css/) 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]].
The test cases of ACT Rules interested in the CSS styling must be viewed with the CSS included by the author, and the [user agent default style sheet](https://drafts.csswg.org/css-cascade/#cascade-origin-ua). [User style sheets](https://drafts.csswg.org/css-cascade/#cascade-origin-user) and other custom styles should be avoided to ensure test cases have the expected outcome.
Accessibility Tree {#input-aspects-accessibility}
-------------------------------------------------
The accessibility tree constructed from extracting information from both the DOM [[DOM]] tree and the [CSS Styling](https://www.w3.org/TR/css/) 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]].
Language {#input-aspects-text}
------------------------------
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.
Rules can only operate on the Language aspect if the language of a page can be determined. 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]].
Some rules can only operate on a Language aspect if the language is sufficiently understood by the tester, while other rules only require identifying the language. For example, a rule checking that an accessible name is descriptive can only function if the language is understood. A rule checking the correctness of a `lang` attribute requires knowing what language is used, but not the meaning of the words.
Source Code {#input-aspects-code}
----------------------------------
The text content of a file from which a web browser or other user agent creates a page. For example, a browser may build up a web page from an HTML file, CSS file, SVG file and JavaScript file. The text of each of these four files is its source code. An ACT Rule could for example test for potential parser errors.
Source code is distinct from an HTTP response, which includes HTTP headers. It is the text content of the file before parsing, which often results in an object model or syntax tree, or serialized versions of those. Notably in HTML, the outerHTML property of the root node can vary significantly from its source code. For the purpose of ACT rules, source files processed on the server such as PHP for creating HTML, or SASS for creating CSS are not considered, as those are not processed by the user agent.
Audio Output {#input-aspects-audio-out}
---------------------------------------
Audio output may be of interest to ACT Rules that intend to test things like the speech and sounds provided in media files. Some rules can operate on whether there is audio output, such as an ACT Rule that may check that audio output on a Web page does not play automatically. Some rules can only operate if the audio output is understood by the tester. For example, a rule checking that captions are equivalent can only function if the audio output is understood.
Visual Output {#input-aspects-visual-out}
-----------------------------------------
Visual output may be of interest to ACT Rules that intend to test things like the moving images displayed in media or animation files. Some rules can operate on the presence of visual output, such as an ACT Rule that may check that visual output has a control to stop it. Some rules can only operate if the visual output is understood by the tester. For example, a rule checking that the visual output information is available in a transcript.