CAPTCHA Accessibility Tickets

A CAPTCHA finding should name the blocked task, the inaccessible challenge, and the acceptable replacement path. "CAPTCHA is inaccessible" is usually too vague to fix or retest.

Use this guide for audit notes about visual puzzles, missing audio alternatives, keyboard traps, unlabeled challenge controls, repeated verification after errors, and login or checkout flows that depend on memory, transcription, or mouse-only interaction.

Open this CAPTCHA finding in the generator

What to capture

User task: reset password, sign in, submit contact form, complete checkout, or create an account.
Challenge type: image matching, audio challenge, checkbox, slider, puzzle, SMS step, email code, or risk-based verification.
Blocked access path: keyboard-only, screen reader, voice control, switch access, low vision, cognitive support, password manager, or copy and paste.
Failure recovery: what happens after an incorrect challenge, expired token, timeout, or refresh.
Security constraint: whether abuse protection must remain in the flow and what alternatives are acceptable.

Ticket pattern

# [Critical] Password reset: CAPTCHA blocks non-visual verification

## User impact
Users who cannot complete the visual puzzle cannot reset their password and regain account access.

## Evidence
- Flow: password reset after submitting account email.
- Challenge: visual image-matching CAPTCHA.
- Observed: no equivalent non-visual alternative is available in the same flow.
- Failed attempt: focus moves unpredictably and recovery instructions are not announced.

## Likely WCAG references to verify
- 2.1.1 Keyboard
- 3.3.8 Accessible Authentication (Minimum)
- 3.3.9 Accessible Authentication (Enhanced)
- 4.1.2 Name, Role, Value

## Acceptance criteria
- The abuse-protection step can be completed without visual puzzle solving.
- Any alternative challenge is available in the same flow and can be reached with keyboard.
- Instructions, errors, refresh state, and recovery options are exposed to assistive technology.
- Focus remains predictable after challenge success, failure, timeout, and refresh.
- Password reset can be completed with the agreed keyboard and screen reader retest path.

Common CAPTCHA ticket mistakes

Only naming the vendor: the developer still needs the affected flow, state, and control behavior.
Assuming audio is enough: audio challenges can still fail for deaf-blind users, noisy environments, language mismatch, or cognitive load.
Ignoring failed states: expired, incorrect, refreshed, and rate-limited states often contain the actual blocker.
Leaving security vague: the ticket should say whether to replace the challenge, add an equivalent method, or preserve a risk-based check with accessible recovery.
Writing only "pass WCAG": include the concrete retest path and user task that must work.

Paste-ready input for the generator

Raw finding:
[Paste CAPTCHA, bot-check, login verification, or abuse-protection audit note.]

Affected task:
[Sign in, password reset, checkout, account registration, comment submission, support form.]

Observed blocker:
[Visual puzzle, missing alternative, keyboard trap, unlabeled controls, unexpected focus, repeated entry, timeout, or inaccessible error.]

Expected behavior:
[Users can complete verification through an accessible method in the same flow, with predictable focus and announced instructions/errors.]

Retest context:
[Keyboard only, VoiceOver/Safari, NVDA/Firefox, TalkBack/Chrome, voice control, password manager, copy/paste.]

CAPTCHA Accessibility Tickets

What to capture

Ticket pattern

Common CAPTCHA ticket mistakes

Paste-ready input for the generator

Related resources