payload-accessibility

Payload Accessibility

Assess accessibility as part of the change, not as a scan added afterward. Scope conclusions to the behavior and states actually evaluated.

Change assessment

For every affected component or flow:

1. Identify the rendered states, input methods, viewport conditions, and assistive-technology behavior the change can affect.
2. Read wcag-2.2-aa.md. Assess every plausibly affected WCAG 2.2 Level A and AA criterion; do not limit review to criteria named in an issue.
3. Prefer native HTML semantics. When a composite ARIA pattern is necessary, implement its complete semantics and keyboard behavior rather than adding roles or states in isolation.
4. Read testing.md and select evidence based on the observable outcome.
5. Exercise the changed behavior in every relevant state. Accessibility checks must cover the production component and integration context, not a simplified substitute.

Test placement

• Put browser-observable, criterion-level accessibility evidence in test/a11y/WCAG.e2e.spec.ts, inside the numerically ordered test.describe group for its primary criterion.
• Put evidence that depends on synthesized speech or a screen-reader virtual/browse cursor in test/a11y/screen-reader.spec.ts, under the same criterion organization.
• Put setup shared by both accessibility specs in test/a11y/helpers.ts. Keep scenario-specific setup in its spec.
• Keep low-level unit tests beside their component when they verify an implementation contract. They supplement, but do not replace, an end-to-end WCAG regression when the reported barrier occurs only in the rendered application.
• Reuse the existing test/a11y Payload configuration and real UI components. Do not create a new accessibility fixture or criterion file by default.

Evidence boundaries

• Axe finds a subset of machine-detectable failures. A clean scan is not proof of criterion or product conformance.
• DOM and accessibility-tree assertions do not prove exact spoken output.
• Guidepup is for outcomes that specifically depend on screen-reader output or cursor behavior, not every issue originally discovered with a screen reader.
• Require human visual or assistive-technology confirmation only when the outcome depends on judgement, timing, platform behavior, or an interaction that reliable automation does not reproduce.
• WCAG 2.2 Level AA conformance requires all applicable Level A and Level AA criteria. A qualified human reviewer approves VPAT/ACR conformance statements.

Required handoff

Report:

1. The affected UI, states, and interaction methods assessed.
2. The WCAG 2.2 A/AA criteria assessed and why they were applicable or potentially affected.
3. Automated tests and commands run, with their results.
4. Required visual, screen-reader, or other manual verification.
5. Known failures, limitations, and any criterion that cannot yet be supported.

Never report a component, criterion, or product as conforming beyond the evidence collected.