Worked checkout example · WCAG Grammar

This material is a specification and reference set. It is not an accessibility scanner, a legal opinion, a certification, or evidence of a completed audit. Sample observations are explicitly untested, and WCAG 3 is draft guidance rather than the target here.

Worked example — checkout validation

Illustrative scenario only. No website was inspected or tested for this example.

Assume a checkout silently rejects a missing postal code, outlines the field in red, clears the address and leaves the user uncertain about whether an order was placed. The observations below are hypothetical design inputs, not collected evidence.

LAKA record

Variable	Scenario definition
Object	Address form, submission feedback and checkout process.
Conditions	Missing postal code; narrow viewport; keyboard or screen-reader interaction.
Actions	Enter address, submit, identify the error, correct it and continue.
Tools	Existing form primitives, browser test runner and actual assistive-technology review.
Resources	Synthetic address, payment sandbox, requirements reviewer and test evidence store.
Outcomes	User identifies the field and correction, then completes the intended step.
Feedback	Specific error explanation, linked correction path and verified post-repair regression.
Constraints	Privacy, data validation, transaction integrity and integration behavior.
Value	Independent completion without unexplained failure or unnecessary re-entry.
Failure mode	Color-only feedback, lost input, inaccessible correction or ambiguous transaction state.

Requirement decomposition

An identified textual error maps to SC-3.3.1; correction guidance maps to SC-3.3.3 when safe and known; non-color identification maps to SC-1.4.1. Programmatic relationships, control semantics and any qualifying status message require their own review. Covered transaction-error prevention is assessed separately under SC-3.3.4. Consult the registry for each condition and exception.

Preserving valid nonsensitive field values and preventing duplicate orders are chosen product policies, not newly invented WCAG success criteria. Repeated-entry requirements must still be assessed when their triggering conditions hold.

Proposed repair sequence

IF validation rejects a field
THEN identify the affected field in text
     AND explain the correction when known and safe
     AND retain meaningful programmatic relationships.

FOR THIS PRODUCT'S ERROR-SUMMARY PATTERN:
  create a visible summary with links to invalid fields;
  deliberately move focus to the summary on failed submit;
  verify that the announcement and reading order are usable;
  do not simultaneously generate redundant interruptive alerts.

FOR THIS PRODUCT'S RECOVERY POLICY:
  preserve valid nonsensitive input;
  allow correction and resubmission;
  make the transaction outcome unambiguous;
  prevent accidental duplicate orders in the payment sandbox.

The error-summary focus strategy is one implementation option, not a universal WCAG requirement. A different tested strategy can satisfy the requirements.

Change depth

Minor Change might add missing field relationships and text. Major Change might replace the form's error handling. Structural Change would create shared field, summary and submission contracts across all checkout and CRUD forms. A possible Paradigm Change would reconsider an unnecessarily complex checkout process while preserving access, information and security.

Do not jump to a complete rewrite before establishing the root cause. Conversely, do not fix one page and leave the same shared component broken elsewhere.

Selected meta-variable measurements

Magnitude: affected error types and steps. Scope: affected forms and routes. Frequency: failures per tested invalid submission. Detectability: automated checks versus manual review needed. Reversibility: correction/cancel behavior and deployment rollback separately. Propagation: all consumers of the shared form primitive. Accumulation: unresolved form defects over comparable releases.

All measured values start as unknown. Set the test fixture count before execution. Report completed runs, failures and unresolved runs rather than asserting a hypothetical improvement.

Acceptance record

Build: NOT_SUPPLIED
Test environment: NOT_SUPPLIED
Criterion observations: NOT_TESTED
Keyboard journey: NOT_TESTED
Screen-reader journey: NOT_TESTED
Visual and text-override checks: NOT_TESTED
Transaction correctness: NOT_TESTED
Release readiness: INCOMPLETE_ASSESSMENT

This record is intentionally not a pass. The grammar specifies the evidence needed to change it.