Turn Error Summary Findings into Accessibility Tickets

An error summary ticket should say what happens after failed submit, where focus goes, whether each error links to the right field, and how a keyboard or screen reader user recovers.

Use this guide for checkout, account, booking, login, support, and application forms where failed submit leaves users on the button, creates a silent summary, links errors to the wrong fields, or only marks fields visually.

Draft the error-summary ticket first

Open a checkout error-summary example in the generator with the finding, failed-submit behavior, field-link evidence, retest steps, and acceptance criteria already filled in.

Open this error summary finding in the generator

What to capture from the finding

Failed-submit trigger: required fields left empty, invalid email, server-side validation, expired session, payment error, or duplicate account.
Focus behavior: whether focus stays on submit, moves to the summary, moves to the first invalid field, jumps to the top, or disappears.
Summary content: heading, number of errors, field names, recovery instructions, and whether each item is specific enough.
Summary links: whether every link targets the matching invalid field or group and preserves useful field context.
Field-level relationship: whether the invalid field references the visible error message when focus reaches the field.

Ticket structure

Title:
[Severity] Form or flow: error summary does not provide a reliable recovery path

User impact:
Explain what users cannot find, understand, or correct after failed submit.

Evidence:
- Form step:
- Failed-submit trigger:
- Number of errors:
- Focus position after submit:
- Error summary heading and text:
- Summary link behavior:
- Field-level error relationship:
- Assistive technology and browser:

Likely WCAG references to verify:
- 3.3.1 Error Identification, when invalid fields are not clearly identified.
- 3.3.2 Labels or Instructions, when the summary or field message does not explain the expected input.
- 3.3.3 Error Suggestion, when known corrections are not suggested.
- 2.4.3 Focus Order, when failed-submit focus does not support a logical recovery path.
- 1.3.1 Info and Relationships, when visible summary or field relationships are not programmatic.
- 4.1.3 Status Messages, when a non-focus-changing summary appears silently.

Acceptance criteria:
- Failed submit gives keyboard and screen reader users a predictable path to the validation errors.
- The summary identifies every blocking error with enough field context to act.
- Each summary item targets the matching invalid field or field group.
- Each invalid field remains programmatically connected to its own field-level message.
- The original invalid-submit path is retested with keyboard and the agreed screen reader/browser pair.

Paste your error-summary note into the generator when you want this structure drafted from raw audit text.

Example conversion: focus stays on submit

Raw note:
Registration form. Submit with empty required fields. Error summary appears above the form, but focus remains on Create account. NVDA does not announce the summary.

Developer ticket:
[High] Registration: failed submit creates an error summary without moving focus or announcing it

User impact:
Screen reader and keyboard users may not know the form failed or where to go next, so account creation becomes a search task instead of a guided recovery path.

Evidence:
- Flow: registration
- Trigger: submit with empty required fields
- Current focus: remains on Create account button
- Visible result: error summary appears above the form
- Screen reader result: summary is not announced after submit
- Expected result: focus or announcement gives users a clear next step

Likely WCAG references to verify:
- 3.3.1 Error Identification
- 2.4.3 Focus Order
- 4.1.3 Status Messages, if focus intentionally stays in place

Acceptance criteria:
- Failed submit moves focus to the summary or first invalid field, or announces the summary through an approved status pattern.
- The summary heading and error count are available to assistive technology.
- Users can navigate from the summary to each invalid field.
- Keyboard-only retest confirms the focus path is predictable.

Example conversion: summary links target the wrong fields

Raw note:
Checkout address summary lists Name, Street, and Postal code errors. The Street link focuses City, and Postal code focuses Country.

Developer ticket:
[Critical] Checkout address: error-summary links send users to the wrong fields

User impact:
Users who rely on the summary to recover from validation errors can be sent to unrelated fields, causing repeated failures and blocking checkout.

Evidence:
- Flow: checkout address
- Summary items: Name, Street, Postal code
- Broken targets: Street link moves to City; Postal code link moves to Country
- Field-level messages: visible below each field
- Expected result: each summary item moves to the matching invalid field or field group

Likely WCAG references to verify:
- 3.3.1 Error Identification
- 2.4.3 Focus Order
- 1.3.1 Info and Relationships

Acceptance criteria:
- Every summary item points to the field or group named in the summary text.
- Focus lands where the user can hear or see the field label and related error.
- Field-level messages remain associated with their controls.
- Retest covers all summary links in the invalid-submit state.

Common weak notes to rewrite

"Error summary inaccessible": say whether the problem is focus, announcement, heading, link target, copy, or field association.
"Focus should go to top": name the project pattern: summary focus, first-error focus, or announced status without focus movement.
"Links do not work": list the broken summary item, actual focus target, and expected target.
"Errors are not announced": distinguish between the summary not being announced after submit and the field-level message not being announced on field focus.
"Multiple fields fail": include the count and whether grouped controls, such as radio sets or date fields, need one group-level error.

Paste-ready input for the generator

Error summary finding:
Form step:
Failed-submit trigger:
Number of errors:
Focus after submit:
Summary heading and text:
Summary link targets:
Field-level error associations:
Assistive technology and browser:
Expected recovery path:
Retest notes:

Open the accessibility ticket generator and paste this structure with the audit note.