WCAG 1.3.5 Identify Input Purpose: A Guide to Accessible Form Fields

WCAG 1.3.5 Identify Input Purpose requires that the purpose of certain form fields can be determined programmatically so browsers, autofill systems and assistive technologies can treat them correctly. This short guide explains what the success criterion covers, how to implement it in HTML, how to test it, and common mistakes to avoid.

What WCAG 1.3.5 requires

The success criterion requires that inputs with a predictable purpose are marked so their purpose is programmatically determinable. That lets user agents and platform autofill identify fields such as name, email, telephone, address and payment fields. The requirement appears at level AA in WCAG 2.1.

Which form controls this covers

Only inputs whose purpose is one of a defined list need to be identified. Typical purposes you will meet most often include:

• name, given-name, family-name
• email and username
• tel and telephone parts
• street-address, postal-code, country
• credit card data such as cc-number and cc-exp
• password fields such as current-password and new-password

How to meet WCAG 1.3.5 in HTML

The recommended, sufficient technique for web content is to use the HTML autocomplete attribute with the appropriate token. That makes the field purpose available to browsers and autofill APIs.

Simple examples

• Name field: add autocomplete=“name”
• Email field: add autocomplete=“email”
• Postal code: add autocomplete=“postal-code”
• Credit card number: add autocomplete=“cc-number”
• Password fields: use autocomplete=“current-password” or autocomplete=“new-password”

Place the attribute on the same control element that accepts the user input. If you use custom widgets, ensure the widget exposes the programmatic token in the accessibility tree or via the platform API.

Native apps and platform autofill

On mobile and native platforms, map the HTML tokens to the platform equivalents. Examples include iOS UITextContentType and Android autofill hints. If your framework exposes an autofill API, set the appropriate hint so the platform can identify the purpose.

Testing and verification

Use a mix of automated checks and manual tests. Follow these steps:

1. Inspect the DOM to confirm autocomplete values are present and correct for each relevant field.
2. In a browser, try autofill with saved data to ensure the right values populate the right fields.
3. Use accessibility inspection tools to view the accessibility tree and confirm the control exposes its purpose to assistive technology.
4. Test with a screen reader such as NVDA or VoiceOver to ensure identifying information does not conflict with spoken labels or announcements.
5. Run an automated tool like axe or WAVE to catch common implementation errors. Automated tests only find some problems, so include the manual checks above.

Common mistakes to avoid

• Using incorrect or misspelled autocomplete tokens. Tokens must match the spec tokens exactly.
• Relying only on visible labels or placeholder text. Those are not programmatic signals for autofill.
• Putting the token on a wrapper element instead of the actual input control.
• Using generic tokens like autocomplete=“on” without a specific purpose token when a specific token exists.
• Breaking the expected field order so autofill assigns values to the wrong inputs.

Practical step-by-step checklist

1. List every input that collects name, contact, address, payment or account data.
2. Assign the correct autocomplete token to each input control.
3. Keep form field order logical and consistent with typical forms.
4. Add clear, programmatic labels using label elements or accessible equivalents.
5. Test autofill in desktop browsers and on mobile platforms with real saved data.
6. Verify the accessibility tree shows the control and that assistive tech can use it.

Edge cases and when this may not apply

This success criterion applies only to inputs with a predictable, standard purpose. If a field collects an idiosyncratic value that does not map to a known token, marking it with a token is not required. Also, if a control is solely decorative or used only for visual layout, it is not in scope. When in doubt, choose the closest standard token and document the decision.

Quick reference

• Primary implementation: use HTML autocomplete with the correct token.
• Mobile/native: set the platform autofill or text content type hint.
• Test: DOM inspection, browser autofill, accessibility tree and a screen reader.

Final notes

Identifying input purpose improves form usability for everyone. It reduces data-entry time and helps assistive technologies provide better hints. Follow the checklist above and include both automated and manual tests before declaring a form compliant with WCAG 1.3.5.