What this template is for
Accessibility audits are how teams move from ‘we should be more accessible’ to ‘we are WCAG 2.2 AA conformant across these specific surfaces’. The audit itself is the easy part; the hard part is making sure findings turn into shipped fixes rather than a 40-page PDF nobody reads.
This template handles both halves:
- Required fields on the create screen - conformance target, scope, manual test coverage, AT combinations tested, findings counts, remediation deadline. The ‘manual test coverage’ and ‘AT combinations’ fields are explicit because audits that rely on automated tools alone catch less than half of real issues.
- STM-created audit sub-tasks - automated baseline, keyboard, screen readers, contrast, logging findings as linked bugs, handoff with deadlines, follow-up audit. The follow-up audit sub-task is the one teams skip; without it, ‘remediated’ never gets verified.
When to use it
Use this template for scheduled accessibility audits (quarterly is typical), pre-launch audits for major releases, and contract-driven audits required by enterprise procurement. Findings discovered during regular development should be filed as individual bug-report tickets, not under a full audit template.
Don’t use this template as a one-time exercise. Accessibility regresses without ongoing attention; the follow-up audit cadence on the template assumes recurring audits.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | Accessibility audit: Checkout v3 - WCAG 2.2 AA conformance | Yes |
WCAG Conformance Target | 2.2 AA (the typical legal floor) | Yes |
Audit Scope (custom) | Pages, flows, or components in scope | Yes |
Auditor | @a11y.specialist or external firm | Yes |
Automated Tool Coverage (custom) | axe / WAVE / Lighthouse - what tools were run | No |
Manual Test Coverage (custom) | Keyboard-only, screen reader (VoiceOver + NVDA), zoom, colour contrast | Yes |
Assistive Technologies Tested (custom) | VoiceOver/Safari, NVDA/Firefox, JAWS/Chrome - real, not just automated | No |
Findings Count (custom) | Critical: 2 / Serious: 7 / Moderate: 12 / Minor: 18 | No |
Linked Findings | Each finding is a separate linked bug-report ticket | No |
Remediation Deadline (custom) | Critical/Serious within 30 days; Moderate/Minor by next major release | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Define audit scope and conformance target with product and legal
- Run automated tooling (axe / Lighthouse) - capture baseline
- Manual keyboard-only walkthrough of in-scope flows
- Screen reader walkthroughs - at least two combinations (VoiceOver, NVDA, JAWS)
- Colour contrast and zoom-to-200% checks
- Log each finding as a linked bug-report ticket with WCAG criterion
- Hand off findings to owning teams with remediation deadlines
- Follow-up audit after remediation - confirm findings actually closed
Common questions
What WCAG conformance level should a Jira accessibility audit target?
WCAG 2.2 AA is the typical legal floor and the standard most enterprise customers will demand in procurement. Targeting AAA across the board is rarely practical; targeting A only is insufficient for most commercial software. Some teams target AA with selective AAA criteria for high-impact areas like forms.
Can automated tools alone certify accessibility?
No. Automated tools like axe catch 30-40% of WCAG issues - mostly things like missing labels and contrast violations. The remaining 60% require manual testing: keyboard navigation, screen reader output, focus management, meaningful error messages. An audit that runs only axe is not an audit.
What's the difference between an accessibility finding and a regular bug?
An accessibility finding is a specific WCAG violation; a bug is any defect. Findings have severity tied to WCAG impact (Critical = blocks task completion for some users), not the project's general severity scale. Track them as linked bug-report tickets but tag them so the accessibility-specific SLAs apply.
Who should own accessibility remediation in Jira?
The team that built the feature with the finding - not a central accessibility team. Central teams audit; they don't fix every issue forever. The point of an audit is to feed work into the product teams that own the relevant code. Otherwise accessibility becomes a permanent backlog held by a small team that can't keep up.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →