Accessibility Ticket Severity Examples

Severity is easier to defend when the ticket ties the defect to a real user task: blocked, seriously confusing, slower, or low-risk.

Use these examples when an audit row says "critical", "major", "serious", or "minor" but the development backlog needs clearer triage language. Keep severity grounded in the affected flow, not in scanner labels alone.

Draft a severity-backed ticket

Open a checkout dialog example in the generator with impact, evidence, reproduction steps, and acceptance criteria already filled in.

Open this severity example in the generator

Severity mapping that stays useful

Critical: a user cannot complete a core task, such as checkout, sign-in, form submission, booking, or document download.
High: the task can technically continue, but the defect creates serious confusion, repeated recovery work, or a high chance of failure.
Medium: the issue slows users down, increases effort, or affects a secondary task without fully blocking completion.
Low: the issue is real and should be fixed, but the user impact is limited, localized, or unlikely to affect task completion.
Needs triage: the finding lacks enough flow, evidence, or user-impact detail to assign priority responsibly.

Ticket structure

Title:
[Severity] Flow or component: accessibility issue tied to user task

Severity rationale:
Name the affected task, who is affected, and whether the task is blocked, seriously confusing, slower, or low-risk.

Evidence:
- User task:
- Affected page or component:
- Assistive technology or input method:
- Actual result:
- Expected result:
- Recovery path or workaround:

Likely WCAG references to verify:
- Include relevant criteria, but do not use WCAG number alone as the severity reason.

Acceptance criteria:
- The user can complete the named task through the affected input or assistive technology path.
- The original evidence no longer reproduces.
- The retest covers the same flow, state, viewport, and assistive technology context.

Paste your finding into the generator when you want the severity and ticket wording drafted together.

Critical examples

Checkout: keyboard focus becomes trapped in a payment iframe and users cannot reach Place order.
Authentication: sign-in requires a puzzle CAPTCHA without an accessible alternative.
Form submission: required-field errors are not exposed and users cannot identify which fields need correction.
Mobile: the only Continue control is outside the reachable swipe or keyboard order.

High examples

Dialog focus return: closing a checkout dialog sends focus to the header, forcing keyboard users through repeated navigation before they can continue.
Data table: order totals are announced without column headers, so screen reader users cannot reliably compare values.
Status update: applying a filter changes the result count silently, so users may not know whether the action worked.
Color contrast: an enabled checkout button looks disabled because its text and state contrast are too weak.

Medium and low examples

Medium: address fields lack autocomplete tokens, causing avoidable typing and autofill errors in checkout.
Medium: repeated "Read more" links require extra context but do not prevent navigation once users inspect surrounding text.
Low: an informative icon has duplicate adjacent text, creating noise but not changing the task outcome.
Low: a non-critical footer link has a vague accessible name while the same destination is clearly available elsewhere.

Common severity mistakes

Scanner label as priority: an automated "serious" label is evidence, not the full severity rationale.
WCAG number as impact: "fails 4.1.2" does not explain whether users are blocked, confused, slowed, or mildly annoyed.
Global priority for local defects: one broken CMS component may be high if it appears in checkout and low if it appears only in an archived page.
Ignoring recovery cost: a workaround that requires ten extra Tab presses, page refreshes, or repeated data entry can raise priority even when the task is technically possible.

Paste-ready input for the generator

Severity triage finding:
User task:
Affected page or component:
Assistive technology or input method:
Actual result:
Expected result:
Does this block completion?
Recovery path or workaround:
How often the component appears:
Likely WCAG references:
Acceptance criteria needed:

Open the accessibility ticket generator and paste this structure with the audit note.