passed
All expectations met
A tested target meets every expectation. Read the rule’s mapping before drawing a conclusion about a requirement.
ACCESSIBILITY CONFORMANCE TESTING
Make testing
reproducible.
Explore ACT Rules Format 1.1: how to describe a test, select the right targets and interpret its evidence. Connect the rule you run to the conclusion you can support.
ACT RULES FORMAT 1.1
W3C Recommendation
5 February 2026
Source checked 15 September 2026
A format for writing accessibility test rules, used by automated tools and manual methods.
Version 1.1 adds conformance/secondary mappings and permits subjective applicability. It is not fully backward-compatible with 1.0.
Read the dated standard →The rule, the check and the result
- Describe the testACT makes its inputs, applicability, expectations and assumptions explicit.
- Implement the checkA tool, a manual procedure or both gather the evidence.
- Interpret the outcomeUse the requirement mapping and preserve the scope and uncertainty.
This is an independent learning companion for rule authors, implementers and evaluators who want to understand their methods. A passing rule is not a whole-site conformance result. Keep the rule’s evidence alongside manual review and a coverage plan. The 20 topics and six cases below are original learning material, not a replacement technical specification or a complete ruleset.
A SHARED VOCABULARY / FIVE OUTCOMES
Separate failure, uncertainty and missing work
failed
An expectation is not met
A tested target does not meet all expectations. The effect on a requirement depends on the mapping and scope.
inapplicable
No matching targets
The subject was checked for applicability and no part matched. This is not a general accessibility pass.
cantTell
Evidence is insufficient
Applicability or the expectations could not be fully determined. Record the evidence or judgment still needed.
untested
Evaluation has not happened
The subject was not evaluated for this rule. A queued or skipped check has not produced accessibility evidence.
Read the normative outcome definition · Represent evidence in EARL
LEARN BY DOING / ORIGINAL TEACHING MODEL
From observations to a defensible outcome
Choose a fictional case, then change the recorded observations. This lab models one subject with zero or one target. It does not inspect a webpage or perform an accessibility evaluation. Several targets require separate outcomes.
Observations changed from the worked case. The explanation below follows your current selections.
Expectations can be assessed when a matching target is established.
Kept in this tab only. Export the study note if you want to keep it.
CURRENT TEACHING RESULT
What the mapping supports
This result follows your selections. It does not assert that the case, a real document or a website conforms to WCAG.
Read all six worked cases
A button has a name
A fictional checkout page contains one applicable native button. Inspection confirms its computed accessible name is “Place order.” The teaching check asks whether that button has a non-empty accessible name. Its declared conformance mapping still requires further testing after a passed result.
Worked reasoning
Outcome: passed. The one target meets the naming expectation. That does not evaluate every aspect of WCAG 4.1.2 or other controls.
A button has no name
The same single-button fixture is inspected, but the applicable button has an empty computed accessible name. Its naming expectation is not met. The teaching check declares a conformance mapping for the naming requirement.
Worked reasoning
Outcome: failed. The target does not meet the expectation. Under the declared conformance mapping, the mapped requirement is not satisfied for this subject.
There are no matching controls
A fictional text-only document is evaluated against the same button-naming check. Applicability has been determined, and it contains no targets. The declared mapping requires further testing when the rule is inapplicable.
Worked reasoning
Outcome: inapplicable. No targets match this rule. The document may still contain unrelated barriers; this is not a page-level pass.
A possible visual heading
A reviewer sees text that might be styled as a heading, but the necessary visual context is missing. The rule’s defined subjective applicability cannot yet be determined.
Worked reasoning
Outcome: cantTell. Uncertainty in applicability is enough for cantTell. Do not guess that the rule is inapplicable or that the target failed.
The check is queued
An evaluator adds a document-language check to a review plan, but neither applicability nor expectations have been evaluated. Scheduling a check does not perform the evaluation.
Worked reasoning
Outcome: untested. No evaluation occurred. Record untested, then schedule the work instead of turning a missing finding into passed.
A narrow requirement is fully checked
A fictional course policy requires its one lesson document to have a non-empty title. The whole narrow requirement is evaluated and met. This teaching rule declares itself a satisfying test for that policy requirement. It is not a claim about all WCAG title requirements.
Worked reasoning
Outcome: passed. All required evidence for the stated narrow policy requirement is available. This declared satisfying-test mapping supports satisfaction of that requirement only.
FIND / UNDERSTAND / APPLY
The rule anatomy reference
Twenty source-linked topics cover the format, interpretation and implementation. Expand a topic for a review activity or example. These are original explanations; use the linked W3C sections for normative wording and qualifications.
20 reference topics.
No matching topics
Try a shorter phrase, select another area or reset the search.
FOUNDATIONS / SECTION 3
Atomic and composite rules
An atomic rule checks one condition using information from the test subject. A composite rule combines outcomes from named atomic rules. Composite rules cannot take other composite rules as inputs.
Understand and apply
Keep the responsibilities clear: atomic expectations inspect declared input aspects; composite expectations inspect input-rule outcomes. The applicability of a composite is the union of its atomic inputs. Every target does not have to be applicable to every input rule.
Review activity: draw the dependency tree. If a composite depends on another composite, list the underlying atomic inputs directly and explain how their outcomes are combined.
FOUNDATIONS / SECTION 9
Test subject and test target
The subject is the resource or collection being evaluated. A target is the distinct part selected by the rule’s applicability. A page may contain many targets, or none for a particular rule.
Understand and apply
A target can be a node, a text range, a period within media or the page itself. Preserve the subject’s identity and the target location in evidence. Do not substitute a count of targets for the rule’s actual expectation.
Example: a checkout page is the subject; each applicable button is a target. Testing the purchase button alone does not describe every control on that page.
FOUNDATIONS / SECTION 9
Five outcomes, different meanings
ACT defines passed, failed, inapplicable, cantTell and untested. A target passes when it meets all expectations and fails when it does not. Uncertainty and absence of testing have their own outcomes.
Understand and apply
When there are no targets, the rule has one inapplicable outcome for the subject. If applicability cannot be determined, report cantTell. A subject that has not been evaluated is untested. With multiple targets, retain each result rather than hiding mixed outcomes in a single score.
Review activity: find a report that labels a skipped manual check “pass.” Correct the outcome and record what evidence is still needed.
WRITING RULES / SECTION 4.1
Descriptive title and stable identifier
Give the rule a title people can understand and an identifier unique within its ruleset. Keep the identifier stable as the rule is updated, and distinguish its version from its identity.
Understand and apply
A new release needs a date or version number and a route to the previous version. Substantial changes to what a rule tests call for a new rule and identifier, with the old one deprecated.
Example: extending a rule from buttons to every interactive role changes its scope. Record that as a deliberate rule change rather than silently replacing an implementation.
WRITING RULES / SECTION 4.2
Plain-language description and rule type
Explain briefly what the rule tests, then identify it as atomic or composite. The description includes language and base-direction metadata so it can be presented and translated correctly.
Understand and apply
The description introduces the task; applicability and expectations provide the precise procedure. A friendly title cannot compensate for an ambiguous selection rule or an unstated expectation.
Review activity: ask another tester to restate the rule’s purpose before seeing the implementation. Compare their understanding with its actual scope.
REQUIREMENTS MAPPING / SECTION 4.4
Map the requirement, document and level
A requirements mapping identifies the requirement, its document and reference, any level, and whether it is a conformance or secondary requirement. Each conformance mapping explains the meaning of the rule’s outcomes.
Understand and apply
Rules may map beyond WCAG. Distinguish a requirement necessary for conformance from an optional technique or house recommendation. If no failure maps to an accessibility requirement, state that rather than inventing a conformance link; thematic references can remain in Background.
Review activity: inspect a tool’s WCAG label. Can you trace its result to the exact rule, requirement, document version and outcome mapping?
REQUIREMENTS MAPPING / SECTION 4.4.1.1
Conformance requirements and satisfying tests
For a conformance requirement, any failed outcome means that requirement is not satisfied for the subject. Passed or inapplicable outcomes can still require further testing; use the declared mapping.
Understand and apply
A satisfying test is one whose all-passed outcomes establish satisfaction of the particular mapped requirement. That is narrower than conformance of a complete page or website. Read the separate mapping for inapplicable outcomes rather than inferring it from “satisfying test.”
Example: all checked image buttons have names. This can pass a naming rule while other non-text content or control behavior still needs evaluation.
REQUIREMENTS MAPPING / SECTION 4.4.1.2
Secondary does not mean optional
A secondary mapping records a related requirement that this rule was not designed to test, or one for which failure still needs further investigation. Explain why the relationship is secondary.
Understand and apply
A stricter or less strict requirement may be related to the rule without having the same result. Secondary describes the mapping relationship; it does not change whether the requirement is mandatory in its own standard. Accessibility-support differences alone cannot justify making a designed-for requirement secondary.
Example: a rule designed for minimum text contrast may also relate to enhanced contrast. Passing the minimum rule cannot establish that the enhanced requirement is satisfied.
WRITING RULES / SECTION 4.5
Declare what the rule uses as input
Atomic rules list input aspects such as the DOM, CSS, visual or audio output. Composite rules list the identifiers and descriptive titles of atomic rules whose outcomes they use.
Understand and apply
Applicability and expectations cannot quietly depend on undeclared information. Define unfamiliar aspects, or reference a precise definition. A DOM-only implementation cannot claim to have made a judgment that requires visual context unless that input is part of the check.
Review activity: annotate each decision with its required evidence. Separate data available to automation from evidence a human must provide.
WRITING RULES / SECTION 4.6
Select targets without hiding uncertainty
Applicability says exactly which parts of the subject are tested. It must be unambiguous. Objective, plain-language descriptions are preferred; version 1.1 also permits subjective applicability where an objective definition is impossible.
Understand and apply
Define terms such as “styled as a heading” in context. Where possible, separate objective and subjective selection into atomic rules. A composite’s applicability is the union of its inputs and can omit a written description, but any description it supplies must match that union.
Example: “all images” leaves tag name, computed role and purpose unclear. State which concept selects the target and how the tester determines it.
WRITING RULES / SECTION 4.7
State what a target must meet
Every rule has one or more distinct, unambiguous expectations in plain language. Meeting all expectations produces passed for a target; not meeting all produces failed. No targets produces inapplicable.
Understand and apply
Atomic expectations can use declared aspects, applicability and other expectations in the same rule. Composite expectations use only input-rule outcomes. If the available evidence cannot determine applicability or all expectations, cantTell preserves that uncertainty.
Review activity: write down the evidence that proves each expectation and one example that violates it. Avoid mixing a target’s eligibility with the condition being tested.
WRITING RULES / SECTION 4.8
Assumptions and accessibility support
The Background includes Assumptions and Accessibility Support sections. Record known limitations, exceptions and interpretation choices; these sections can be empty when nothing is known.
Understand and apply
Document known browser and assistive-technology support limitations with the relevant context. Related rules, other resources and acknowledgments can add context. A source note about an older software version is evidence about that version, not a timeless support claim.
Example: a CSS-based contrast check records that it does not assess images of text. A reviewer can then identify the coverage that needs another method.
IMPLEMENTATION / SECTION 4.9
Examples make a rule testable
Each rule needs examples for passed, failed and inapplicable outcomes. An example pairs relevant input-aspect snippets with the expected outcome so readers and implementers can check their interpretation.
Understand and apply
Passed and inapplicable examples must satisfy every conformance requirement mapped by the rule; failed examples must not satisfy those requirements. Composite rules also impose these conditions on examples of their inputs. The rule document itself must be accessible; risky non-interference examples need advance warnings.
Review activity: check that a fixture’s expected result comes from the rule text, and that an unrelated error is not accidentally determining its outcome.
MAINTENANCE / SECTION 4.10–4.11
Rule version and format version
The rule’s version tracks changes to the test. Its ACT Rules Format version says which format requirements it follows. Preserve or reference earlier rule versions so changed results can be investigated.
Understand and apply
ACT Rules Format 1.1 is not fully backward-compatible with 1.0. Both versions coexist. An optional issues list can record known inaccurate results and link their resolution to a later release.
Example: a finding changes after a tool upgrade. Compare the content, rule version, definition versions and implementation before deciding that the page regressed.
WRITING RULES / SECTION 4.12
Definitions are part of the rule
The glossary includes the outcome definition and terms used by applicability and expectations. A definition change can change the test even when its main prose is untouched.
Understand and apply
When shared definitions change, rules using them need new versions. If an external definition can change independently, identify the version or date used. Linking only to a moving specification can leave future readers unable to reproduce the original interpretation.
Review activity: pick a term that selects targets. Follow its definition and record whether the reference identifies the version actually used by the test.
IMPLEMENTATION / SECTION 4.14
Rule and implementation are different
An implementation is a tool or testing methodology. Its checks may be automated, manual or a mixture. A single check can correspond to multiple rules, and several checks can jointly implement one rule.
Understand and apply
If listing implementations, identify the checks, modes, tool version and their consistency or partial consistency. A claim about an implementation’s behavior is evidence about that implementation, not a change to the ACT rule.
Example: automation identifies candidate media and a reviewer judges whether an alternative conveys the relevant information. Describe both contributions to the final result.
IMPLEMENTATION / SECTION 4.14.1–4.14.3
Consistency is more than matching a percentage
ACT consistency checks correct treatment of examples, completeness and requirements mapping. It has specific conditions; “most examples passed” is not the definition.
Understand and apply
The consistency procedure prohibits certain incorrect outcomes, disallows untested results for a consistent check and requires at least one failed example to be detected. Partial consistency and sets of checks have their own conditions. Use the source procedure before publishing a consistency claim.
Review activity: inspect false positives and missed failures separately. Keep cantTell and untested visible instead of counting them as successes.
IMPLEMENTATION / SECTION 5
Investigate disagreement and inaccurate results
A repeatable rule can still have assumptions, coverage limits or interpretation errors. Compare evidence and definitions before deciding whether disagreement comes from content, the rule or its implementation.
Understand and apply
Record a small reproducible example, expected and observed outcomes, the rule and implementation versions, environment and relevant mapping. Separate a rule defect from an implementation defect so a correction reaches the right place.
Example: two tools disagree about one button. Check that both selected the same target in the same state and computed its name with the same assumptions.
MAINTENANCE / SECTION 6
Reuse and compare published rules
Shared rule descriptions help different tools and manual methods interpret requirements consistently. Evaluate an existing rule’s scope and assumptions before creating another test for the same issue.
Understand and apply
Distinguish the Rules Format Recommendation, individual published rules and community-contributed candidates. A ruleset is not a complete testing strategy. Integrate appropriate rules with manual review, real tasks and a documented coverage plan.
Review activity: compare two checks for the same requirement using a common fixture set. Trace differences to applicability, expectations, assumptions or mapping.
MAINTENANCE / SECTION 7–8
Keep test evidence useful and controlled
Accessibility evidence can contain personal information, authenticated URLs, screenshots and page content. Plan what a report needs and who may receive it before exporting or sharing results.
Understand and apply
Treat externally supplied test content as untrusted. Avoid rendering unsafe examples inside an ordinary learning page, and do not collect credentials merely to explain a rule. This companion uses fictional facts and local form state; it does not fetch or scan a user-entered page.
Review activity: remove tokens, personal records and unnecessary screenshots from a reproducible example. Retain enough context to investigate the accessibility finding safely.
A COMPOSITE RULE / READ ITS ACTUAL LOGIC
Combine solutions without inventing a score
A worked “either solution” example
An original teaching composite declares that a shared target meets its expectation when at least one of two atomic solution checks passes. If the first fails and the second passes, that declared expectation is met. Counting the failed input alone would lose the alternative solution.
If no input applies, the composite is inapplicable. Its applicability is the union of its inputs. If evidence is incomplete, preserve that limitation and follow the rule’s logic; do not treat missing results as passes.
Keep direct inspection in atomic rules
A composite reads input-rule outcomes. It cannot quietly inspect extra DOM properties to decide its result. All its input rules must be atomic; a composite cannot be nested inside another composite.
One tool check can implement multiple rules, or several checks can implement a rule together. That implementation detail does not change the distinction between an atomic rule and a composite.
Use ACT in a real evaluation workflow
- Choose a scope and baseline. Record the pages, states, tasks, technologies and environments under review. Identify coverage that requires other rules or methods.
- Select and read the rule. Verify its version, applicability, mapping, assumptions and support notes. Distinguish a W3C-published rule from a community candidate.
- Check the implementation. Compare the method against the rule’s examples and consistency conditions. Document manual steps and incomplete evidence.
- Keep target-level evidence. Record which rule ran, where, when, with what outcome and why. Preserve cantTell and untested work in the plan.
- Report supported conclusions. Interpret each mapping, retest fixes and combine evidence with the wider evaluation. Use EARL to explore structured reporting.
Source, status and learning scope
This companion explains Accessibility Conformance Testing (ACT) Rules Format 1.1, W3C Recommendation 5 February 2026. Source checked 15 September 2026. See the latest published format, WAI ACT overview, published rules and informative EARL / JSON-LD appendix.
Original A11y.mv explanations, review activities and fictional teaching cases, informed by ACT Rules Format 1.1 (https://www.w3.org/TR/2026/REC-act-rules-format-1.1-20260205/). W3C source: Copyright © 2026 World Wide Web Consortium. Copyright © 2023 W3C®. This software includes material derived from Accessibility Conformance Testing (ACT) Rules Format 1.1, W3C Recommendation 5 February 2026. W3C Document License. This independent learning application is not an official W3C technical specification. Its scenarios, outcomes and counts do not certify a rule implementation or a website.