Checkout Accessibility Ticket Example
Checkout bugs deserve clear severity because they can block purchases. This example keeps the claim practical: what happened, who is affected, and how the fix is verified.
Developer-ready ticket
# [Critical] Checkout: error message is not announced after submitting payment ## Summary for client / product owner Screen reader users may not know why payment failed. This can block checkout completion and directly affect conversion. ## Developer ticket **Area / flow:** Checkout payment step **Assistive technology context:** VoiceOver / NVDA **Suggested severity:** Critical **User impact:** Blocks task completion ### Expected behavior After submitting invalid payment data, focus should move to a clear error summary or the error should be announced programmatically. ### Actual behavior The visual error appears, but screen reader users remain on the submit button and receive no announcement. ### Reproduction steps 1. Open checkout payment step. 2. Enter invalid payment data. 3. Submit using keyboard. 4. Observe that the error is not announced and focus does not move to error context. ### Likely WCAG references to verify - 3.3.1 Error Identification - 3.3.3 Error Suggestion - 4.1.3 Status Messages ### Acceptance criteria - Invalid payment state is announced or focus moves to a clear error summary. - Field-level payment errors are associated with the affected controls. - The checkout payment step can be completed after correction using keyboard and screen reader. ### Fix direction Use an error summary with programmatic focus or an aria-live status message. Ensure field-level errors are associated with inputs.