Accessibility Conformance Testing (ACT) Rules Format 1.0

W3C Candidate Recommendation, 16

This version:
Latest published version:
Highest version of ACT Rules Format:
Latest editor's draft:
Implementation report:
Previous version:
Wilco Fiers (Deque Systems)
Maureen Kraft (IBM Corp.)
Mary Jo Mueller (IBM Corp.)
Shadi Abou-Zahra (W3C)


The Accessibility Conformance Testing (ACT) Rules Format 1.0 defines a format for writing accessibility test rules. These rules can be evaluated fully-automatically, semi-automatically, and manually. This common format 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.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This is a Candidate Recommendation of Accessibility Conformance Testing Rules Format 1.0 (ACT Rules Format 1.0) by the Accessibility Guidelines Working Group. This is a call for implementation; the Accessibility Guidelines Working Group requests that implementations be submitted by 28 May 2019. The Working Group targets 28 May 2019 to complete the testing process and produce the implementation report. The Working Group plans to advance past Candidate Recommendation when at least three independent instances of rules meeting the Candidate Recommendation Exit Criteria have been identified and documented.

The Accessibility Guidelines Working Group primarily seeks feedback in relation to implementation of ACT Rules Format 1.0, but feedback on any aspect of the document is accepted. To comment, file an issue in the W3C ACT TF GitHub repository. It is free to create a GitHub account to file issues. If filing issues in GitHub is not feasible, send email to public-wcag-act-comments@w3.org (comment archive). Comments are requested by 28 May 2019. In-progress updates to the document may be viewed in the publicly visible editors' draft.

This document was published by the Accessibility Guidelines Working Group as a Candidate Recommendation. This document is intended to become a W3C Recommendation. W3C publishes a Candidate Recommendation to indicate that the document is believed to be stable and to encourage implementation by the developer community. This Candidate Recommendation is expected to advance to Proposed Recommendation no earlier than 28 May 2019.

Please see the Working Group's implementation report.

Publication as a Candidate Recommendation does not imply endorsement by the W3C 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.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures 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 Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 March 2019 W3C Process Document.

1. Introduction

There are currently many test procedures and tools available which aid their users in testing web content for conformance to accessibility standards such as the Web Content Accessibility Guidelines [WCAG]. As the web develops in both size and complexity, these procedures and 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 conformance to WCAG and other accessibility requirements documents and promote consistent results in accessibility testing. The rules format is designed to describe both manual accessibility tests, as well as automated tests as performed by accessibility testing tools.

Documenting how to test 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).

An ACT Rule is a plain language description of how to test a specific type of content for a specific aspect of an accessibility requirement. An ACT Rule describes what kind of content it applies to and which conditions must be true about the applicable elements for them to meet all expectations of the rule.

The ACT Rules Format defines the requirements and rule structure for the types of information each rule needs to include to be called an ACT Rule. The structure of the ACT rule is defined in the ACT Rule Structure section. Each ACT Rule also contains a plain language description of the type of content under test, the test to perform, and the expected result. Where the test result affects conformance, the rule documents the particular requirement being tested. The resulting outcomes from the test can be used to help determine conformance or non-conformance to the requirement. Test cases are also written as part of the ACT rule to provide a way to verify that implementations of the rule can successfully determine the expected outcomes.

2. 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 [HTML], Cascading Style Sheets [css-2018], Accessible Rich Internet Applications [WAI-ARIA], Scalable Vector Graphics [SVG2], EPUB 3, 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 [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]. The ACT Rules Format might not always be suitable to describe tests for other types of accessibility requirements.

3. ACT Rule Types

In accessibility, there are often different technical solutions to make the same type of content accessible. For example, there are multiple methods for giving an img element in HTML an accessible name. Multiple solutions could be tested in a single rule; however, such a rule tends to be quite complex, making it difficult to understand and maintain. The ACT Rules Format solves this by providing two types of rules:

Composite rules cannot contain other composite rules. Any time a nested composite rule would be needed, all of the relevant atomic rules can be combined directly into the new composite rule.

Composite rule: Video elements have an audio description or media alternative (WCAG 2.1 success criterion 1.2.3 Audio Description or Media Alternative).

Each HTML video element meets all expectations from at least one of the following rules:

Not all atomic rules have to be part of a composite rule. Composite rules are used when the outcomes of multiple atomic rules need to be combined to determine if a test subject does not satisfy an accessibility requirement.

The separation between atomic rules and composite rules creates a division of responsibilities. Atomic rules test if web content is correctly implemented in a particular solution. Composite rules can test if a combination of outcomes from other atomic rules satisfy the accessibility requirement, in part or as a whole.

4. ACT Rule Structure

An ACT Rule MUST consist of at least the following items:

The ACT Rules format does not prescribe what format ACT Rules can be written in (e.g. HTML, DOCX, PDF, etc.). However, ACT Rules MUST be written in a document that conforms to the Web Content Accessibility Guidelines [WCAG] or a comparable accessibility standard. This ensures that ACT Rules are accessible to people with disabilities. ACT Rule test cases are allowed to contain inaccessible content. If any test case contains accessibility issues listed in WCAG 2.1 Section 5.2.5 Non-Interference, users MUST be warned of this in advance. In addition to supporting people with disabilities, using an accessible format also makes internationalization of ACT Rules easier.

4.1. Rule Identifier

An ACT Rule MUST have a unique identifier that can be any unique text, such as plain text, URL or a database identifier.

Example: ACT Rules can use identifiers that can also be used as a file name. They include a technology directory, followed by a handle that includes an element name or attribute:

4.2. Rule Description

An ACT Rule MUST have a description that is in plain language which provides a brief explanation of what the rule does.

Example: This rule checks that the HTML page has a title

4.3. Rule Type

An ACT Rule MUST have a rule type which is one of the following:

Refer to the Rule Type section for detailed definitions of the rule types.

4.4. Accessibility Requirements Mapping

When an ACT Rule is designed to test conformance to one or more Accessibility requirements documents, the rule MUST list all accessibility requirements from those documents that are not satisfied when one or more of the outcomes of the rule is failed. For example, when designing a rule for WCAG that tests if image buttons have alternative text, the rule maps to success criteria 1.1.1 Non-text content, and 4.1.2 Name, Role, Value. That ACT Rule will list both success criteria in its accessibility requirements mapping.

Each accessibility requirement in the mapping MUST include the following:

  1. either the name, title, identifier or summary of the accessibility requirement, and

  2. the name of the accessibility requirements document, and

  3. a link or reference to the accessibility requirements document if one exists, and

  4. the conformance level associated with the accessibility requirement, if one exists.

4.4.1. Outcome Mapping

For each accessibility requirement in the mapping, an ACT Rule MUST indicate what the outcomes of the rule mean for satisfying that accessibility requirement for that test subject. When one or more of the outcomes for a test target is failed, the accessibility requirements are not satisfied for the test subject. When all of the outcomes are passed or inapplicable, the accessibility requirements could be satisfied, or further testing is needed. Rules that can be used to determine if an accessibility requirement is satisfied are called satisfying tests.

Note: In the Web Content Accessibility Guidelines [WCAG], success criteria do not evaluate to passed, failed or inapplicable. Rather they can be satisfied (or not). (See the WCAG 2.1 definition: satisfies a success criterion.) If a success criterion is not satisfied, a web page can only conform if there is a conforming alternative version, as described in WCAG 2.1 Conformance Requirement 1.

Example: Accessibility Requirements Mapping for a rule that tests if an image button has an accessible name:

  • Success criterion 1.1.1: Non-text content
    • Required for conformance to WCAG 2.0 and WCAG 2.1 level A
    • Outcome mapping:
      • Any failed outcomes: not satisfied
      • All passed outcomes: further testing is needed
      • An inapplicable outcome: further testing is needed
  • Success criterion 4.1.2: Name, Role, Value
    • Required for conformance to WCAG 2.0 and WCAG 2.1 level A
    • Outcome mapping:
      • Any failed outcomes: not satisfied
      • All passed outcomes: further testing is needed
      • An inapplicable outcome: further testing is needed

4.4.2. Mapping Outside WCAG

ACT Rules can be used to test accessibility requirements that are not part of a W3C accessibility standard, such as accessibility requirements in Hypertext Markup Language [HTML], or tests in a methodology like RGAA 3 2016. An ACT Rule MUST indicate whether or not the accessibility requirement it maps to is required for conformance in its accessibility requirements document. Examples of accessibility requirements that are not required for conformance are WCAG sufficient techniques, or a company style guide that includes both requirements and optional "best practices". The distinction between what is required and what is optional has to be clear.

Example: Accessibility Requirements Mapping for a rule that tests that each img element has an alt attribute

4.4.3. Rules Without Accessibility Requirements

If the rule does not map to any accessibility requirement, the accessibility requirement mapping will only contain the explainer that it is not required for conformance to the accessibility requirements document. This is common with atomic rules used in composite rules.

Example: An ACT Rule for WCAG 2.1 that tests if role=alert is used to satisfy WCAG 2.1 success criterion 4.1.3 Status Messages:

This rule is not required for conformance to WCAG 2.1 at any level.

If the failed outcome cannot be mapped to an accessibility requirement, there MUST NOT be an accessibility requirement in the accessibility requirements mapping. The optional Background section could be used to list accessibility requirements documents when they are thematically related, but for which the rule is not a failure test.

4.4.4. External Accessibility Requirements Mapping

This section is non-normative.

While rules are often designed for one, or possibly a small collection of accessibility requirements documents, it is likely that other accessibility requirements documents also map to those ACT Rules. For example, rules can be written for the Web Content Accessibility Guidelines [WCAG], but many of those could also map to a company’s internal accessibility policy. In such a scenario, an external accessibility requirements mapping could be created. An external accessibility requirements mapping amends the accessibility requirements mapping of an ACT rule by adding mapping to a different accessibility requirements document. An external accessibility requirements mapping avoids duplication of a rule for the sole purpose of changing the mapping.

4.5. Rule Input

To evaluate content using an ACT Rule, the rule requires some information from the test subject. This is the input for the rule. What input is required is made explicit, to help testers understand what capabilities are required to use a rule. Atomic rules and composite rules have different input.

4.5.1. Input Aspects (Atomic rules only)

An 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 atomic rule. For example, some rules need to operate directly on the Hypertext Transfer Protocol [http11] messages exchanged between a server and a client, while others need to operate on the Document Object Model [DOM] tree exposed by a web browser.

Atomic rules MUST list the aspects used as input for the applicability and expectations of the atomic rule. Rules can operate on several aspects simultaneously, such as both the HTTP messages and the DOM tree. 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, or it can be inferred from a JSX source file. All rules that have only DOM tree as an input aspect can be applied to those technologies.

Some input aspects are well defined in a formal specification, such as HTTP messages, DOM tree, and CSS styling [css-2018]. For these, a reference to the corresponding section in the Common Input Aspects note is sufficient as a description of the aspect. For input aspects that are not well defined, an ACT Rule MUST include either a detailed description of the aspect in question, or a reference to a well defined description.

Example: Input aspects for a rule that checks if a transcript is available for videos:

Example: Input aspects for a rule that checks for use of (language specific) generic link texts like "click here" and "more":

4.5.2. Input Rules (Composite rules only)

A composite rule uses outcomes from atomic rules and applies logic to them so that a single outcome can be determined for each test target. The identifier and descriptive title of all the atomic rules used in the expectations MUST be listed in the composite rule. The input rules describe the input for composite rules, similar to how input aspects describe the input for atomic rules.

4.6. Applicability

The applicability describes what parts of the test subject are tested.

4.6.1. Applicability for Atomic Rules

The applicability section is a required part of an atomic 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 [DOM] tree, or tags that are incorrectly closed in an HTML [HTML] document. These are known as the test targets. The applicability MUST only use information made available through the listed input aspects in the rule. No other information can be used in the applicability. 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 tag names, their computed role, the distance 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. These terms could refer to the tag name, the semantic role, or the element’s purpose on the web page because they are ambiguous. The latter of which is almost impossible to define objectively. When used in applicability, potentially ambiguous concepts MUST be defined objectively. Definitions can be put in the rule glossary, or they can be defined in the section where they are used.

Example: The applicability of an atomic rule testing WCAG 2.1 success criterion 1.4.2 Audio Control:

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.

Note: A web page is considered "loaded" when the document.readyState is set to complete.

Example: The applicability of a rule with the page as a test target

The rule applies to any page where the document element is an html element, and the html element is rendered in a top-level context (i.e. the html element is not embedded in another page, such as through iframe or object elements).

Example: The applicability of a rule with a DOM attribute as a test target

The rule applies to any role attribute that is specified on an HTML or SVG element.

4.6.2. Applicability for Composite Rules

The applicability of a composite rule is defined as the union of all applicability definitions from the rules listed in the input rules. Rule authors MAY omit a description of the applicability for composite rules. This can be useful if it is difficult to express the combined applicability in plain language. If the composite rule includes applicability, it MUST be the union of all the applicability in the input rules.

Note that input rules in a composite rule MAY have different applicability. Because of this, not every test target applicable within the composite rule is tested by every input rule.

Example: A composite rule about img elements uses results from rules that have the following applicability:

The applicability of the composite rule combines the applicability of both rules. This becomes:

All img elements.

4.7. Expectations

An ACT Rule MUST contain one or more expectations. The expectations describe what the requirements are for the test targets derived from the applicability. An expectation is an assertion about a test target. When a test target meets all expectations, the test target passed the rule. If the test target does not meet all expectations, the test target failed the rule. If there are no test targets, the outcome for the rule is inapplicable.

Each expectation MUST be distinct, unambiguous, and be written in plain language.

4.7.1. Expectations for Atomic Rules

All expectations of an atomic rule MUST describe the logic that is used to determine a single passed or failed outcome for a test target. The expectation MUST only use information available in the input aspects, from the applicability, and other expectations of the same rule. No other information can be used in the expectation. So for instance, an expectation could be "Expectation 1 is true and ...", but it can’t be "Rule XYZ passed and ...". This ensures that atomic rules are encapsulated.

Example: A rule to test for accessible names of HTML input elements might have the following expectations:

  1. Each HTML input element has an accessible name (as described in Accessible Name and Description: Computation and API Mappings 1.1). [accname-1.1]
  2. The accessible name describes the purpose of each HTML input element.

Example: A rule to test if a role attribute is valid:

  1. Each role attribute has a value that corresponds to a non-abstract WAI-ARIA 1.1 role.

Note: Rules can be used to do complex aggregation by describing the logic in the expectations. e.g. "The test target (the page) has a text alternative for 80% of all img elements".

4.7.2. Expectations for Composite Rules

All expectations of a composite rule MUST describe the logic that is used to determine a single passed or failed outcome for a test target, based on the outcomes of rules in its input rules. A composite rule expectation MUST NOT use information from input aspects. The outcome for a composite rule is inapplicable when all input rules are inapplicable.

Composite rule: video elements have an audio description or media alternative (WCAG 2.1 success criterion 1.2.3 Audio Description or Media Alternative).

Each HTML video element meets all expectations from at least one of the following rules:

Composite rule: This rule checks that a mechanism is available to escape a keyboard trap. Either through a standard mechanism, or one for which instructions are available.

For each focusable element, the outcome of one of the following rules is passed:

4.8. Assumptions

An ACT Rule MUST list any known assumptions, limitations or any exceptions for the evaluation, the test environment, technologies being used or the subject being tested. For example, a rule that would partially test WCAG 2.1 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 styleable with CSS, and that the rule 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 are "text" or "non-text content" in the Web Content Accessibility Guidelines [WCAG]. Whatever the interpretation is, this MUST be documented in the rule.

While the assumptions MUST be included in the ACT Rule, it MAY be empty when there are no known assumptions, limitations or exceptions.

4.9. Accessibility Support

Content can be designed to rely on the support for particular accessibility features by different assistive technologies and user agents. For example, content using a particular WAI-ARIA 1.1 feature relies on that feature to be supported by assistive technologies and user agents. This content would not work for assistive technologies and user agents that do not support WAI-ARIA. See the WCAG definition for accessibility supported use of a Web technology.

An ACT Rule MUST include known limitations on accessibility support.

Example: A rule that checks if aria-errormessage is used satisfy WCAG 2.1 success criterion 4.1.3 Status messages

The aria-errormessage property is known to have limited support with several major screen readers. This method cannot be relied on for support. Alternatives, like using live regions, may serve as fallback. (January 2019)

While an accessibility support section MUST be included in the ACT Rule, it MAY be empty when there are no known accessibility support issues.

Note: The Website Accessibility Conformance Evaluation Methodology (WCAG-EM) provides guidance on defining an accessibility support baseline for test scenarios, which can help users of ACT Rules to select the appropriate rules for their own circumstance.

4.10. Test Cases

Test cases are (snippets of) content that can be used to validate the implementation of ACT Rules. Each rule MUST have one or more test cases for passed, failed, and inapplicable outcomes. A test case consists of two pieces of data, a snippet of each input aspect for a rule, and the expected outcome for that rule. Test cases serve two functions, firstly as example scenarios for readers to understand when the outcome of a rule is passed, failed, or inapplicable. It also serves developers and users of accessibility testing tools and methodologies to validate that a rule is correctly implemented.

Example: HTML test cases for a rule that checks if img elements have a text alternative.

Example of a passed outcome:

<img alt="W3C Logo" src="image/w3c.png">

Example of a failed outcome:

<img src="image/w3c.png">

Example of an inapplicable outcome:

<input type="image" alt="W3C Logo" src="image/w3c.png">

4.11. Change Log

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, or from changes in the content itself. All changes to an ACT Rule that can change the outcomes of an evaluation 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.

Example: When updating a rule that is about buttons, to now also be about links, menu items and tabs, the buttons rule is deprecated. As a replacement, a new rule is created that is applicable to all those elements.

4.12. Glossary

ACT Rules MUST have a glossary section. The glossary MUST contain the outcome definition, as well as any definitions used in applicability and expectations sections in the rule. Since changes to the definition change the rule, those definitions cannot be maintained independently of the rule. If a shared glossary is used for rules, any definition changes MUST be included in the change log of all rules that use that definition.

4.13. Issues List (optional)

An ACT Rule MAY include a list or a reference to a list of any known issues. The issues list would be used to record cases where an outcome of an ACT Rule was failed where it ought to have been passed or inapplicable, or vice versa. There are several reasons why this might occur. See rule accuracy for more information.

The issues list serves two purposes. For users of ACT Rules, the issues list gives insight into why an inaccurate result occurred, as well as provide confidence in the result of that rule. For the designer of the rule, the issues list is also useful to plan future updates to the rule. In a new version of the rule, resolved issues would be moved to the change log.

4.14. Background (optional)

An ACT Rule MAY contain information about the background for the development of the rule, or references to relevant reading. The relationship to the relevant reading should be specified. Examples of relevant background references for a rule for a Web Content Accessibility Guidelines [WCAG] success criterion could be WCAG 2.1 Understanding documents, WCAG 2.1 Techniques, or WAI-ARIA 1.1, CSS [css-2018], or HTML [HTML] specifications.

4.15. Acknowledgements (optional)

An ACT Rule MAY contain acknowledgements. This can include, but is not limited to:

5. Rule Accuracy

This section is non-normative.

While test cases can be used to determine if an ACT Rule was correctly implemented, they do not guarantee that implementations will never produce incorrect results. When writing ACT Rules, it is almost inevitable that edge cases will be overlooked. Technologies are always evolving, and content authors are constantly coming up with new and unexpected ways to use them. Some examples of causes for inaccuracy are:

There are two types of inaccuracies that can produce incorrect results. Inaccuracies in the implementation can be addressed with test cases, but inaccuracies in the ACT Rule itself cannot. After all, rule inaccuracies come from the rule author being unaware of a particular edge case.

When a test result incorrectly indicates non-conformance to an accessibility requirement, this is known as a false positive. Opposite, when a rule incorrectly indicates conformance, this is a false negative. A percentage of false positives and false negatives can be calculated by comparing it to results from an accessibility audit:

The ever present possibility of false positives and false negatives with ACT Rules mean they will likely require ongoing maintenance. Designing a process for maintaining ACT Rules is outside the scope of the ACT Rules Format, which is limited to the rules themselves. Nevertheless, it is suggested that rule authors work out a process for maintaining their rules.

6. Harmonization

This section is non-normative.

While the ACT Rules Format is designed to stimulate harmonization, there are no direct requirement in the ACT Rules Format that prevent a rule author from writing rules inconsistent with already established ACT Rules. Neither are there requirements for ACT Rules to have a certain number of implementations, or to have a certain level of accuracy. This allows quality requirements to be different for different rulesets, and allows them to develop over time.

Harmonization occurs when a group of rule implementors collectively accept the validity of an ACT Rule. For example, a community group of accessibility testing tool vendors could declare they have harmonized on a particular set of ACT Rules. Such a group can set acceptance criteria for rules, and have quality requirements that go beyond the ACT Rules Format.

Example: The ACT EPUB group might have the following acceptance criteria:

An example of such a process is the WCAG ACT Review Process.

7. Definitions

Accessibility requirement

A requirement is a condition that has to be satisfied in order to conform to a standard, or to comply with a contract, policy or regulation. An accessibility requirement is a requirement aimed at improving access for people with disabilities to an ICT product.

A common example of accessibility requirements are the WCAG success criteria. There are other standards, including W3C standards, that have recommendations for accessibility, such as WAI-ARIA and HTML. Accessibility requirements are also often found in company policies, regional standards or in legislation.

Accessibility requirements document

A document, such as a standard, contract, policy or regulation, that includes accessibility requirements. For example, WCAG 2.1, WAI-ARIA 1.1, HTML 5.2, EPUB Accessibility 1.0, BBC HTML Accessibility Standards v2.0


A conclusion that comes from evaluating an ACT Rule on a test subject or one of its constituent test target. An outcome can be one of the three following types:

  • Inapplicable: No part of the test subject matches the applicability
  • Passed: A test target meets all expectations
  • Failed: A test target does not meet all expectations

Note: A rule has one passed or failed outcome for every test target. When there are no test targets the rule has one inapplicable outcome. This means that each test subject will have one or more outcomes.

Note: Implementers using the [EARL10-Schema] can express the outcome with the outcome property. In addition to passed, failed and inapplicable, EARL 1.0 also defined an incomplete outcome. While this cannot be the outcome of an ACT Rule when applied in its entirety, it often happens that rules are only partially evaluated. For example, when applicability was automated, but the expectations have to be evaluated manually. Such "interim" results can be expressed with the incomplete outcome.

Test Subject

A resource or collection of resources that can be evaluated by an ACT Rule.


  • An HTML page, including all embedded scripts, style and images
  • An EPUB publication
  • A Vue component file

Note: Implementers using the [EARL10-Schema] can express the test subject with the subject property

Test Target

A distinct part of the test subject, as defined by the applicability.


  • Nodes within an HTML page
  • A period of time within a video
  • A range of characters within a text document

Note: Implementers using the [EARL10-Schema] can express the test target with the pointer property

Appendix 1: Expressing ACT Rule results with JSON-LD and EARL

This section is non-normative.

Example 1: Output data using EARL and JSON-LD. (See Evaluation and Report Language [EARL10-Schema] and Java Script Object Notation (JSON).)

	 "@context": "https://raw.githubusercontent.com/w3c/wcag-act/master/earl-act.json",
	 "@type": "Assertion",
	 "subject": "https://example.org/",
	 "test": "auto-wcag:rules/SC1-1-1-css-image.html",
	 "result": {
		 "outcome": "earl:failed",
		 "pointer": "html > body > h1:first-child"

Example 2:

	 "@context": "https://raw.githubusercontent.com/w3c/wcag-act/master/earl-act.json",
	 "@graph": [{
		 "@type": "Assertion",
		 "subject": "https://example.org/",
		 "test": "auto-wcag:SC1-1-1-css-image.html",
		 "result": {
			 "outcome": "earl:failed",
			 "pointer": "html > body > h1:first-child"
	 }, {
		 "@type": "Assertion",
		 "subject": "https://example.org/",
		 "test": "auto-wcag:SC1-1-1-css-image.html",
		 "result": {
			 "outcome": "earl:passed",
			 "pointer": "html > body > h1:nth-child(2)"

Example 3: Aggregate outcomes to a WCAG success criterion

	 "@context": "https://raw.githubusercontent.com/w3c/wcag-act/master/earl-act.json",
	 "@type": "Assertion",
	 "subject": {
		 "@type": ["WebSite", "TestSubject"],
		 "@value": "https://example.org/"
	 "test": "http://www.w3.org/WAI/WCAG2A-Conformance",
	 "result": {
		 "outcome": "earl:failed",
		 "source": [{
			 "test": "wcag20:text-equiv-all",
			 "result": {
				 "outcome": "earl:failed",
				 "source": []
		 }, {
			 "test": "wcag20:media-equiv-av-only-alt",
			 "result": {
				 "outcome": "earl:passed",
				 "source": []
		 }, {
			 "test": "wcag20:media-equiv-captions",
			 "result" : {
				 "outcome": "earl:inapplicable",
				 "source": []

Example 4: Aggregate a list of results to a result for the website

	 "@context": "https://raw.githubusercontent.com/w3c/wcag-act/master/earl-act.json",
	 "@type": "Assertion",
	 "subject": {
		 "@type": ["WebSite", "TestSubject"],
		 "@value": "https://example.org/"
	 "test": "http://www.w3.org/WAI/WCAG2A-Conformance",
	 "result": {
		 "outcome": "Failed",
		 "source": [{
			 "test": "wcag20:text-equiv-all",
			 "result": {
				 "outcome": "Failed",
				 "source": []
		 }, {
			 "test": "wcag20:media-equiv-av-only-alt",
			 "result": {
				 "outcome": "Passed",
				 "source": []
		 }, {
			 "test": "wcag20:media-equiv-captions",
			 "result" : {
				 "outcome": "Inapplicable",
				 "source": []

Appendix 2: Acknowledgments

This section is non-normative.

Participants of the AG WG active in the development of this document

Shadi Abou-Zahra, Trevor Bostic, Romain Deltour, Kathy Eng, Wilco Fiers, Alistair Garrison, Kasper Isager, Maureen Kraft, Mary Jo Mueller, Jey Nandakumar, Charu Pandhi, Stein Erik Skotkjerra, Anne Thyme Nørregaard, Kathleen Wahlbin

Enabling funders

This publication has been developed with support from the WAI-Tools Project, co-funded by the European Commission (EC) under the Horizon 2020 Program (Grant Agreement 780057). The content of this publication does not necessarily reflect the views or policies of the European Commission (EC) or any of the European Union (EU) Member States.

Appendix 3: Change History

The following updates have been made since the last public working draft:

All changes from the previous published version can be viewed using the July 2018 to this April 2019 diff link

Appendix 4: Exit Criteria


Accessibility requirements mapping

Each rule implemented in plain English form, as listed below:

Rule Input




Accessibility Support



Issues list

Test cases



Implementations and data format


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.


Terms defined by this specification


Normative References

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

Joanmarie Diggs; Bryan Garaventa; Michael Cooper. Accessible Name and Description Computation 1.1. 18 December 2018. REC. URL: https://www.w3.org/TR/accname-1.1/
Tab Atkins Jr.; Elika Etemad; Florian Rivoal. CSS Snapshot 2018. 22 January 2019. NOTE. URL: https://www.w3.org/TR/css-2018/
Anne van Kesteren. DOM Standard. Living Standard. URL: https://dom.spec.whatwg.org/
Shadi Abou-Zahra. Evaluation and Report Language (EARL) 1.0 Schema. 2 February 2017. NOTE. URL: https://www.w3.org/TR/EARL10-Schema/
Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. June 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7230
Amelia Bellamy-Royds; et al. Scalable Vector Graphics (SVG) 2. 4 October 2018. CR. URL: https://www.w3.org/TR/SVG2/
James Allan; et al. User Agent Accessibility Guidelines (UAAG) 2.0. 15 December 2015. NOTE. URL: https://www.w3.org/TR/UAAG20/
Joanmarie Doggs; et al. Accessible Rich Internet Applications (WAI-ARIA) 1.1. 14 December 2018. REC. URL: https://www.w3.org/TR/wai-aria/
Andrew Kirckpatrick; et al. Web Content Accessibility Guidelines 2.1. 5 June 2018. REC. URL: https://www.w3.org/TR/WCAG/