Build a barrier-focused release check for booking
Scanners pass while keyboard testers still lose drafts after conflicts. Add a release check covering actual booking and recovery.
- Focused work estimate
- 2h 30m + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Accessibility testing · Release verification · Documentation
Estimated field mix
- Accessibility60%
- Quality engineering40%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
The fictional Riverside desk books appointments for permit paperwork and library assistance. Its browser flow was assembled from separate forms and dialogs. Work uses synthetic availability and booking adapters; actual appointments and personal records are excluded.
Setup prerequisites
- Synthetic services, slots, and booking API contract
- Keyboard and screen-reader access for a documented manual check
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- A11Y-101 · Replace clickable service tiles with a named selection group
- A11Y-103 · Make month navigation work without a pointer
- A11Y-105 · Recover when another visitor takes the chosen slot
- A11Y-106 · Announce availability changes without reading the whole page again
- A11Y-102 · Keep contact-field help and errors understandable together
- A11Y-107 · Handle expiry without an inaccessible countdown trap
- A11Y-104 · Keep the booking action visible at high zoom
- A11Y-108 · Return focus correctly after reviewing contact details
- A11Y-109 · Make confirmation usable on screen and in print
Acceptance criteria
- Checks cover keyboard completion, zoom, named controls, slot conflicts, and session recovery.
- Automated assertions and manual observations are recorded separately with browser/tool versions.
- Unresolved barriers name affected steps and usable fallbacks without claiming universal accessibility.
Implementation constraints
- Bound the manual matrix to agreed combinations and include a reproduction script per barrier.
Verification to include
- Run normal booking plus slot-conflict and session-expiry scenarios and record outcomes.
- Introduce a missing dialog name or broken return focus in a local fixture; the relevant check detects it.
Deliverables
- Booking accessibility regression matrix and release decision note
Rollout and recovery
Use before pilot expansion; block steps with unrecoverable barriers and retain the documented alternative flow.
Value of the work
For the engineer: Practice accessibility as complete interaction behavior, including recovery and asynchronous updates.
For the team: Inspect whether an engineer removes concrete barriers while preserving appointment integrity and supportability.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.