Mobile Accessibility Findings to Developer Tickets

Mobile accessibility findings are easy to underwrite as "responsive bug" or "app accessibility issue". A useful ticket names the affected task, viewport or device state, assistive technology path, and retest criteria.

Use this guide when converting mobile web, hybrid app, or native app audit notes into a backlog your developers and QA team can actually close.

Open a mobile tap-target example in the generator

What to capture before writing the ticket

Task: checkout, account recovery, booking, product filtering, search, support, or document review.
Platform: mobile web, iOS app, Android app, embedded WebView, PDF viewer, or third-party widget.
Device state: viewport width, zoom level, orientation, text size, keyboard open state, or modal state.
Assistive technology: TalkBack, VoiceOver, switch access, external keyboard, or not manually retested yet.
Evidence: exact control, screen, selector, announcement, gesture path, screenshot note, or scanner output.

Mobile findings that need sharper tickets

Small tap targets: name the affected control and whether adjacent controls cause wrong activation risk.
Reflow and zoom: include the zoom level or viewport where content is clipped, overlaps, or requires two-dimensional scrolling.
Orientation locks: explain which task becomes blocked when portrait or landscape is unavailable.
Screen reader labels: quote what TalkBack or VoiceOver announces and what the user needs to hear instead.
Dynamic updates: state whether result counts, cart totals, validation errors, or saved states are announced.

Example: tap target issue

Weak note:
Mobile buttons too small.

Better ticket:
[High] Mobile checkout: delivery slot controls are too small and too close together

User impact:
Shoppers with limited dexterity may activate the wrong delivery time and continue checkout with an unintended selection.

Evidence:
- Flow: checkout delivery step
- Viewport: 360px wide mobile web
- Affected controls: delivery slot buttons in the evening group
- Observation: adjacent controls are difficult to activate reliably without hitting the neighboring slot

Likely WCAG references to verify:
- 2.5.8 Target Size (Minimum)
- 2.5.5 Target Size (Enhanced), if used as the project target

Acceptance criteria:
- Each delivery slot has a reliable activation area or enough spacing from adjacent targets.
- The visible label, hit area, focus outline, and accessible name all refer to the same slot.
- QA retests at the affected mobile viewport and verifies keyboard or switch-access focus where relevant.

Generate a draft from this tap-target example

Example: zoom and reflow issue

Weak note:
Page breaks on zoom.

Better ticket:
[Critical] Mobile account recovery: password reset form is clipped at 400% zoom

User impact:
Low-vision users who zoom text cannot read the full password reset form or reach the submit button without two-dimensional scrolling.

Evidence:
- Flow: account recovery
- Viewport/state: 320px wide mobile viewport at 400% zoom
- Observation: input help text overlaps the submit button and the page requires horizontal scrolling

Likely WCAG references to verify:
- 1.4.10 Reflow
- 1.4.4 Resize Text

Acceptance criteria:
- The password reset form reflows without horizontal scrolling at the reported zoom and viewport.
- Labels, help text, validation messages, and submit control remain readable and operable.
- Keyboard focus is visible and follows the visual order after the layout changes.

Generate a draft from this reflow example

Example: TalkBack label issue

Weak note:
TalkBack labels are bad.

Better ticket:
[High] Product filters: TalkBack announces icon-only clear buttons as "button"

User impact:
Blind Android users cannot tell which active filter will be removed and may accidentally change the product list.

Evidence:
- Flow: product listing filters
- Assistive technology: TalkBack with Chrome on Android
- Observation: each active filter chip has a clear button announced only as "button"

Likely WCAG references to verify:
- 4.1.2 Name, Role, Value
- 2.4.6 Headings and Labels

Acceptance criteria:
- Each clear control exposes a unique accessible name, such as "Remove size medium filter".
- The visible filter text and accessible name stay in sync when filters change.
- TalkBack retest confirms the active filter list and removal controls are understandable.

Generate a draft from this TalkBack example

Mobile ticket template

Title:
[Severity] Mobile flow/component: user-facing accessibility problem

User impact:
Who is affected, what mobile task is harder or blocked, and why?

Evidence:
- Platform/device:
- Viewport, zoom, orientation, or text-size state:
- Assistive technology path, if tested:
- Affected control, selector, or screen:
- Observed result:

Likely WCAG references to verify:
- Add likely criteria after inspecting the implementation.

Acceptance criteria:
- The affected mobile task can be completed in the reported state.
- Labels, roles, states, target size, reflow, focus, or announcements are retested as relevant.
- The original finding can no longer be reproduced, or any remaining limitation is documented.