Identify Input Purpose

In brief

Typing a name, an address and a card number again and again is hard for people with motor impairments, memory or attention difficulties, and dyslexia. Browsers and assistive tools can fill these fields in for them, but only if they know what each field is for.

This criterion requires that the purpose of an input field can be determined programmatically when the field collects information about the user and its purpose is in the list of input purposes in WCAG. On the web this means giving the field an autocomplete attribute with the matching token, such as given-name or email.

What does it cover?

• Which fields: Fields that collect information about the user: name, username, address, phone, email, birthday, payment card and similar items from the WCAG list of input purposes.
• Which fields are not covered: Fields that do not collect information about the user, for example a search box, a coupon code or a field for someone else's details.
• The tokens: Values of the autocomplete attribute from the HTML specification, such as name, given-name, family-name, email, tel, street-address, postal-code, country, username, current-password, new-password, cc-number and cc-exp.
• Custom controls: If you build your own control instead of a native input, the purpose must still be available in code.
• Out of scope: Labels are covered by 1.3.1 and 3.3.2. Entering information again is covered by 3.3.7 (Redundant Entry), and authentication by 3.3.8 (Accessible Authentication).

Who does it affect?

People with motor impairments type less when fields are filled in for them. People with memory, attention or learning differences, including dyslexia, make fewer errors. People who use symbols or icons to understand a field benefit from tools that show the purpose. Anyone who fills in forms on a small screen saves time.

In the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Making the purpose of a field available in code is part of "perceivable" and "understandable".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 1.3.5 by reference and turns it into separate clauses for each kind of ICT.

Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.

Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 1.3.5 is the same in WCAG 2.1 and 2.2. It is a Level AA criterion.

A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.

Directive (EU) 2019/882, EUR-Lex, opens in a new tab

Code examples for the web

1. Name fields

Use the token that matches the field. A single "name" field uses name.

<label for="fn">First name</label>
<input id="fn" name="fn">
<label for="ln">Last name</label>
<input id="ln" name="ln">

<label for="fn">First name</label>
<input id="fn" name="fn" autocomplete="given-name">
<label for="ln">Last name</label>
<input id="ln" name="ln" autocomplete="family-name">

2. Email and phone

Combine the right input type with the matching token.

<input type="text" name="mail">
<input type="text" name="phone">

<label for="mail">Email</label>
<input id="mail" type="email" name="mail" autocomplete="email">
<label for="phone">Phone</label>
<input id="phone" type="tel" name="phone" autocomplete="tel">

3. Address

Each part of an address has its own token.

<input name="addr">
<input name="zip">
<input name="ctry">

<label for="addr">Street address</label>
<input id="addr" name="addr" autocomplete="street-address">
<label for="zip">Postal code</label>
<input id="zip" name="zip" autocomplete="postal-code">
<label for="ctry">Country</label>
<input id="ctry" name="ctry" autocomplete="country-name">

4. Sign in and sign up

Use current-password on a sign-in form and new-password when the user creates a password. This also helps password managers.

<input type="text" name="u">
<input type="password" name="p">

<label for="u">Username</label>
<input id="u" name="u" autocomplete="username">
<label for="p">Password</label>
<input id="p" type="password" name="p" autocomplete="current-password">

5. Payment card

Card fields have their own tokens.

<input name="card">
<input name="exp">
<input name="cvv">

<label for="cc">Card number</label>
<input id="cc" name="cc" inputmode="numeric" autocomplete="cc-number">
<label for="exp">Expiry date</label>
<input id="exp" name="exp" autocomplete="cc-exp">
<label for="cvv">Security code</label>
<input id="cvv" name="cvv" inputmode="numeric" autocomplete="cc-csc">

6. Do not turn autocomplete off on personal data fields

autocomplete="off" on a personal data field takes the help away. Use it only where the field is not about the user, or where there is a real security reason.

<input type="email" name="mail" autocomplete="off">

<input type="email" name="mail" autocomplete="email">

Code examples for mobile

The same rule applies in native mobile apps. Give each field the content type that the platform uses for autofill.

iOS (SwiftUI)

import SwiftUI

struct SignUpForm: View {
    @State private var firstName = ""
    @State private var lastName = ""
    @State private var email = ""

    var body: some View {
        Form {
            TextField("First name", text: $firstName)
                .textContentType(.givenName)

            TextField("Last name", text: $lastName)
                .textContentType(.familyName)

            TextField("Email", text: $email)
                .textContentType(.emailAddress)
                .keyboardType(.emailAddress)
        }
    }
}

Android (Jetpack Compose)

import androidx.compose.foundation.layout.Column
import androidx.compose.material3.OutlinedTextField
import androidx.compose.material3.Text
import androidx.compose.runtime.*
import androidx.compose.ui.Modifier
import androidx.compose.ui.autofill.ContentType
import androidx.compose.ui.semantics.contentType
import androidx.compose.ui.semantics.semantics

// Requires a recent Compose UI version (1.8 or newer)
@Composable
fun SignUpForm() {
    var firstName by remember { mutableStateOf("") }
    var email by remember { mutableStateOf("") }

    Column {
        OutlinedTextField(
            value = firstName,
            onValueChange = { firstName = it },
            label = { Text("First name") },
            modifier = Modifier.semantics {
                contentType = ContentType.PersonFirstName
            }
        )
        OutlinedTextField(
            value = email,
            onValueChange = { email = it },
            label = { Text("Email") },
            modifier = Modifier.semantics {
                contentType = ContentType.EmailAddress
            }
        )
    }
}

How to test

• List the personal data fields: Find every field that collects information about the user: name, address, contact details, sign-in and payment.
• Inspect the code: Does each of these fields have an autocomplete attribute, and is the token correct and valid? In mobile apps, is the content type set?
• Try the browser autofill: Save a profile in the browser, then open the form. Does the browser offer to fill every field correctly?
• Try a password manager: Does it recognize the sign-in and sign-up fields?
• Look for autocomplete="off": Is it used on fields about the user? Is there a reason for it?
• Check custom controls: If a field is built from custom elements, is its purpose available in code?
• Use a checker as a start: Automated tools can check that the token is valid and that it fits the field. Only a person can decide whether the field is about the user.

Common mistakes

• No autocomplete at all: The most common failure.
• Using an invalid or invented token: Values such as autocomplete="fname" are not in the specification and are ignored.
• Using the wrong token: For example name on a last-name field.
• Turning autocomplete off to "protect" the user: It takes the help away and does not make the form safer.
• Using the wrong input type: A text field for an email address misses the keyboard and the validation of the right type.
• Splitting one value into many fields: A card number in four boxes, a date in three: the browser cannot fill them in well.
• Forgetting to add the token when you rename a field: The token and the name are different things.
• Forgetting mobile: Native forms need the content type as well.

Sources

• Understanding SC 1.3.5: Identify Input Purpose (W3C), opens in a new tab
• Input Purposes for User Interface Components (W3C), opens in a new tab
• H98: Using HTML autocomplete attributes (W3C), opens in a new tab
• Directive (EU) 2019/882, European Accessibility Act (EUR-Lex), opens in a new tab
• EN 301 549 V4.1.1 (ETSI), opens in a new tab
• The European accessibility standard EN 301 549 has been updated (AccessibleEU), opens in a new tab

Standard version: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official texts of the European Accessibility Act (Directive (EU) 2019/882) and EN 301 549.