My take on this is that it is likely unclear to many non-developers what a "test subject type" actually entails as a lot of implicit assumptions underpin the choice of test subject type. In the case of a rule that verifies color contrast, for example, it is obvious to a developer that the test subject type would be the rendered page. The "why" of it is missing though; computing styles and cascade is required in order to determine the fore- and background color of a given element, hence the need to render the page before running the rule.

What I would like to suggest is something along the lines of a section describing "requirements" instead. Based on these requirements, rule implementors can then themselves determine how to run a given rule. For example:

• Rule: Verification of color contrast.
  Requirements: CSS styles must be computed before running the rule.
  Conclusion: Run rule in a browser.

• Rule: Validation of HTML.
  Requirements: HTML is not parsed prior to running the rule.
  Conclusion: Run rule on the raw HTTP response.

• Rule: Verification of template (<template>, JSX, Handlebars, etc.) attributes.
  Requirements: Unparsed templates are available when running the rule.
  Conclusion: Run rule on the source code.

What I'm thinking is that it is easier for people to answer the question "what does my rule require?" than it is answering "on what kind of input should my rule be run?".

I agree with @kasperisager and believe these would fit better as a kind of Requirement for a test rule. Also we should consider removing the more fluffy "Scripts" and "Templates" from the list of test subject types, as they are more likely to cause confusion than to help. If you come to need these types when developing rules, you will be able to specify them then to properly fit the purpose of your rule.

SI will create a proposal by October 19th for the TF to review.

As mentioned above, Siteimprove would like to see this section more focused on the actual requirements for a Rule and then leave it up to the implementers to decide on the input type, as long as it lives up to the specified requirements.
As agreed, we have created a proposal for this section to illustrate what we are looking for:

4. Input Requirements

Web pages, including publications and applications, go through many different stages before they are rendered to the end user. For example, PHP may be used to put various pieces of content into a template. That template is then sent as an HTML text document to a web browser. The browser in turn parses it and turns it into a DOM tree before rendering it to the screen. Accessibility tests could be run at each of these stages. It is therefore important to specify the input requirements that an ACT Rule expects.

The ACT Rule must state the kind of input that is required for the rule to give the expected results.

Examples of input requirements:

• Source HTML must be available
• The DOM must be constructed
• CSS styles must be computed
• Elements must be laid out on the page
• Images must be fully loaded
• HTTP headers must be available
• Input events can be triggered
• Unparsed templates must be available
• Script AST must be available
• Combinations of the above mentioned input requirements

Other input requirements are possible. In those cases the ACT Rule MUST include a description of the input requirement, or a reference to that description. Rule authors are encouraged to specify new input requirements if necessary.

Source HTML must be available

Source HTML is a textual representation of the structure of a document. It is necessary to have access to it for parsing it or validating it.

The DOM must be constructed

DOM (Document Object Model) represents the document as nodes and objects. It provides a tree representation of the structure of the document and the API for traversing and modifying this representation. Access to it is necessary for identifying the nodes and its properties and for testing the relationships between nodes.

CSS styles must be computed

CSS is a stylesheet language used to describe the presentation of the HTML or XML documents. Computed CSS describes how the nodes should be rendered and it is the result of applying stylesheets to the document, accounting for cascade and for inherited, relative, media query-specific and for other properties that might be dependent on some other factor than the CSS declaration itself. Access to the computed CSS is necessary to test the resulting visual representation of the document.

Elements must be laid out on the page

The document (and potentially stylesheets) specify how the elements should be positioned. Access to the layout is required to be able to test how are the elements positioned in relation to each other and to the viewport or the document.

Images must be fully loaded

Access to the content of the images is necessary to test their impact on the layout and rendering of the document as well as for testing the actual content of the images.

HTTP headers must be available

HTTP headers are the metadata of the data transferred using the HTTP protocol from the server that hosts the website to the user's browser. Access to HTTP headers is necessary for tests involving the transferred metadata, such as the language code of the document.

Input events can be triggered

It must be possible to trigger input events (such as key presses or pointer events) to be able to test the behavior or presentation of the document in various states.

Unparsed templates must be available

Template is the source code which is used to generate the final source code (for example HTML). Access to the template is necessary if testing is required before generating the final source code.

Script AST must be available

Script AST (Abstract Syntax Tree) is a representation of a structure of the script's source code. It might be necessary to be able to test the code statically (without its execution).
Combinations of the above mentioned input requirements
In many cases, more than one type of input will be required for properly executing a given rule. This should be clearly stated in the ACT Rule.

Examples:

Rule: Visible link focus (2.4.7 Focus visible)

Input requirements:

• Input events can be triggered
• CSS styles must be computed

Possible implementation options:

• Run the rule in a headless browser

Rule: Form validation (3.3.1 Error identification)

Input requirements:

• Input events can be triggered

Possible implementation options:

• Run the rule in a browser using a webdriver

Rule: Verification of template (<template>, JSX, Handlebars, etc.) attributes

Input requirements:

• Unparsed templates must be available

Possible implementation options:

• Run the rule on the template's source code

Rule: Inline links are distinguishable (1.4.1 Use of color)

Input requirements:

• CSS styles must be computed

Possible implementation options:

• Run the rule in a headless browser

Rule: Using HTML according to spec (4.1.1 Parsing)

Input requirements:

• Source HTML must be available

Possible implementation options:

• Run the rule on the source HTML using an HTML parser

Rule: Language of the page is set (either using meta tags or HTTP headers) (3.1.1 Language of Page)

Input requirements:

• Source HTML must be available
• HTTP headers must be available

Possible implementation options:

• Run the rule on the HTTP response

Rule: Providing submit buttons (3.2.2 On Input)

Input requirements:

• The DOM must be constructed

Possible implementation options:

• Run rule on a constructed DOM (e.g. in a headless browser)

Rule: Images of text (1.4.5 Images of Text)

Input requirements:

• Images must be fully loaded

Possible implementation options:

• Run the rule in a browser

Rule: Text-background contrast (1.4.3 Contrast (Minimum), 1.4.6 Contrast (Enhanced))

Input requirements:

• Images must be fully loaded
• CSS styles must be computed
• Elements must be laid out on the page

Possible implementation options:

• Run the rule in a headless browser
• Run the rule in a browser

Rule: Implementing automatic redirects on the server side instead of on the client side

Input requirements:

• Script AST must be available

Possible implementation options:

• Run the rule on a script source code

I think that in most cases these are implementation details that may not be the only way to implement the rules and I would therefore caution against becoming too explicit and thereby blocking technology enhancements or innovation from implementing this standard

@WilcoFiers Here's my take on a replacement for section 5 "Test Subject Types":

Aspects Under Test

ACT Rules can operate on different aspects of the subject being tested. 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 may 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.

Each ACT Rule MUST include a description of all the aspects under test by the rule. Some of these aspects are already well defined within the context of web content, such as HTTP messages, DOM tree, and computed 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 a detailed description, or a reference to one, of the aspect in question.

Will add list of examples, including hearing and vision, as well as specify that each aspect is discrete.

This was handled in pull request #157.