Skip to content
wcagc
Create account
←Back to blog
accessibilityJiraworkflowhow-to

A Jira accessibility workflow that doesn't create noise

Route accessibility findings into Jira as one ticket per root cause, with severity, WCAG references and a status that follows the next re-scan.

P

Pavel Charkasau

A Jira accessibility workflow stays quiet when it follows four rules. File one ticket per root cause, not one per failing element. Decide which severities earn a ticket before anything is exported. Never create a second ticket for a finding that already has one. And let the next scan, not someone's memory, decide when a ticket closes or reopens. Skip any of these and the usual thing happens: a scanner reports 412 nodes, someone bulk-imports 412 tickets, the board fills with near-duplicates, and the team learns to ignore the label. A smaller number of tickets that each describe one fix, with the selector and the WCAG success criterion in it, gets worked. Below is how I'd set this up, what wcagc's Jira Cloud sync does for you, and where it stops. One limit up front: automated scans find a share of accessibility issues, not all of them. Deque's study of more than 2,000 audits put automated coverage at 57% of issues by volume (Deque, 2021). A clean Jira board is not a conformance claim, and the rest needs human review.

Why do accessibility tickets turn into noise in Jira?

Because scanner output and backlog items have different shapes. An engine like axe-core reports a result per rule, with every matching DOM node listed under it, and gives each failed rule an impact of "minor", "moderate", "serious" or "critical" (axe-core API docs). A missing label on a shared <SearchInput> component shows up on every page that renders the header. Crawl 80 pages and that is 80 results for one line of JSX.

Jira tickets should be units of work. If a developer can close three tickets with one commit, two of them were noise. If one ticket needs six unrelated fixes, it will sit in "In Progress" for a quarter.

The other source of noise is lifecycle. Tickets get closed when someone believes the fix shipped, and nobody reopens them when the next release brings the bug back. After a few months the board says one thing and the site does another.

How should I group accessibility findings into Jira tickets?

Group by rule plus component (or root cause), and list the affected pages inside the ticket. That is the grain at which the work actually happens.

A useful ticket for the search-input example looks like this:

  • Summary: [accessibility] label — SearchInput
  • Severity: critical
  • WCAG: 1.3.1, 4.1.2
  • Affected pages: 80, with a sample of URLs
  • Sample selector: header form > input[type="search"]
  • The failing HTML snippet, a link to the rule's fix guidance and a link back to the scan report

The prefix in the summary is boring on purpose. It makes the tickets easy to find with a JQL text search, and it keeps them recognisable when they're mixed into a sprint with feature work.

What not to do: one ticket per page, or one ticket per node. Both look thorough in a status meeting. Both produce tickets that differ only in the URL, and developers rightly start bulk-closing them.

Which accessibility issues should become Jira tickets?

Not all of them, at least not on day one. Pick a threshold and write it down. A common starting point is to ticket critical and serious findings right away and review moderate and minor ones in a batch every sprint. That isn't a WCAG rule. WCAG itself has no severity levels; its conformance levels are A, AA and AAA, and a page conforms at AA only if it meets every Level A and AA success criterion (W3C, Understanding Conformance). The impact score is a prioritisation aid from the engine, and a "minor" finding on your checkout page can matter more than a "serious" one on a 2019 press release.

So the threshold is a team decision, and it should include where the issue is. W3C's conformance requirements say that for a multi-step process such as checkout, every page in the process has to conform (W3C). I'd put any finding on sign-up, login or checkout above the line regardless of its impact score.

Here is my opinion, stated once: if your team can't keep up with the tickets you create, create fewer and fix them. A short list that gets closed beats a complete list that gets ignored, and the scan report still holds the full inventory for audit purposes.

How does wcagc send findings to Jira?

You connect one Jira Cloud project with your site URL, project key, Atlassian email and an API token. wcagc stores the token encrypted and never returns it in the interface or API. Atlassian tokens expire after one year by default (Atlassian), so put the renewal in a calendar or sync will stop with an auth error. Then, on a finding in a scan report, you choose Jira and wcagc creates a Task.

Some specifics, because "integrates with Jira" means very different things across tools:

  • Grouping. The ticket is created per tracked finding, which is a rule grouped by the component or root-cause pattern wcagc detected. The summary follows the [accessibility] <rule> — <pattern> format above.
  • Contents. Severity, mapped WCAG success criteria, affected page and element counts, up to 10 page URLs, up to 5 sample selectors, the HTML snippet, the fix-guidance link and a link to the report. The footer says the finding came from automated scanning and that manual review is still required.
  • No duplicates. A finding can be linked to one Jira ticket. Try to export it again and you get "An issue is already linked" with a link to the existing ticket.
  • Manual export. Nothing gets bulk-imported. A person decides which findings cross the threshold, which is the point of the previous section.

The Jira integration page has the setup steps.

How do Jira tickets stay in sync with the next scan?

wcagc changes the ticket when the evidence changes. When a later scan no longer detects the finding, or someone marks it fixed in wcagc, it adds a comment and moves the ticket to a done status. When the finding comes back in a later scan, it comments "wcagc detected the finding again in a later scan and reopened this issue" and reopens it. Marking a finding as won't-fix closes the ticket with a comment that says so.

The comment matters more than the transition. A close comment reads like "wcagc no longer detected this finding on the 12 pages re-checked on 2026-10-14". That is a statement about scanner output. It is not a statement that a screen-reader user can now complete the form, and the comment says manual review is still required.

One practical gotcha. Jira workflows are configurable, so wcagc reads the transitions available on each ticket through Jira's Get transitions endpoint and picks one whose target is in the Done category (or is named like done, close or resolve). If your workflow forces tickets through "In Review" with no direct path to Done, sync fails with "No suitable Jira workflow transition is available". Add a transition, or accept that someone closes these by hand.

How do I report on accessibility work in Jira?

Use JQL on the summary prefix and the status category. Something like:

project = WEB AND summary ~ "accessibility" AND statusCategory != Done ORDER BY created ASC

Atlassian's JQL reference treats statusCategory = Done as resolved (Atlassian, JQL fields), so this works across custom workflows. Put it on a dashboard gadget and you have an honest open count.

Two things I'd add to the board that no scanner gives you:

  1. A separate ticket type or label for manual review findings: keyboard traps, focus order, unclear error messages, screen-reader announcements. These are the issues automation misses, and they deserve their own lane so they don't look like a scanner gap.
  2. One standing ticket per release for a short manual pass on the critical flows. The WCAG checklist is a reasonable script for it.

Does a clean Jira board mean the site conforms?

No. It means the findings you chose to track have been resolved to the scanner's satisfaction. Conformance is judged against success criteria on full pages and complete processes, not against a ticket count. That's true under the frameworks most teams care about: EN 301 549 for the European Accessibility Act, and WCAG 2.1 AA under the DOJ's ADA Title II rule (ADA.gov). The Jira trail is good evidence that you find, prioritise and fix issues as a routine. It is not evidence that nothing is left.

Frequently asked questions

Should every accessibility finding become a Jira ticket?

No. Ticket findings above an agreed threshold, such as critical and serious issues plus anything on sign-up, login or checkout, and review the rest in batches so the board stays workable.

How do I avoid duplicate accessibility tickets in Jira?

Group findings by rule and component before export, and use a tool that links one finding to one ticket. wcagc refuses a second export of the same finding and points you to the existing ticket.

Can wcagc close Jira tickets automatically?

Yes, when the evidence changes. It comments and moves the ticket to a done status when a re-scan no longer detects the finding or someone marks it fixed, and reopens it if the finding comes back.

Why did my Jira ticket fail to close from wcagc?

Most likely your workflow has no transition from the current status into the Done category. wcagc reports "No suitable Jira workflow transition is available"; add that transition or close the ticket manually.

Does a resolved Jira ticket mean the issue is fixed for users?

Not necessarily. It means the automated check no longer finds it. Automated testing covered 57% of issues by volume in Deque's 2021 study, so a person still needs to confirm the fix with a keyboard and a screen reader.

Start with one scan

Before wiring up Jira, look at what a scan of one important page actually reports. Run a free scan on your sign-up or checkout flow, count how many distinct fixes it describes, and use that number to set your ticket threshold.

Pavel Charkasau, founder, wcagc.com. Last updated 20 October 2026.

Sources