Form Validation Accessibility Ticket Example
A real ticket should say more than “errors are inaccessible”. It should show the user impact, how to reproduce it, and what a fix must prove.
Developer-ready ticket
# [High] Registration: required-field errors are not announced after submit ## Summary for client / product owner Screen reader users can submit the registration form and hear no useful feedback about which fields need attention. This can prevent account creation and creates avoidable support/contact friction. ## Developer ticket **Area / flow:** Registration form **Assistive technology context:** NVDA with Firefox, VoiceOver with Safari **Finding source:** Manual screen reader test **Suggested severity:** High **User impact:** Causes serious confusion or high effort ### Expected behavior When the user submits the form with missing required fields: - focus moves to an error summary, or the first invalid field receives focus with its error available programmatically. - each error message is associated with the related field. - the screen reader announces enough context to understand what must be fixed. ### Actual behavior Visual red error messages appear below the inputs, but focus stays on the submit button. The error messages are not announced and are not connected to their fields. ### Reproduction steps 1. Open the registration form. 2. Leave Email and Password empty. 3. Submit the form using the keyboard. 4. Continue with NVDA or VoiceOver. 5. Observe that no error summary is announced and the invalid fields do not expose their error text. ### Evidence / raw finding - Email input has a visual error message, but no `aria-describedby` relationship to the error text. - No error summary receives focus after submit. - Invalid fields do not expose `aria-invalid="true"`. ### Likely WCAG references to verify - 3.3.1 Error Identification - 3.3.2 Labels or Instructions - 3.3.3 Error Suggestion - 4.1.3 Status Messages ### Acceptance criteria - Submitting invalid data announces an error summary or moves focus to a clear first error. - Each invalid field exposes `aria-invalid="true"` while invalid. - Each invalid field is programmatically associated with its visible error text. - A keyboard-only user can identify and fix all validation errors without relying on color. ### Fix direction Use a server/client validation pattern that updates both visual and accessible state. Prefer a focusable error summary at the top of the form for multi-field errors, and connect each field to its message with `aria-describedby`.
Why this example matters
Form validation bugs are common in ecommerce, account creation, booking, and contact flows. They are also easy to under-ticket: a vague issue title rarely gives developers the DOM relationships they need to inspect.
Use this as a pattern for tickets where an error is visible on screen but missing from the accessibility tree.