Login and Authentication Accessibility Tickets

Authentication findings become fixable when the ticket names the sign-in task, the credential field or control, the failed state, and the recovery path.

Use this guide for login, account creation, password reset, one-time-code, show-password, password-manager, and session-timeout findings. Keep the ticket focused on the user task and implementation evidence; do not turn it into a broad security, legal, or identity-management project.

Draft an authentication accessibility ticket

Open a login-form example in the generator with labels, password instructions, failed-submit behavior, control names, retest steps, and acceptance criteria already filled in.

Open this login finding in the generator

Where authentication tickets need precision

Credential fields: persistent labels, autocomplete values, password requirements, required state, and inline instructions.
Error recovery: failed sign-in messages, locked-account notices, expired links, multi-field summaries, and focus after submit.
Password controls: show-password buttons, password-manager buttons, generated-password suggestions, and current pressed or expanded state.
One-time codes: SMS or email code fields, paste behavior, resend buttons, countdowns, and status messages after a new code is requested.
Timeouts and reauthentication: warnings, extension controls, saved work, and where focus lands after the session changes.

Ticket structure for a login or authentication finding

Title:
[Severity] Authentication flow: specific accessibility failure

User task:
Name the task, such as sign in, create an account, reset a password, enter a one-time code, reveal a password, or recover from a failed login.

Evidence:
- Page or step:
- Affected field or control:
- Trigger or state:
- Assistive technology or input method:
- Actual behavior:
- Expected behavior:
- Source evidence:

Likely WCAG references to verify:
Choose only the criteria supported by the behavior. Common references include labels, instructions, error identification, focus order, status messages, accessible name/state, and accessible authentication.

Acceptance criteria:
- The affected authentication task can be completed with keyboard and the supported screen reader.
- Fields expose persistent names, instructions, invalid state, and error text when relevant.
- Password, code, or helper controls expose specific names and states.
- Failed submit gives users a predictable recovery path.
- QA can reproduce the original state and confirm it no longer happens.

Example: failed sign-in is visible but not announced

Raw note:
Login form. Submit wrong password. Red message appears above the form, but focus stays on Sign in and VoiceOver does not announce the error.

Developer ticket:
[High] Login: failed sign-in message is not announced or focused

User impact:
Screen reader users may not know the sign-in attempt failed or what to do next, especially if the form visually updates without moving focus or exposing a status message.

Evidence:
- Flow: login
- Trigger: submit invalid credentials
- Current focus: remains on Sign in
- Visible result: error appears above the form
- Screen reader result: error is not announced
- Expected result: users receive a clear next step and can reach the error text

Likely WCAG references to verify:
- 3.3.1 Error Identification
- 2.4.3 Focus Order, if focus should move to the error or first relevant field
- 4.1.3 Status Messages, if the error is announced without moving focus

Acceptance criteria:
- Failed sign-in exposes the error message to assistive technology.
- The project pattern is explicit: move focus to the error, move focus to the first relevant field, or announce a status message without moving focus.
- The error text explains the recovery path without disclosing sensitive account details.
- Keyboard and screen reader retest confirms the failed-sign-in state is discoverable.

Example: password helper controls have unclear names

Raw note:
Password field has two adjacent icon buttons. Screen reader announces “button” and “button collapsed”. One is Show password and one opens password-manager suggestions.

Developer ticket:
[Medium] Login: password helper buttons do not expose specific accessible names or states

User impact:
Screen reader and voice-control users cannot reliably choose the intended password action. They may reveal a password by mistake, miss password-manager help, or abandon sign-in.

Evidence:
- Flow: login
- Controls: show-password button and password-manager suggestions button
- Actual: generic button names and unclear expanded or pressed state
- Expected: each control names the action and exposes the current state when state changes

Likely WCAG references to verify:
- 4.1.2 Name, Role, Value
- 2.5.3 Label in Name, if visible text or icon-label wording differs from the accessible name

Acceptance criteria:
- Show-password control has an accessible name such as “Show password” and changes to “Hide password” or exposes an equivalent pressed state.
- Password-manager control has a distinct name such as “Open password suggestions”.
- Expanded, pressed, or selected state is exposed when the control changes state.
- The controls remain reachable and operable with keyboard.

Do not over-pack the ticket

Separate label/instruction bugs from failed-submit recovery when they affect different controls or require different owners.
Do not claim that a login is secure or legally compliant; describe the accessibility behavior to fix and retest.
Do not paste account identifiers, customer emails, tokens, or production secrets into the ticket. Use safe selectors, steps, and redacted evidence.
Use one ticket for a shared password-field component only when the evidence shows the same defect appears across login, registration, and reset flows.

Paste-ready input for the generator

Authentication accessibility finding:
Flow or page:
Affected field or control:
User task:
Trigger or state:
Assistive technology or input method:
Actual behavior:
Expected behavior:
Error or instruction text:
Source evidence:
Retest notes:

Paste your login or authentication finding into the accessibility ticket generator when you want a structured first draft.