This library provides test procedures and record structures. It does not certify products, determine legal compliance or make a product-wide accessibility claim merely because a procedure or sample passed.
Three testing layers
Atomic conformance checks
An atomic check addresses one precise condition. Its result applies only to the recorded target, state, technology and environment. Where an approved ACT Rule is used, its outcome is supporting evidence for the rule’s exact applicability and expectation; it does not automatically satisfy the whole WCAG success criterion.
Composite and criterion-level assessments
A composite procedure combines named atomic results. It records what the checks cover, what remains manual, the technologies evaluated and the aggregation logic. A WCAG decision requires the complete criterion scope, applicable exceptions, conformance requirements and any conforming alternate version to be considered.
Assistive-technology and user journeys
A journey examines task completion, announcements, focus management, discoverability, interruption and recovery in a named platform combination. It can reveal an issue and support a criterion investigation. It does not silently become a WCAG conformance result and one environment does not represent every environment.
Target outcomes
Rule and target outcomes use the ACT Rules Format 1.1 vocabulary:
passed: the applicable target meets every expectation evaluated by the procedure.failed: the applicable target fails at least one expectation evaluated by the procedure.inapplicable: the target does not meet the rule’s applicability. Evidence must show why.cantTell: the target is applicable, but available evidence cannot support a defensible passed or failed decision.untested: the target or a required state or environment was not evaluated.
blocked is not a target outcome.
Execution states
Operational progress is recorded separately as not_started, in_progress, completed, blocked or aborted. A blocked record identifies what prevented testing, the affected scope, another environment attempted, who may resolve the block and whether testing remains required. A blocked execution retains an untested target outcome unless a target was actually exercised and produced another independently supported result.
WCAG requirement decisions
Report-level WCAG decisions are satisfied, not_satisfied, not_evaluated and cannot_determine. They are not ACT outcomes. A success criterion with no applicable content is satisfied for WCAG conformance purposes even though an atomic rule may be inapplicable. A criterion decision must never be inferred solely from schema validity, automation, an ACT pass or a journey pass.
Optional buyer-owned automation records a separate run_status: completed means the bounded local adapter completed; blocked means a required capability or evidence boundary stopped the run. The step-derived rule outcome remains separate. For example, a diagnostic observation set may be cantTell while the run is blocked. Automation does not approve a claim, replace competent review or require a seller-hosted service.
Claim readiness
Claim readiness is independent of all three models above:
not_readyready_for_reviewreviewed_with_limitationsready_for_scoped_claim
The browser worksheet always exports not_ready. Testers cannot select claim readiness. Agent verification may validate the recorded evidence and decision, while formal claim readiness changes only after all applicable real-platform, participant, legal and organisational gates and an authorised approval recorded in the purchased edition's governance register.
Authoring readiness
Procedure authoring readiness is separate from governance status:
needs_revision: the procedure still has a known authoring defect.content_complete: required content fields are complete, but the procedure is not yet packaged for review.ready_for_agent_verification: the procedure is packaged for the repository's deterministic internal review passes.
Authoring readiness never changes draft to in_review, reviewed or approved.
Assessment workflow
1. Define the evaluation goal, frozen product version, scope and claim boundary. 2. Inventory the known population before sampling. 3. Select common and unique content, essential functions, complete processes, states, responsive variations, languages and required environments. 4. Record the accessibility-support baseline and known platform limitations. 5. Calibrate the test environment with the version-frozen known-good fixtures. 6. Execute atomic checks for every selected target and required state. 7. Execute composite assessments without hiding unresolved atomic coverage. 8. Execute separately labelled platform and user journeys. 9. Preserve target outcomes, execution states, WCAG decisions and claim readiness separately. 10. Reconcile issues, evidence, exclusions, incomplete work and changes to scope. 11. Obtain independent review and authorised governance approval where a scoped claim is proposed.
Regional assurance workflow
Regulatory assessment starts with applicability, not an edition label. Complete the Regulatory Applicability Profiler and engagement intake before selecting one or more dated profiles. The suite includes separate profiles for WCAG 2.2 and ACT, Section 508 web/software, documents and procurement, ADA Title II, EAA, EU WAD and EN 301 549, UK public-sector requirements, Canadian federal ICT and Ontario AODA.
WCAG results remain versioned. Non-WCAG EN 301 549, Section 508, statement, exemption, support and EAA sector requirements are not inferred from a WCAG pass. Legal applicability, exceptions, burden, local transposition and conformity decisions remain authorised human decisions.
Engagements record selected profile IDs and source versions in the applicability decision, coverage matrix and client deliverables. The profile controls resolve into scoped test methods and separately tracked legal or organisational decisions. Completed examples demonstrate WCAG product assessment, Section 508 procurement, EAA e-commerce and public-sector statement workflows without presenting fictional results as professional advice.
Scope definition, profile setup and result administration are shared workflow activities. They do not appear as repeated fake test steps. A procedure step exists only when it tells the tester how to create a method-specific observation or decision.
Browser worksheet flow
The initially visible worksheet asks what was tested, the optional scenario or state, the tester-facing result and what was observed. The result control maps to separate execution-state and rule-outcome values in the exported record: final outcomes remain an in-progress draft unless the tester deliberately marks the execution complete. Blocked and not-applicable reasons appear only when selected. Evidence, the reusable environment profile, component expectations, assistive-technology attestations, WCAG report decisions, limitations, completion and destructive data actions are grouped as secondary details.
Use WCAG-EM 1.0 as stable informative guidance for website evaluations. WCAG-EM 2.0 is a W3C Group Note Draft and may be used only as clearly labelled draft input for broader digital-product methodology.
Automation and accessibility trees
Automation is diagnostic unless a procedure states a narrower defensible result. It cannot evaluate every semantic, contextual, perceptual, interaction or usability requirement. An accessibility-tree inspection or simulated screen reader is not evidence of real assistive-technology execution.
Disabled-user evaluation
Evaluation with disabled people can reveal barriers missed by conformance tests. A small participant group cannot represent all disabled people, and user evaluation alone does not establish WCAG conformance. Keep standards findings and user-study findings separate while linking evidence where useful. Record objective, relevant participant characteristics, recruitment and consent, tasks, environment, facilitation, collected data, limitations, privacy and retention.
Responsibility and uncertainty
Record observed behaviour before assigning responsibility. A defect may belong to the product, user agent, operating system, assistive technology, document tool or configuration. Use cantTell when responsibility or applicability cannot be defensibly resolved. Do not turn a platform limitation into a product failure without evidence, and do not use a platform limitation to hide a reproducible product failure.