Accessibility Testing Across User Journeys

Accessibility Testing Across User Journeys asks whether a person can complete the intended outcome through every meaningful interaction and state—not merely whether one rendered page produces zero automated violations. Automated scans are useful evidence. They are not the product category, the complete test, or the final release Decision.

Reshot treats accessibility as a first-class Journey capability beside functional and visual verification.

Start with the outcome

Choose a release-critical Journey such as accepting an invitation, completing checkout, publishing content, recovering an account, or changing a billing plan. State the observable consequence and the actors who must complete it.

Then identify checkpoints where accessibility meaning can change:

• an authentication or account-selection boundary;
• a modal, menu, combobox, data grid, or multi-step form;
• validation, error recovery, and asynchronous status;
• destructive confirmation and undo;
• completion feedback;
• content that updates without navigation;
• responsive states where interaction order changes.

This focuses evidence on complete participation rather than raw page count.

Declare representative contexts

Accessibility behavior can vary by role, permissions, locale, viewport, zoom, input method, assistive technology, reduced-motion preference, and product data. Preserve those dimensions in the State Capsule and context cell.

Do not create a combinatorial matrix without purpose. Select contexts from user impact, structural difference, product risk, known barriers, and release change. Record which cells were executed, skipped, unsupported, or covered by a scoped exception.

Combine automated and manual evidence

Playwright documents integration with @axe-core/playwright for automated accessibility scanning and cautions that automated testing cannot detect every WCAG violation (Playwright accessibility testing). It also supports ARIA snapshot assertions for accessible-tree structure (ARIA snapshots).

Automated evidence can efficiently detect rule-based conditions such as missing names, invalid relationships, color-contrast failures detectable from computed styles, and structural errors. Manual or assisted evaluation remains necessary for keyboard workflows, focus management, announcement timing, error comprehension, cognitive load, meaningful sequence, alternative text quality, and usability with real assistive technology.

Store both as peer Observations with:

• rule or protocol identity and version;
• evaluator or engine identity;
• component and owner;
• Journey Version, Run, context cell, step, and Observation;
• target reference and occurrence identity;
• evidence hash and capture time;
• resulting barrier, remediation, verification, exception, or statement references.

Avoid fragile violation snapshots

Playwright’s accessibility guide warns against snapshotting the entire axe violations array because it includes implementation details that change for unrelated reasons. It recommends smaller violation fingerprints built from rule IDs and target selectors when teams need to track accepted existing issues.

In a Journey system, a fingerprint should still connect to a durable barrier record and context. Suppressing a rule or excluding a selector without ownership, rationale, scope, and expiry turns known debt into invisible debt.

Make barriers durable and attributable

A barrier is not just a failed scan row. Record:

• a stable barrier identity;
• title and impact;
• affected occurrence IDs;
• component version and owner;
• relevant WCAG criteria or internal requirements;
• first and latest Observation;
• remediation and verification events;
• current status;
• any Decision or exception.

Shared-component occurrences should connect to the owning component so one repair can be evaluated across affected Journeys without pretending every instance was independently fixed.

Handle exceptions as expiring Decisions

An exception requires a subject, authorized actor, rationale, scope, evidence, grant time, and expiry. It should identify the Journey Versions, context cells, barriers, and criteria it affects. When time expires or the Journey changes materially, reopen Review.

Never convert an exception into a permanent passing test by deleting the rule. Preserve the underlying finding and make the release consequence explicit.

Review accessibility beside functional and visual truth

Accessibility evidence changes the interpretation of other evidence:

• a visually identical button may lose its accessible name;
• a functional flow may complete with a mouse while trapping keyboard focus;
• an intended visual redesign may change heading order or announcement behavior;
• a localized layout may clip zoomed text or reorder interaction;
• a screenshot difference may be the visible result of a correct accessibility remediation.

One Run lets the reviewer inspect these relationships without collapsing them into one composite score.

Produce a scoped statement, not universal certification

When the implemented path supports conformance work, bind statements to the exact scope: Journey, version, context cells, criteria, automated and manual evidence, exceptions, policy version, issue time, and evidence records. State what the evidence supports and what it does not.

Do not claim that an automated scan certifies a product, that one Journey proves whole-site conformance, or that an accessibility score replaces expert judgment.

Release workflow

For each material Journey change:

1. identify affected checkpoints and contexts;
2. run functional assertions and collect visual Observations;
3. run versioned automated accessibility rules;
4. perform required manual protocols;
5. connect occurrences to barriers and owners;
6. classify product, state, target, infrastructure, or policy failures;
7. remediate, verify, or create a scoped expiring exception;
8. record the attributable Review Decision;
9. include the scoped evidence consequence in release readiness;
10. invalidate dependent documentation or training when accessibility instructions changed.

Read Functional, Visual, and Accessibility Evidence in One Run for the unified model, Full-Journey Visual QA for visual review, and Critical User Journey Testing for outcome selection.