Audit Spreadsheet Rows to Accessibility Tickets

A spreadsheet row can be good evidence and still be a poor developer ticket. The ticket needs the affected task, exact state, user impact, and retest path.

Use this when an accessibility audit arrives as rows with columns such as page, finding, WCAG, severity, notes, selector, tool, or assistive technology. Keep the scope to one row or one repeated component pattern at a time.

Draft a ticket from one audit row

Open a checkout focus-order row in the generator with impact, evidence, steps, and acceptance criteria already filled in.

Open this audit-row example in the generator

Before you import rows into a backlog

Preserve the row evidence: keep the row ID, page, selector, WCAG reference, tool, assistive technology, and quote from the finding where they exist.
Name the user task: say whether the row affects checkout, sign-in, search, form submission, account setup, document reading, or another concrete task.
Replace severity labels with impact: scanner or audit severity is useful, but developers need to know whether users are blocked, confused, slowed down, or mildly inconvenienced.
Write one retestable issue: split unrelated rows instead of bundling all keyboard, color, ARIA, and content defects into one broad ticket.

Audit row fields to carry into the ticket

Source row:
- Row ID:
- Page or flow:
- Component or selector:
- Finding text:
- Tool or test method:
- Assistive technology / browser:
- WCAG or standard reference:
- Audit severity:

Ticket additions:
- User task affected:
- Actual behavior:
- Expected behavior:
- Reproduction steps:
- Severity rationale:
- Acceptance criteria:
- Retest context:

Paste one audit row into the generator when you want these fields drafted into ticket form.

Example: row rewritten as a ticket

Raw row:
ID A11Y-214. Page: product filters. Test: manual keyboard.
Finding: size dropdown cannot be opened with Space.
Severity: critical. WCAG: 2.1.1. Note: users cannot apply size filter without mouse.

Ticket:
Title: Keyboard users cannot open the size filter dropdown

Severity rationale:
Blocks product filtering for keyboard users. The affected task is choosing a size before selecting a product.

Evidence:
- Source row: A11Y-214
- Page: product filters
- Method: manual keyboard test
- WCAG reference to verify: 2.1.1 Keyboard
- Actual: Space does not open the size filter dropdown
- Expected: the filter can be opened, navigated, selected, and closed without a mouse

Acceptance criteria:
- The size filter opens with Space and Enter.
- Options can be reached and selected with keyboard.
- The selected state is exposed visually and programmatically.
- The result count or selected-filter state update is communicated.
- The original row is closed with keyboard-only retest evidence.

Generate the product-filter ticket from this row

Rows that need clarification before development

"Fails WCAG 1.3.1": add the affected element, missing relationship, and how a user is harmed.
"Focus order wrong": name the trigger, expected focus target, actual focus target, and whether the user can recover.
"Screen reader issue": name the assistive technology, browser, spoken output, expected output, and state being tested.
"Contrast fails": include text or UI state, foreground/background colors if known, component state, and required ratio.
"ARIA invalid": keep the failing attribute, referenced ID, role, computed name, or accessibility-tree evidence.

Common mistakes

Turning the spreadsheet into a dashboard request: A11y Tickets is for one known finding becoming one copy-ready ticket, not audit management.
Dropping the source row: the row ID and original wording help QA trace the fix back to the audit.
Importing severity without rationale: "critical" should be backed by the blocked task or recovery cost.
Bundling unrelated rows: one shared component pattern is fine; unrelated flows should become separate tickets.