Prioritizing Accessibility Findings in Ticketing by Severity

1. Why unprioritized findings vanish into the backlog graveyard

A typical pattern in many teams looks like this: a comprehensive accessibility audit gets commissioned, delivers a long PDF report with hundreds of individual findings, and those findings all get logged as tickets in bulk, without distinguishing between a barrier that fully blocks checkout and a cosmetic deviation in the footer text. The result is a backlog nobody dares to start working through, because the sheer volume is overwhelming and no priority is visible anywhere.

Within a few weeks these tickets lose relevance, get pushed aside by newer, business-critical requirements, and sit unresolved in the backlog for months or years, a state many teams aptly call the accessibility backlog graveyard. Consistently prioritizing by severity right at the moment each finding gets logged is the most effective lever against exactly that fate.

2. Severity categories: Blocker, Major, and Minor

A proven breakdown distinguishes three categories. A Blocker fully prevents a core function for a specific user group, such as a checkout confirm button that cannot be reached by keyboard, and typically maps to WCAG Level A criteria, whose violation is treated as a fundamental exclusion. A Major finding makes a function significantly harder without making it fully impossible, such as confusing but technically still operable form validation, and usually maps to Level AA.

A Minor finding, finally, affects comfort and consistency without fundamentally blocking a task, such as a focus indicator that is technically visible but visually unremarkable. This breakdown deliberately aligns with WCAG conformance levels A, AA, and AAA, without adopting them one to one, because the actual priority also depends on the affected user group and how often the affected interaction occurs, not solely on the formal conformance level of the violated criterion.

3. Impact assessment by affected user group

Beyond the plain technical severity of a violation, a second, independent dimension is worth tracking: how many users of which group are actually affected, and how central the affected page is to the overall purchase flow. A missing alt attribute on a rarely visited subpage carries a different impact than the same missing alt attribute on the homepage's main product, even though both technically map to the same WCAG rule violation.

A simple matrix helps with this assessment, plotting technical severity on one axis against estimated reach, such as page views per month or centrality in the ordering process, on the other axis. A Blocker on a high-traffic page like checkout consistently lands at the very top of the priority list, while the same Blocker on a rarely visited archive page remains urgent but less time-critical.

4. Concrete examples for each severity category

A typical Blocker in a Magento context is a keyboard trap inside a modal cart dialog that cannot be navigated out of by keyboard, because focus incorrectly stays locked inside the dialog even after it should have closed. A Major finding is often a missing or meaningless alt text on central product images on the product detail page, which makes an informed purchase decision significantly harder for screen reader users without technically blocking the purchase altogether.

A classic Minor finding is a focus indicator that technically meets WCAG's minimum contrast and thickness requirements but is visually barely distinguishable from an element's default state, making keyboard navigation orientation unnecessarily harder without making it impossible. These graded examples help the whole team consistently sort new findings into the same category as already known, comparable cases.

5. Integrating into existing Jira or Linear workflows

Instead of tracking accessibility findings as a separate, isolated bug type outside the usual workflow, integrating them as a dedicated label or custom field inside the existing ticket system works better, for example a field a11y-severity with values Blocker, Major, and Minor, maintained alongside the ticket's regular priority field. This integration makes sure accessibility findings get handled in the same sprint planning and the same backlog grooming as any other functional bug, instead of vanishing into a separate, frequently overlooked system.

A consistent ticket template with fixed required fields, such as affected URL, violated WCAG criterion, test method used, and severity category, substantially speeds up both logging new findings and later working on them, because developers no longer need to dig through a separate audit document to find the business context.

# Example accessibility finding ticket template (Jira custom fields)
title: "[A11Y][Blocker] Focus trapped in cart dialog"
labels: [accessibility, a11y-severity-blocker]
custom_fields:
  wcag_criterion: "2.1.2 No Keyboard Trap (Level A)"
  test_method: "Manual keyboard navigation, NVDA"
  affected_url: "/checkout/cart"
  affected_group: "Keyboard users, screen reader users"
  sla_days: 5

6. Linking to the WCAG criterion and the test method

Every ticket should explicitly state which specific WCAG success criterion was violated and which method was used to identify the finding, whether automated through axe-core, manual through keyboard navigation, or as part of a user test with a person with a disability. This link makes it possible to later filter specifically for all open violations of a given criterion, for example to pinpoint every remaining Level A violation ahead of a renewed external certification.

Noting the test method also helps with prioritization itself, because a finding from real user testing, as covered in a companion article in this series, typically deserves a higher priority than a purely automated violation, since it has demonstrably caused a real difficulty for a real person.

7. Defining turnaround times and SLAs by severity

Without a binding turnaround deadline, even a finding correctly classified as a Blocker stays without consequence if it keeps getting pushed aside in sprint planning in favor of new features. A clearly defined service level, for example Blockers within five business days, Major findings within four weeks, and Minor findings within the next regular quarterly planning cycle, gives the team a binding, verifiable baseline that actual handling can be measured against.

These deadlines should be checked regularly, for example monthly, against tickets that are actually still open, so an overdue Blocker becomes immediately visible and can be escalated, instead of only resurfacing at the next big audit.

8. Avoiding the backlog graveyard through regular reviews

Even with clean categorization, a backlog can still turn into a graveyard again if nobody actively looks into it on a regular basis. A monthly accessibility review meeting that specifically walks through all open findings by severity and age stops a single ticket from sitting unnoticed for months, while also creating a fixed occasion to escalate overdue Blockers visibly to management.

A simple but effective dashboard that plots the number of open findings per severity category over time makes progress or stagnation visible at a glance, and doubles as a reporting basis for leadership, for instance in the context of the European Accessibility Act, where documented, traceable handling of findings is becoming increasingly important.

9. Defining ownership and escalation paths

Every ticket needs a clearly assigned owner, whether a person or a team, not just a generic assignment to the frontend team as a whole, because diffuse ownership in practice means nobody feels specifically responsible. Blocker findings should additionally have a clear escalation path defined, such as a direct notification to the team lead as soon as a Blocker exceeds its defined turnaround deadline, instead of waiting for the next regular review meeting.

This clear ownership should get assigned right when the ticket is created, not retroactively during sprint planning, so a Blocker finding does not first sit unassigned in the backlog for days before anyone even starts working on it.

10. Summary

11. FAQ: Accessibility Ticketing: Key Takeaways