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

Use the pattern feature-scenario.uc.yaml:

login-success.uc.yaml
login-error-wrong-password.uc.yaml
login-error-empty-fields.uc.yaml
register-success.uc.yaml
checkout-guest-user.uc.yaml

The "name" in your step should match what a screen reader would announce. If your button says "Submit" visually but has aria-label="Send form", use "Send form".

It's tempting to just write activate: button "Submit" — Playwright will find and click it. But adding locate and focus first tests two additional accessibility requirements that activate alone won't catch.

# Bad — fragile, slow
- wait: 3000
- locate: text "Results"

# Good — precise, fast
- wait_for: text "Results"

Keep each file focused on a single scenario. Use extension cases to create variants rather than putting multiple paths in one file.

For every form, write negative cases that verify:

• Error messages use role="alert" (verify: alert)
• Invalid fields have aria-invalid and associated error text (verify: field_error)
• Focus moves to the first error (verify: focus field "...")

For your most important interactions, test keyboard activation separately:

- activate: button "Submit" via keyboard

Screenshots are invaluable in reports. Capture them after errors, at visual checkpoints, or when verifying layout:

- verify: alert "Form has errors"
- screenshot: 'error-state-visible'