Accessibility Use Case Definition Language (UCDL) and Runner

This section is normative.

The overall score for a use case execution is one of four values, computed from the step results of the main steps.

A before block (§4.6) contributes in exactly one way: if any of its entries failed, the score is error and the rows below do not apply. Notes and skips recorded against before entries are reported in before_results (§10.1) and do not affect the score, because they describe setup rather than the behaviour under test — the same separation §4.6 rule 3 requires of the report. The overall score for a use case execution is one of five values, computed from the step results — those of the main steps, together with those of any before block (§4.6).

error is distinct from fail: the use case did not get far enough to be judged, so its main steps carry no evidence either way. It is reported and gated (§14.1) alongside fail, but MUST NOT be presented as a completed run that found a defect.

Step skips arise when continue_on_failure: false truncates execution after a failure, and in the before block (§4.6), which halts after a failure whatever continue_on_failure is set to. accessibility_notes arise from low-priority audit issues and from runtime warnings the processor wishes to surface.

The score MUST be computed from those step results alone, together with whether the before block failed. Processors MUST NOT alter the score based on factors outside them (e.g., elapsed wall-clock time, browser version).

For iterated use cases (§5.8), the flat step_results list — concatenated across all iterations — is the input to the scoring algorithm above. This means:

• A use case with at least one failing iteration has overall score fail.
• A use case whose for_each resolves to zero elements scores inapplicable: iteration_summary.total is 0 and iteration_summary.inapplicable is 1. It is not a pass — no assertion was evaluated, and folding it into pass would mean a report improves as coverage is removed.

Step outcomes. A step result MAY carry an outcome alongside status: passed, failed, inapplicable or cannot_determine. status answers whether the step failed the run; outcome answers what it established. They come apart for the delegating verbs — a lang_check on a page with no declared lang has nothing to compare, and a read_image that extracted no text has no evidence either way. A processor MUST report inapplicable where a verb completed without evaluating anything, and SHOULD report cannot_determine where the evidence itself was insufficient. Absent, outcome follows status.

Score-affecting notes. Only notes from an enumerated source change the score: low-priority audit issues (§9.5), contrast skips (§9A.1), and escape-hatch targets (§5.4.2). Notes from any other source are informative and MUST NOT change it. A processor that could raise a score by adding a warning would make identical page behaviour score differently across versions.

inapplicable gates nothing: the exit code for a run of inapplicable cases is 0 (§14.1). What it carries is that coverage is missing, which is a fact for a reader to act on rather than a pipeline failure.

The mapping to AFixt's manual scoring labels is: