WCAG 2.2 Findings to Accessibility Tickets

WCAG 2.2 findings are easiest to fix when the ticket names the affected user task, the exact interaction that fails, and the behavior QA must retest.

Use this page when an audit row says "WCAG 2.2" but the development team still needs concrete work: target size, dragging alternatives, focus visibility, redundant entry, accessible authentication, and motion control.

Open a WCAG 2.2 target-size example in the generator

What to add before creating the ticket

User task: sign in, choose delivery, open menu, complete checkout, submit support request.
Failed interaction: tap target, drag-only movement, obscured focus, repeated entry, authentication challenge, or auto-updating content.
Evidence: viewport, zoom level, selector, screen reader path, keyboard path, audit row, or screenshot note.
Retest condition: what must be checked after the fix, using the same device, viewport, assistive technology, or keyboard path.

Ticket examples by WCAG 2.2 issue

2.5.8 Target Size (Minimum)

# [High] Checkout: shipping method controls are too small to activate reliably

User impact:
Mobile users with motor disabilities can select the wrong shipping method or fail to continue checkout.

Evidence:
The radio control hit areas are 18px wide and 4px apart at a 390px viewport.

Acceptance criteria:
- Each shipping method can be activated reliably at the affected mobile viewport.
- The visual control, hit area, focus outline, and accessible name all refer to the same option.
- Adjacent controls have enough size or spacing to avoid accidental activation.

Generate a target-size ticket

2.5.7 Dragging Movements

# [Critical] Account dashboard: cards can only be reordered by drag and drop

User impact:
Keyboard, switch, and screen reader users cannot place the payment card before the invoices card.

Acceptance criteria:
- The card order can be changed without drag-and-drop.
- The alternative controls are visible, keyboard-operable, and programmatically named.
- The new order is announced or otherwise confirmed without moving focus unexpectedly.

Generate a drag-alternative ticket

2.4.11 Focus Not Obscured

# [High] Product listing: sticky newsletter bar hides focused filter controls

User impact:
Keyboard users can reach the price filter, but the visible focus indicator is covered by the sticky bar.

Acceptance criteria:
- Focused controls are not fully hidden behind sticky headers, cookie banners, chat widgets, or bars.
- The focused element scrolls into a visible position before the user needs to act.
- The focus indicator remains visible against the surrounding background.

Generate a focus-obscured ticket

3.3.7 Redundant Entry and 3.3.8 Accessible Authentication

# [High] Login: verification requires retyping and a puzzle-only challenge

User impact:
Users with cognitive, motor, or screen reader barriers may be unable to complete sign-in.

Acceptance criteria:
- Users can authenticate without solving a puzzle-only or memory-only challenge.
- Password managers, copy/paste, or one-time-code autofill are not blocked.
- Information already supplied in the same process is reused or made available instead of being requested again.

Generate an authentication ticket

Paste-ready generator input

Audit row:
[Paste the WCAG 2.2 criterion, finding, selector, viewport, assistive technology path, or screenshot note.]

Affected user task:
[What the user was trying to do.]

Expected behavior:
[What should happen for keyboard, pointer, screen reader, or cognitive-access users.]

Acceptance criteria needed:
Draft a developer-ready ticket with user impact, evidence, likely WCAG references, and retestable criteria.