WCAG 1.3.5 Identify Input Purpose: Compliance Guide

Your team probably knows the feeling. Registration works, checkout mostly works, and your support queue still gets complaints that forms are confusing, tedious, or hard to complete with assistive tech. QA may already be checking labels, error messages, and keyboard access, yet one quiet gap remains: fields that look clear to a sighted user but don’t expose their purpose in a standardized way to browsers, password managers, and assistive technologies.

That gap is where WCAG 1.3.5 Identify Input Purpose matters. It’s a narrow requirement, but it touches conversion-critical journeys, procurement reviews, and accessibility conformance claims. It also tends to surface late, because many automated checks can spot that an attribute exists but can’t reliably judge whether the chosen value is the right one for the actual field.

For technical leaders trying to reduce accessibility risk across product, engineering, and documentation, it helps to treat this as part of a broader compliance workflow instead of a one-off HTML tweak. A useful reference point is Suby’s consolidated compliance, which shows how teams often need one view across implementation, policy expectations, and operational controls rather than disconnected fixes.

Why Input Purpose Matters for Business and Compliance

Trust isn’t lost merely because a form lacks a label. It’s lost because the form feels harder than it should. Users retype profile data, browsers fail to assist, password managers guess wrong, and accessibility complaints land with product or legal after release.

That pattern creates two problems at once. First, it adds friction in journeys tied directly to revenue or account activation. Second, it creates an avoidable compliance weakness in forms that collect user information.

The issue hides in otherwise polished forms

A form can look excellent in design review and still fail this requirement. Clear visual labels are necessary, but they don’t always give software enough information to identify a field’s purpose programmatically. When that mapping is missing or incorrect, the user experience breaks down for people who rely on autofill, personalization, or assistive support to complete repetitive form tasks.

Practical rule: If a user field belongs to a common personal-data pattern, the code should expose that meaning explicitly, not force the browser or assistive tech to guess.

This matters most in forms your business can’t afford to get wrong:

• Account creation: New users need a low-friction first interaction.
• Checkout: Payment and address forms are where abandonment and support friction often show up.
• Profile and settings: Returning users expect browsers and password managers to help.
• Lead generation: Long B2B forms become harder when every field demands manual effort.

Compliance risk is tied to ordinary product work

WCAG 1.3.5 isn’t an obscure edge rule. It’s part of the Level AA baseline discussed in procurement, accessibility reviews, and remediation planning. That makes it relevant to product teams shipping enterprise SaaS, government-facing systems, healthcare portals, and ecommerce flows.

The operational takeaway is simple. Treat input purpose as part of your form component standard, your QA checklist, and your accessibility documentation. If you wait to address it during a VPAT or legal review, remediation gets slower and more expensive because the issue is usually spread across templates, design systems, and shared components.

Decoding WCAG 1.3.5 Identify Input Purpose

WCAG Success Criterion 1.3.5 Identify Input Purpose was added in WCAG 2.1, which W3C published in June 2018. It is a Level AA requirement and applies only to form fields that collect information about the user, where the field purpose must be programmatically determinable. W3C’s understanding document explains that this lets user agents and assistive technologies extract and present the purpose in different modalities, and it recommends code-based techniques such as the HTML autocomplete attribute when technology support exists. The same W3C guidance also notes a standardized list of 53 input purposes, which gives implementers a finite mapping target instead of an open-ended labeling problem, as described in the W3C understanding document for Identify Input Purpose.

What the requirement actually says

In plain English, the browser or assistive technology shouldn’t have to infer that a field is “first name” or “email” from nearby text alone. Your code should identify that purpose using a recognized semantic pattern.

A useful way to think about it is a filing system. If every folder says only “document,” your assistant has to open each one and guess where things belong. If each folder is pre-labeled “invoice,” “contract,” or “tax record,” the assistant can file and retrieve information correctly without guessing. autocomplete works the same way for user data fields.

For teams that want a field-by-field implementation reference, this guide to the HTML autocomplete attribute and input purpose mapping is the right technical companion to your design system work.

Who benefits most

The requirement has strong practical value for people who struggle with repetitive data entry. That includes users with cognitive disabilities, users with motor impairments, and users who depend on software assistance to reduce typing and errors.

It also helps more broadly in day-to-day usage. Browsers, password managers, and assistive tools can only do reliable work when the field meaning is explicit.

When teams implement input purpose correctly, they stop relying on visible labels alone and start giving user agents a dependable contract.

What is in scope and out of scope

The biggest misunderstanding is scope. This criterion doesn’t apply to every text box on a page.

It applies to fields collecting information about the user, such as:

Field type	Usually in scope
Name fields	Yes
Email address	Yes
Phone number	Yes
Street address	Yes
Payment-related personal data	Yes

It usually doesn’t apply to freeform fields that aren’t collecting personal profile data in a standardized purpose category, such as:

• Site search: A search box isn’t personal user profile information.
• Comments or messages: These are content-entry fields, not standard personal-data purposes.
• Internal business data: Order notes, project codes, or product quantities usually don’t map to user identity purposes.

That narrower scope is a good thing. It makes WCAG 1.3.5 Identify Input Purpose more testable than many broader form requirements.

How to Implement Identify Input Purpose with Autocomplete

The fastest path to compliance is usually the simplest one. Use the HTML autocomplete attribute on eligible fields, and use the correct standardized token for the field’s actual purpose.

Deque notes that the practical interoperability value of 1.3.5 comes from standardized autocomplete semantics that let browsers, password managers, and assistive technologies infer exact field meaning and reduce manual entry errors, especially for cognitive and motor accessibility. It also describes HTML autocomplete tokens as the recommended implementation path and ties the WCAG input-purpose list to a fixed set of standardized purposes used across common user-data fields in its Deque University explanation of SC 1.3.5.

If your team generates forms from structured data, form builders, or spreadsheet-driven workflows, it’s worth checking how those tools output labels and attributes. Many no-code pipelines create inputs quickly but don’t always produce strong semantics by default. This walkthrough on turning a google sheet to form is useful because it highlights where generated forms still need developer review before they’re accessibility-ready.

Start with the fields that matter most

Don’t try to retrofit every legacy form in one sprint. Start with forms that collect user identity, account, contact, address, or payment information.

A practical implementation order looks like this:

1. Registration and login-adjacent flows: Name, email, username, password fields.
2. Checkout and billing: Shipping, billing, phone, cardholder details.
3. Account profile pages: Saved addresses, contact details, profile settings.
4. Lead capture forms: Only where fields collect user contact and identity data.

For broader form engineering patterns, this guide to accessible forms under WCAG is a good cross-check for labels, errors, focus order, and instructions alongside input-purpose work.

Registration form example

Use precise tokens. Don’t settle for broad guesses.

<form>

<div>
<label for="given-name">First name</label>
<input id="given-name" name="givenName" type="text" autocomplete="given-name" />
</div>


<div>
<label for="family-name">Last name</label>
<input id="family-name" name="familyName" type="text" autocomplete="family-name" />
</div>


<div>
<label for="email">Work email</label>
<input id="email" name="email" type="email" autocomplete="email" />
</div>


<div>
<label for="new-password">Create password</label>
<input id="new-password" name="password" type="password" autocomplete="new-password" />
</div>

</form>

Why this works:

• given-name and family-name: More accurate than a generic name.
• email: Gives browsers and assistive tech a standard meaning.
• new-password: Helps password managers distinguish account creation from sign-in.

Address form example

Address forms are where teams often introduce inconsistent mappings across countries and templates.

<form>

<div>
<label for="street-address">Street address</label>
<input id="street-address" name="streetAddress" type="text" autocomplete="street-address" />
</div>


<div>
<label for="address-level2">City</label>
<input id="address-level2" name="city" type="text" autocomplete="address-level2" />
</div>


<div>
<label for="address-level1">State or province</label>
<input id="address-level1" name="region" type="text" autocomplete="address-level1" />
</div>


<div>
<label for="postal-code">Postal code</label>
<input id="postal-code" name="postalCode" type="text" autocomplete="postal-code" />
</div>


<div>
<label for="country">Country</label>
<input id="country" name="country" type="text" autocomplete="country" />
</div>


<div>
<label for="tel">Phone number</label>
<input id="tel" name="phone" type="tel" autocomplete="tel" />
</div>

</form>

Teams often get city, region, and postal code right visually but omit the semantic mapping. That’s where browser autofill support becomes inconsistent.

Payment form example

Payment screens deserve extra care because they mix user data, card data, security expectations, and third-party widgets.

<form>

<div>
<label for="cc-name">Name on card</label>
<input id="cc-name" name="cardName" type="text" autocomplete="cc-name" />
</div>


<div>
<label for="cc-number">Card number</label>
<input id="cc-number" name="cardNumber" type="text" inputmode="numeric" autocomplete="cc-number" />
</div>


<div>
<label for="cc-exp">Expiration date</label>
<input id="cc-exp" name="cardExpiry" type="text" autocomplete="cc-exp" />
</div>

</form>

When a payment provider injects hosted fields inside iframes, your team may not control the final markup. In that case, document the dependency, test the vendor implementation, and reflect any limitations in your procurement and conformance records.

A quick technical walkthrough can help teams align on the markup pattern before rollout:

Implementation rules that prevent rework

Most failures come from process, not difficulty.

• Map design-system components once: Put autocomplete support into your base input component API.
• Don’t use visible text as your only source of truth: A label that says “First Name” isn’t enough by itself.
• Avoid custom token inventions: Browsers won’t understand made-up values.
• Review conditional forms carefully: If fields appear based on earlier answers, the rendered input still needs the correct token.
• Coordinate with security teams: Some teams disable autofill globally. That can create unnecessary friction and doesn’t remove the need for correct field semantics.

Testing for WCAG 1.3.5 Compliance

Testing this criterion is straightforward when the form is simple, and surprisingly easy to get wrong when the form is generated by a framework, third-party script, or design-system abstraction.

Manual inspection that catches real issues

Start in the browser, not in a slide deck or ticket summary.

A reliable manual check looks like this:

1. Open the live form in Chrome, Edge, Firefox, or Safari.
2. Inspect the field element with developer tools.
3. Find the rendered <input>, not the component wrapper.
4. Check whether autocomplete is present on fields that collect user data.
5. Verify the token matches the field meaning, not just the visible label.
6. Repeat in state changes, such as modals, accordions, step forms, and conditional sections.

Review cue: Test the DOM users actually get after hydration, validation, and client-side rendering. That’s where many SPA regressions appear.

For example, a React component may accept an autoComplete prop, but the prop may never reach the final input because of prop filtering or a custom wrapper. Automated linting can miss that if it only sees the component API.

Where automated tools help and where they don’t

Automated tools are useful for finding obvious omissions. They’re weaker at validating meaning.

A scanner can often detect that an input lacks an autocomplete attribute. It usually can’t tell whether name, given-name, or organization-title is the correct semantic choice for the business field in front of the user.

That’s why teams should use automation as triage, not as proof of conformance. This is especially important if your process currently leans on browser extensions or CI-based scanners as the final signoff. A realistic review of accessibility testing tools and their limitations helps teams place automated checks in the right part of the workflow.

A practical QA checklist

Use this in release testing and in audit preparation:

• Eligible field check: Confirm the field collects information about the user, not generic content or search terms.
• Token accuracy check: Compare the actual field purpose against the standardized token used in code.
• Rendered DOM check: Verify the final browser output, especially in component libraries and single-page apps.
• Third-party form check: Inspect embedded auth, checkout, CRM, and payment widgets separately.
• Regression check: Re-test after design-system updates, checkout vendor changes, and form-builder migrations.

Manual review takes longer, but it’s the step that catches the expensive false passes.

Common Mistakes and Edge Case Solutions

Most implementation bugs aren’t dramatic. They’re small semantic mismatches that repeat across dozens of templates.

Wrong token for the field meaning

The classic mistake is choosing a broad token when a precise one exists. A field labeled “First name” shouldn’t use name if given-name is the accurate purpose. The code may look close enough to a developer, but close enough isn’t the standard that browsers or assistive technologies need.

Another frequent issue is treating every phone field the same when the form distinguishes between different contact purposes. If your UX and business logic clearly separate fields, your semantics should be equally deliberate.

Small token mistakes scale badly. One bad component can spread the same defect across every signup, checkout, and profile form in the product.

Custom components and single-page apps

Design systems often wrap native inputs with React, Vue, or Angular abstractions. That’s fine until the wrapper drops native attributes, renames them inconsistently, or renders a non-input element that breaks semantics.

The fix is operational, not just technical:

• Expose autocomplete in the component API
• Pass it through to the native control
• Test the rendered DOM after hydration
• Document approved tokens in component guidelines

For dynamic forms, validate the state where the field appears. Teams often test the initial view and miss the modal, drawer, or second-step screen where the bug lives.

Fields that usually fall outside the criterion

Not every form control needs input-purpose mapping. Common examples outside the intended scope include:

Field example	Usually outside SC 1.3.5
Search input	Yes
Comment box	Yes
Support message textarea	Yes
Product quantity	Yes

That boundary matters because over-applying the rule can create noisy remediation tickets. Keep the focus on standard user-data fields where recognized purposes exist.

Remediation Priorities and VPAT Wording

Fixing everything at once sounds disciplined. In practice, it slows down meaningful risk reduction. Prioritize forms that matter to customers, procurement reviewers, and legal stakeholders first.

DigitalA11Y highlights the practical history behind this criterion. It is strongly tied to autofill and personalization for people who struggle with repetitive data entry, especially users with cognitive disabilities. It also notes that HTML 5.2 defines 53 autocomplete tokens, and explains that the criterion has become part of the broader AA baseline used in public-sector and procurement contexts built on WCAG 2.1 and 2.2. Its summary also emphasizes that the rule is specifically about fields collecting user data, which makes it narrower and more testable than older, broader form expectations, as outlined in DigitalA11Y’s explanation of SC 1.3.5.

What to fix first

A sensible order is based on user impact and documentation exposure.

• Checkout and payment: High business sensitivity, frequent third-party dependencies, and common procurement scrutiny.
• Registration and account setup: Core conversion path and a common place for password-manager issues.
• Profile and account settings: Repeated user interaction means repeated friction if semantics are weak.
• Legacy internal forms exposed to customers or vendors: Often overlooked, often included in enterprise reviews.

If engineering capacity is limited, fix shared components before isolated pages. That gives you broader coverage and cleaner retesting.

Sample VPAT remarks

Your VPAT or ACR language should be accurate, restrained, and easy for a reviewer to follow.

Supports
User-data input fields that collect standard personal information expose programmatically determinable purpose through recognized HTML autocomplete values where applicable.

Partially Supports
Most user-data input fields expose programmatically determinable purpose through recognized HTML autocomplete values. Some legacy or third-party forms do not yet provide complete input-purpose mapping for all applicable fields.

Does Not Support
User-data input fields generally do not expose programmatically determinable purpose through recognized HTML autocomplete values, limiting interoperability with browsers, password managers, and assistive technologies.

Documentation habits that hold up in review

Good VPAT remarks depend on traceable evidence.

• List the tested forms: Name the workflows and screens reviewed.
• Separate first-party and third-party responsibility: Note hosted payment, identity, or CRM components.
• Keep remarks consistent with actual findings: Don’t claim broad support if known exceptions remain.
• Record remediation status: Closed, in progress, vendor-dependent, or accepted limitation.

A weak conformance statement creates more risk than a candid partial one. Reviewers usually respond better to precise scope and documented remediation than to vague blanket claims.

Frequently Asked Questions about Identify Input Purpose

Is autocomplete the same as a <label>?

No. A <label> tells users what the field is. autocomplete tells browsers and assistive technologies the standardized purpose of that field. You generally need proper labels regardless. For eligible user-data fields, visible labeling alone doesn’t satisfy the input-purpose requirement.

Does this apply to every input on the site?

No. It applies to fields collecting information about the user when that purpose can be programmatically identified using the standardized model discussed earlier. Search boxes, comment areas, and many freeform business-data fields usually aren’t the target of this criterion.

Can we use custom autocomplete values that match our product language?

No. Custom values defeat the point. The ecosystem depends on recognized tokens so user agents and assistive technologies can interpret field meaning consistently.

If the form is visually clear, isn’t that enough?

Not for this criterion. A human may understand the form perfectly while software still can’t determine each field’s intended purpose. WCAG 1.3.5 is specifically about exposing that meaning programmatically.

How should we handle VPAT language for partial implementation?

Be specific about which workflows support standardized input-purpose mapping and which ones don’t. If your legal or procurement team needs examples of how organizations describe that process, this guide on how to create a VPAT is a useful reference point for structure and review expectations.

Are automated scans enough to verify compliance?

No. They’re helpful for finding obvious omissions, but they often can’t confirm whether the chosen token matches the actual business meaning of the field. Manual review is still the reliable way to validate conformance.

---

If your team needs a defensible review of forms, component libraries, or VPAT wording for WCAG 1.3.5 and related Level AA issues, consider working with ADA Compliance Pros. They provide manual accessibility audits, remediation guidance, and procurement-ready documentation for websites, web apps, and digital products.