← A11y Tickets

Turn axe Findings into Jira Tickets

axe is excellent at finding many technical issues. It does not automatically create the ticket your team needs to prioritize, fix, and retest the problem.

Conversion checklist

  1. Keep the original axe rule, help URL, selector, and affected node.
  2. Add the affected user task or flow: checkout, login, search, product filtering, account creation.
  3. Describe expected and actual behavior in user terms, not only DOM terms.
  4. Add reproduction steps that do not depend only on visual inspection.
  5. Prioritize by task impact and component reuse, not just issue count.
  6. Add acceptance criteria and a retest instruction.

axe finding to ticket mapping

Bad vs better

Bad:
Button must have discernible text.

Better:
[High] Checkout: payment method button has no accessible name

User impact:
Screen reader users hear only “button” and cannot determine which payment method they are selecting.

Evidence:
axe rule: button-name
Selector: .payment-methods button.icon-only
Observed with NVDA/Firefox: each icon-only payment control is announced as “button”.

Acceptance criteria:
- Each payment method control exposes a unique accessible name.
- The selected payment method state is available programmatically.
- The checkout payment step can be completed with keyboard and NVDA.

Common axe rules that still need human context

Related resources