# Accessibility Conformance Testing Rules: Common Input Aspects

## Editor’s Draft, 1 January 1970

This version:
  https://w3c.github.io/wcag-act/NOTE-act-rules-common-aspects.html
Latest published version:
  https://www.w3.org/TR/
Previous Versions:
  https://w3c.github.io/wcag-act/archive_act-format/NOTE-act-rules-common-aspects.html
Editors:
  Wilco Fiers (Deque Systems)
  Maureen Kraft (IBM Corp.)
  Mary Jo Mueller (IBM Corp.)
  Shadi Abou-Zahra (W3C)

To the extent possible under law, the editors have waived all copyright and related or neighboring rights to this work. In addition, as of 1 January 1970, the editors have made this specification available under the Open Web Foundation Agreement Version 1.0, which is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0. Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.

## Abstract

This document is a companion to the Accessibility Conformance Testing (ACT) Rules Format 1.0 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.

## 1. Introduction

The term Input Aspects is defined by the Accessibility Conformance Testing (ACT) Rules Format 1.0 Specification. An input aspect is a distinct part of a test subject. Atomic rules are required to list input aspects in the applicability and 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. 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.

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.

## 2. Common Input Aspects

### 2.1. HTTP Messages

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.

### 2.2. DOM Tree

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 [DOM].

### 2.3. CSS Styling

The computed CSS 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 [CSSOM].

### 2.4. Accessibility Tree

The accessibility tree constructed from extracting information from both the DOM [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 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 [CORE-AAM-1.1].

### 2.5. Language

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 Requirements for WCAG 2.0 Checklists and Techniques §humantestable [WCAG].

## Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with `class="example"`, like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with `class="note"`, like this:

Note, this is an informative note.

## References

### Normative References

[RFC2119]
  S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119

### Informative References

[CORE-AAM-1.1]
  Joanmarie Diggs; et al. Core Accessibility API Mappings 1.1. 14 December 2017. REC. URL: https://www.w3.org/TR/core-aam-1.1/
[CSSOM]
  Simon Pieters; Glenn Adams. CSS Object Model (CSSOM). 17 March 2016. WD. URL: https://www.w3.org/TR/cssom-1/
[DOM]
  Anne van Kesteren. DOM Standard. Living Standard. URL: https://dom.spec.whatwg.org/
[HTML]
  Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[HTTP11]
  R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html
[WCAG]
  Wendy Chisholm; Gregg Vanderheiden; Ian Jacobs. Web Content Accessibility Guidelines 1.0. 5 May 1999. REC. URL: https://www.w3.org/TR/WAI-WEBCONTENT/