Autocomplete for Enrollment, Sign-in and Payment Forms

Telling the browser what a field is for

An enrollment, benefits or utility form asks for the same few things again and again: name, address, phone, email, card details. For someone with a tremor, a memory difficulty or dyslexia, each field typed by hand is a place to make an error or give up. Browsers and assistive tools can fill these in, and some can show a familiar icon beside the field, but only if the field says what it is for.

WCAG 1.3.5 (Level AA) requires that the purpose of each input field collecting information about the user can be programmatically determined, when the field serves one of the purposes in WCAG's list of input purposes and the technology supports it. On the web this is the autocomplete attribute, whose values are fixed and independent of language.

Which fields are in scope

• In scope: fields that collect information about the user and match a listed purpose, such as name, username, address, phone, email, birthday and payment card details.
• Out of scope: fields that do not collect information about the user, such as a search box, a permit number, or a transaction amount.
• Another person's details: the token describes the user's own data. A parent filling in a child's name is entering information about someone else.
• Not the same as type: type="email" does not tell whether the address is the user's or another person's, so it is too broad on its own.

Whether a browser actually autofills does not decide conformance; what matters is that the purpose is exposed. Autofill can still be turned off for a form while each field keeps its token.

School enrollment, benefits and bill-pay forms

The forms that residents complete most often are also the longest: school district enrollment, benefits renewal, utility bill payment, library card applications. They repeat the same personal details, and they are often completed on a phone with a keyboard that is hard to use. DOJ's list of common barriers includes inaccessible forms; marking the purpose of fields is a low-cost way to make them easier for people who rely on autofill or on tools that add icons and clearer labels. See common barriers for other recurring form problems.

Web: tokens for enrollment, sign-in and payment

Use the token that names the data, on the field that collects it.

<label for="fn">Parent or guardian first name</label>
<input id="fn" name="fn" type="text">
<label for="em">Email</label>
<input id="em" name="em" type="email">
<label for="zip">ZIP code</label>
<input id="zip" name="zip" type="text">

<label for="fn">Parent or guardian first name</label>
<input id="fn" name="fn" type="text" autocomplete="given-name">
<label for="em">Email</label>
<input id="em" name="em" type="email" autocomplete="email">
<label for="zip">ZIP code</label>
<input id="zip" name="zip" type="text" autocomplete="postal-code">

Sign-in forms have their own tokens, which also help password managers.

<label for="acct">Account number or email</label>
<input id="acct" name="acct" type="text">
<label for="pw">Password</label>
<input id="pw" name="pw" type="password">

<label for="acct">Account number or email</label>
<input id="acct" name="acct" type="text" autocomplete="username">
<label for="pw">Password</label>
<input id="pw" name="pw" type="password" autocomplete="current-password">

Payment details have a dedicated set of tokens.

<input name="holder" aria-label="Name on card">
<input name="card" aria-label="Card number" inputmode="numeric">
<input name="exp" aria-label="Expiry date">

<input name="holder" aria-label="Name on card" autocomplete="cc-name">
<input name="card" aria-label="Card number" inputmode="numeric"
       autocomplete="cc-number">
<input name="exp" aria-label="Expiry date" autocomplete="cc-exp">

Native apps: autofill hints

Native toolkits expose the same idea as content types or autofill hints.

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

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

OutlinedTextField(
    value = email,
    onValueChange = { email = it },
    label = { Text("Email") }
)

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

How to check it

1. List every field on the form that collects the user's own information.
2. Inspect each one and read its autocomplete value. Compare it with the list of tokens in the HTML specification.
3. Look for misspellings, tokens that name a different purpose, and fields where a token is missing.
4. Try the form with a browser's autofill or a password manager. A working fill is a good sign, though it does not prove conformance.

Automated tools can validate token values and flag missing ones; whether a field truly collects the user's data is a judgement a person makes.

Mistakes seen in forms

• Inventing values, such as autocomplete="fname".
• Using autocomplete="off" on fields that should name their purpose.
• Putting a user token such as email on the field for someone else's email.
• Splitting a card number across several unlabeled boxes, so no token applies.
• Building a custom control that renders as a div and exposes no purpose.

Ship it when

• Each field about the user carries the matching autocomplete token.
• Fields that are not about the user carry none.
• Custom controls expose the purpose as well as native inputs do.

Sources

• Understanding SC 1.3.5: Identify Input Purpose (W3C), opens in a new tab
• H98: Using HTML autocomplete attributes (W3C), opens in a new tab
• 28 CFR Part 35, Subpart H: Accessibility of Web Information and Services (eCFR), opens in a new tab

Standard version: WCAG 2.1 (W3C Recommendation, 5 June 2018), as named in the Title II web rule. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official ADA statute and regulations, and ask a lawyer how they apply to you.