WCAG 1.3.5: Identify Input Purpose

What This Rule Means

WCAG 1.3.5 — Identify Input Purpose is a Level AA criterion introduced in WCAG 2.1 and carried forward into WCAG 2.2. It requires that any <input>, <select>, or <textarea> element that collects information about the user must have its purpose communicated programmatically, so that browsers and assistive technologies can identify and act on that purpose automatically.

The mechanism for meeting this criterion is the autocomplete attribute, combined with the correct token value from the official list defined in the HTML specification. When a field collects a user's name, email address, phone number, mailing address, credit card number, or similar personal data, the autocomplete attribute must carry a value that accurately describes that field's purpose — for example, autocomplete="given-name" for a first-name field, or autocomplete="email" for an email field.

The criterion applies specifically to inputs that collect information about the user themselves. It does not apply to fields where a user is entering data about someone else (for example, a travel booking form asking for a passenger's name when the user is booking on behalf of another person), nor does it apply to fields where autocomplete would create a security risk — such as one-time passwords or CAPTCHA-style challenges, which can legitimately use autocomplete="off" or autocomplete="one-time-code".

A pass requires that: (1) every in-scope input field carries an autocomplete attribute; and (2) the value of that attribute is a valid, recognized token from the HTML autofill specification — not an arbitrary string, not an empty value where a meaningful one is required, and not a misspelled token. A fail occurs when an in-scope input has no autocomplete attribute, has autocomplete="off" without justification, or has an invalid token such as autocomplete="firstname" (the correct token is given-name) or autocomplete="phone" (the correct token is tel).

The full list of valid autocomplete tokens is maintained by the WHATWG HTML Living Standard and includes values for names (given-name, family-name, additional-name), addresses (street-address, address-line1, postal-code, country-name), contact information (email, tel, tel-national), credentials (username, current-password, new-password), payment details (cc-name, cc-number, cc-exp, cc-csc), and more. Tokens can also be prefixed with section identifiers (e.g., section-billing) and shipping or billing keywords to handle multiple address groups on a single page.

Why It Matters

This criterion exists primarily to benefit users with cognitive disabilities, including people with dyslexia, memory impairments, attention-deficit conditions, and learning disabilities. For these users, correctly filling in a complex checkout form — with separate fields for given name, family name, street address, city, postal code, phone, and payment details — can be a significant cognitive burden. When autocomplete tokens are correct, browsers can pre-populate fields from the user's saved profile with a single interaction, dramatically reducing friction and the risk of errors.

Users with motor impairments — including people with limited hand function who use switch access, eye-tracking software, or sip-and-puff devices — benefit equally. Typing is slow, effortful, and sometimes painful for these users. Autofill that works reliably can transform a ten-minute ordeal into a near-instant task. According to the World Health Organization, approximately 1.3 billion people globally live with some form of significant disability, and motor impairments affecting fine hand control are among the most common.

Beyond autofill, correct autocomplete tokens allow browsers and assistive technologies to present custom icons, labels, or augmented input interfaces — for example, displaying a phone keypad automatically for a tel field on a mobile device, or showing a credit card graphic for a cc-number field. Password managers, which are critical accessibility tools for users with memory impairments, also rely on these tokens to identify and fill credential fields correctly.

Consider a real-world scenario: a user with cerebral palsy is completing a government benefits application. The form has twelve fields covering name, address, national ID, and contact details. Without correct autocomplete values, every field must be typed manually. One misspelled token — say, autocomplete="surname" instead of autocomplete="family-name" — is enough to prevent the browser from recognizing the field, leaving the user to type their family name character by character. With correct tokens, the entire form can be autofilled in seconds, reducing both effort and error rates.

There are also usability and conversion-rate benefits for organizations: research consistently shows that autofill-compatible forms have lower abandonment rates and higher completion rates, meaning that fixing autocomplete tokens is not only an accessibility improvement but a direct business improvement.

Related Axe-core Rules

• autocomplete-valid — This is the primary axe-core rule for WCAG 1.3.5. It inspects every <input>, <select>, and <textarea> element that has an autocomplete attribute and checks whether the attribute's value is a recognized, valid token from the HTML autofill specification. The rule flags elements where the token is misspelled (e.g., given name with a space instead of a hyphen), where a non-standard proprietary value has been used (e.g., autocomplete="first-name"), or where the token order in a multi-token value is incorrect (e.g., placing a field name before a required section prefix). The rule does not flag fields that are missing an autocomplete attribute entirely — that situation requires manual review — because axe-core cannot determine programmatically whether a given field is in scope for the criterion (i.e., whether it collects information about the user).
• Why manual testing is also required — Automated tools like axe-core can only validate that a present autocomplete value is syntactically correct; they cannot determine whether the chosen token accurately describes the field's purpose. For example, a billing phone field with autocomplete="email" would pass the automated rule (since email is a valid token) but would fail the criterion because the token does not match the field's actual purpose. Similarly, automated tools cannot identify fields that are missing an autocomplete attribute but should have one, because determining whether a field collects personal information about the user requires human judgment based on context. Manual review of every form field that collects user-specific data is therefore essential for full compliance with 1.3.5.

How to Test

1. Run an automated scan with axe DevTools or Lighthouse. Open the page containing the form in Chrome or Firefox. In axe DevTools, click "Analyze" and filter results by the rule ID autocomplete-valid. In Lighthouse, run an accessibility audit and look for violations referencing autocomplete. Note every element flagged and record the invalid token values reported. Resolve each flagged element and re-scan to confirm the fix.
2. Manually identify all in-scope input fields. Review the form and list every field that collects information about the current user — name fields, address fields, email, phone, payment details, credentials. For each field, verify that an autocomplete attribute is present and that its token matches the field's actual purpose according to the HTML autofill token list. Fields collecting information about other people are out of scope and can be excluded.
3. Test browser autofill behavior. In Chrome or Firefox, ensure the browser has a saved profile (Settings > Autofill). Navigate to the form page and click into the first personal information field. Confirm that the browser presents an autofill suggestion and that selecting it populates the correct fields with the correct values. Repeat for address fields, payment fields, and credential fields. If autofill fails to suggest values or populates the wrong fields, the autocomplete tokens are likely incorrect.
4. Test with a screen reader and browser combination. With NVDA and Firefox, navigate to each form field using the Tab key. NVDA should announce the field's label and purpose; some screen reader and browser combinations will also announce the autocomplete purpose. With VoiceOver on macOS (Safari), navigate fields using Tab and listen for VoiceOver announcing autofill availability. With JAWS and Chrome, similarly tab through fields and confirm JAWS announces expected field context. While screen readers do not always explicitly announce autocomplete tokens, confirming that autofill works correctly in combination with keyboard navigation validates the programmatic purpose is exposed.
5. Inspect autocomplete attributes in the browser DevTools. Right-click each form field and select "Inspect." In the Elements panel, confirm the autocomplete attribute is present and that its value exactly matches a valid token. Pay particular attention to multi-token values — for example, autocomplete="shipping street-address" — and confirm the token order follows the specification (section name, then "shipping" or "billing", then field name).

How to Fix

Name fields — Incorrect

<!-- Invalid: uses non-standard token 'firstname' instead of 'given-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='firstname'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='surname'>

Name fields — Correct

<!-- Valid: uses the exact WHATWG-specified tokens 'given-name' and 'family-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='given-name'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='family-name'>

Address form with billing and shipping sections — Incorrect

<!-- Invalid: missing autocomplete attributes entirely on address fields -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' placeholder='Street Address'>
  <input type='text' name='bill_city' placeholder='City'>
  <input type='text' name='bill_postal' placeholder='Postal Code'>
</fieldset>

Address form with billing and shipping sections — Correct

<!-- Valid: autocomplete tokens include 'billing' prefix and correct field names -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' autocomplete='billing street-address' placeholder='Street Address'>
  <input type='text' name='bill_city' autocomplete='billing address-level2' placeholder='City'>
  <input type='text' name='bill_postal' autocomplete='billing postal-code' placeholder='Postal Code'>
</fieldset>

Telephone field — Incorrect

<!-- Invalid: uses 'phone' which is not a recognized autocomplete token -->
<label for='tel'>Phone Number</label>
<input type='text' id='tel' name='telephone' autocomplete='phone'>

Telephone field — Correct

<!-- Valid: 'tel' is the correct autocomplete token for a full phone number -->
<label for='tel'>Phone Number</label>
<input type='tel' id='tel' name='telephone' autocomplete='tel'>

Login credentials — Incorrect

<!-- Invalid: autocomplete='off' prevents password managers and autofill from working -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='off'>

<label for='pass'>Password</label>
<input type='password' id='pass' name='password' autocomplete='off'>

Login credentials — Correct

<!-- Valid: 'username' and 'current-password' allow password managers to function correctly -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='username'>

<label for='pass'>Password</label>
<input type='password' id='pass' name='password' autocomplete='current-password'>

Common Mistakes

• Using autocomplete="firstname" or autocomplete="first-name" instead of the correct token given-name". These non-standard values are not recognized by browsers or assistive technologies even though they appear logical. Always use the exact tokens from the HTML autofill specification.
• Using autocomplete="phone" instead of autocomplete="tel". The word "phone" is not a valid token. The specification uses tel for a full telephone number, and tel-national, tel-area-code, tel-local for sub-parts of a phone number.
• Setting autocomplete="off" on credential fields as a misguided security measure. Modern browsers and the WCAG specification both recognize that preventing autofill on login forms creates real barriers for users with disabilities and does not meaningfully improve security. Use autocomplete="username" and autocomplete="current-password" instead.
• Omitting the autocomplete attribute entirely on personal data fields, assuming the browser will infer the purpose from the field name or label. Browsers use heuristics to guess field purpose, but these are unreliable and inconsistent across browsers. Explicit tokens are required for a guaranteed, accessible experience.
• Using autocomplete="address" instead of the specific address sub-tokens. There is no address token in the specification. You must use street-address, address-line1, address-line2, address-level1 (state/province), address-level2 (city), and postal-code individually.
• Placing shipping or billing keywords in the wrong order in multi-token values. The correct order is: optional section prefix (e.g., section-billing), then optional shipping/billing keyword, then the field name token. Writing autocomplete="street-address billing" is invalid; the correct form is autocomplete="billing street-address".
• Applying autocomplete only to visible fields and ignoring hidden or dynamically revealed fields. Fields that are hidden initially but revealed through user interaction (such as additional address lines or optional fields) must also carry correct autocomplete tokens when they become active.
• Using JavaScript to dynamically strip or overwrite the autocomplete attribute after page load. Some form libraries or UI frameworks reset input attributes when components mount or re-render, inadvertently removing autocomplete tokens. Always verify that the attribute persists in the live DOM after all JavaScript has executed.
• Assuming that type="email" or type="tel" on an input is sufficient to communicate purpose without autocomplete. While type provides some information, the autocomplete attribute is a separate, explicit signal required by WCAG 1.3.5 and used differently by browsers and assistive technologies.
• Using the same autocomplete token on two different fields that collect different data. For instance, labeling both a work email field and a personal email field with autocomplete="email" confuses browsers and may result in incorrect autofill. Use section prefixes (e.g., section-work email vs. section-personal email) to disambiguate.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes binding accessibility requirements for a broad range of organizations operating in Turkey. The Circular mandates conformance with WCAG 2.2 at Level AA as the baseline standard for digital services, which directly includes WCAG 1.3.5 — Identify Input Purpose.

The entity types covered by the Circular are wide-ranging. Public institutions and government agencies are required to meet these standards for all citizen-facing digital services. Private sector organizations covered include e-commerce platforms, banks and financial service providers, hospitals and healthcare providers, telecommunications operators with 200,000 or more subscribers, licensed travel agencies, private passenger transport companies, and private educational institutions authorized by the Ministry of National Education (MoNE). The practical implication is that virtually every major consumer-facing digital product in Turkey — from banking apps to online retail checkouts to healthcare appointment portals — must have correctly implemented autocomplete tokens on all personal data input fields.

For WCAG 1.3.5 specifically, this means that any Turkish e-commerce checkout form, bank account opening form, hospital patient registration form, or telecom subscription form that collects user information such as name, address, phone number, or payment details must include valid autocomplete attribute values on every relevant input field. Failure to do so constitutes a Level AA non-conformance and can prevent an organization from obtaining or retaining the Accessibility Logo (Erişilebilirlik Logosu), the official mark issued by the Ministry of Family and Social Services that certifies an organization's digital services meet accessibility standards.

The Accessibility Logo carries reputational and regulatory weight, and organizations in competitive consumer markets — such as e-commerce and banking — have strong incentives to achieve and maintain it. Because WCAG 1.3.5 is straightforward to implement (adding or correcting autocomplete attribute values requires no architectural changes) yet provides significant benefit to users with cognitive and motor disabilities, it represents one of the highest-value, lowest-effort accessibility improvements an organization can make in pursuit of full Level AA conformance under the 2025/10 Circular.

Organizations should audit all forms across their digital properties — including mobile web interfaces and responsive layouts — and establish a development policy that requires correct autocomplete tokens as a standard part of any form implementation. This should be enforced through automated testing in CI/CD pipelines using tools such as axe-core, so that regressions are caught before they reach production.