Accessibility Use Case Definition Language (UCDL) and Runner

This section is informative.

Use case testing, as practiced by AFixt, is the act of acting out a specific, goal-oriented workflow against a system in order to determine whether the workflow can be completed accessibly. It is distinct from automated rule checking (which finds code-level violations of a checklist) and from usability testing (which observes naive users' behavior). Use case testing is performed by an expert who is given a script and asked: can this script be performed, and, if so, with how much friction?

The premise of this specification is that the script the human tester executes can be expressed precisely enough to be replayed by a browser automation engine, provided that the script's targeting language is accessibility-first. A step that says "locate the button labeled 'Sign Up'" maps directly onto an assertion that the accessibility tree contains a button whose accessible name is "Sign Up". If no such button exists, both the human tester and the automated tester fail in the same way and for the same reason. The fidelity between the manual script and the automated script is the central design constraint of UCDL.

This specification standardizes that fidelity. It defines the file format, the verbs, the semantics of each verb, the resolution model for targets, and the shape of the resulting test artifacts.

• Fidelity. A use case document SHALL describe a workflow in terms a human tester can follow without a developer's help.
• Determinism. Two conforming processors SHALL produce equivalent test artifacts from the same input document.
• Accessibility-first targeting. The DSL SHALL NOT provide CSS or XPath affordances. Targets are identified by role and accessible name.
• Round-trippability. The same document MUST be executable in either of two modes (codegen or direct execution) without behavioral divergence.
• Reportable. Results MUST be expressible in the same step/comments rubric used by AFixt for manual use case reports, so that automated and manual results are mergeable.

• General-purpose end-to-end testing. Although largely usable for such a purpose, UCDL is deliberately narrow.
• A replacement for automated rule-based scanners. The audit keyword delegates to an accessibility testing engine, but the rest of the language is about workflow conformance, not rule conformance.
• A test runner. Conforming processors emit Playwright artifacts and/or invoke Playwright directly; UCDL does not redefine browser automation.