Turn Input Purpose and Autocomplete Findings into Accessibility Tickets

Input-purpose findings become fixable when the ticket names the field, the missing or wrong autocomplete token, and the user task affected by repeated typing or unreliable autofill.

Use this guide for WCAG 1.3.5 audit notes about checkout addresses, contact details, account registration, billing forms, password reset, support forms, and any input that collects the user's personal information.

Open this autocomplete finding in the generator

What to capture from the finding

Form step: checkout shipping, billing address, account registration, contact form, password reset, booking, or support request.
Affected fields: exact visible labels and field names, such as First name, Last name, Email, Phone, Street address, Postal code, or Birthday.
Current autocomplete state: missing token, wrong token, duplicated token, token on the wrong field, or disabled browser autofill.
User task impact: manual typing, increased error risk, blocked autofill, longer checkout, or repeated personal-data entry.
Retest path: browser autofill, password manager, mobile keyboard suggestions, and screen reader field navigation where relevant.

Ticket structure

Title:
[Severity] Form or flow: personal-information fields do not expose input purpose

User impact:
Explain what users have to type, repeat, or correct because autofill and assistive technology cannot identify each field purpose reliably.

Evidence:
- Page or form step:
- Affected fields:
- Current autocomplete attributes:
- Expected autocomplete tokens:
- Browser or device used for retest:
- Actual result:
- Expected result:

Likely WCAG references to verify:
- 1.3.5 Identify Input Purpose, when fields collect the user's personal information and the purpose can be programmatically determined.
- 3.3.2 Labels or Instructions, when the visible or programmatic label does not explain the requested information.
- 4.1.2 Name, Role, Value, when custom inputs or masked fields do not expose a usable name or value.

Acceptance criteria:
- Each affected personal-information field uses the appropriate autocomplete token.
- Visible labels, programmatic labels, and autocomplete purpose describe the same information.
- Browser or platform autofill can identify representative address, contact, and account fields.
- The fix does not disable paste, password managers, or one-time-code autofill in the same flow.

Paste your input-purpose note into the generator when you want this structure drafted from raw audit text.

Example conversion: checkout address fields

Raw note:
Checkout shipping address fields collect first name, last name, street address, postal code, city, country, email, and phone. None of the inputs include autocomplete tokens.

Developer ticket:
[Medium] Checkout shipping address: personal-information fields are missing autocomplete tokens

User impact:
Users who rely on browser autofill, mobile keyboard suggestions, password managers, or cognitive support tools must type personal address and contact data manually. This slows checkout and increases avoidable entry errors.

Evidence:
- Flow: checkout shipping address
- Affected fields: First name, Last name, Street address, Postal code, City, Country, Email, Phone
- Current result: fields have visible labels but no autocomplete attributes
- Expected result: fields expose appropriate purpose tokens such as given-name, family-name, street-address, postal-code, address-level2, country-name, email, and tel

Likely WCAG references to verify:
- 1.3.5 Identify Input Purpose
- 3.3.2 Labels or Instructions

Acceptance criteria:
- Each affected shipping field has the correct autocomplete token for the information it collects.
- Browser autofill can populate representative saved address data without field mismatches.
- Screen reader field navigation still announces the visible label and current value clearly.
- The change is applied consistently to billing address fields if they use the same component pattern.

Example conversion: wrong token on email field

Raw note:
Registration form has autocomplete="username" on the email input even though the visible label is Email address and the account login identifier is separate.

Developer ticket:
[Medium] Registration: email field exposes the wrong input purpose

User impact:
Autofill and password-manager tools may fill the wrong saved value into the email field, creating account creation errors that are difficult to spot before submit.

Evidence:
- Flow: registration
- Affected field: Email address
- Current autocomplete value: username
- Expected autocomplete value: email, unless this exact field is intentionally the login username
- Actual result: saved username values can be suggested where an email address is requested

Likely WCAG references to verify:
- 1.3.5 Identify Input Purpose
- 3.3.2 Labels or Instructions

Acceptance criteria:
- The email field uses an autocomplete token that matches the requested information.
- The visible label, accessible name, autocomplete token, validation message, and submitted field meaning all align.
- Password-manager and browser autofill suggestions no longer encourage the wrong saved value.
- If the product intentionally uses email as username, that decision is reflected consistently in labels, help text, and validation.

Common fix directions

Use standard tokens: prefer documented HTML autocomplete tokens such as given-name, family-name, email, tel, street-address, postal-code, country-name, current-password, new-password, and one-time-code.
Match field meaning: do not copy the same token across multiple unrelated fields because the component looked similar.
Keep labels honest: if a field asks for "Company phone", do not expose it as the user's personal phone number.
Do not disable helpful input support: paste blocking, autocomplete="off", and password-manager interference can turn a small WCAG 1.3.5 issue into an authentication or checkout blocker.
Retest repeated components: address fields often appear in shipping, billing, account profile, guest checkout, and saved-address modals.

Paste-ready input for the generator

Input purpose finding:
Page or form step:
Affected field labels:
Current autocomplete values:
Expected autocomplete tokens:
Browser/device autofill behavior:
Screen reader or keyboard notes:
User task affected:
Repeated forms/components to inspect:
Acceptance criteria needed:

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