Writing Accessibility Use Case Tests with @afixt/usecase-runner

Most features have one happy path and many error paths. Instead of duplicating the entire use case, use extension cases to branch off from a parent:

# register-error-missing-email.uc.yaml

id: register-error-missing-email
title: 'Register — Missing Email Error'
extends: register-success
type: negative
description: 'Verify proper error handling when email is left blank'

preconditions: []

data:
  email: '' # Override parent's email with empty string

# Replace steps starting at step index 14 (the "Fill in email" section)
# Count from 1 — this replaces from that step onward
steps_override:
  from_step: 14
  steps:
    # Skip filling in email, go straight to submit
    - 'locate: field "Password"'
    - 'focus: field "Password"'
    - 'enter: field "Password" value "{{ password }}"'
    - 'locate: checkbox "I agree to the Terms of Service"'
    - 'select: checkbox "I agree to the Terms of Service"'
    - 'locate: button "Create Account"'
    - 'focus: button "Create Account"'
    - 'activate: button "Create Account"'

    # Verify error handling
    - 'verify: alert "Please correct the errors below"'
    - 'verify: field_error "Email"'
    - 'verify: focus field "Email"'

1. The runner loads the parent case (register-success)
2. It replaces the parent's data values with any overrides you provide
3. It takes the parent's steps up to from_step (exclusive), then appends your steps_override.steps
4. The resulting merged case runs as a single test

This is efficient for testing multiple validation scenarios — each extension case only defines what's different.