Form field autocomplete attribute is missing or invalid

What is this issue?

A form input, select, or textarea that collects one of the recognized categories of personal information, such as a given name, email address, telephone number, or street address, either has no autocomplete attribute at all, or has one whose value doesn’t match any token from the standard list WCAG 1.3.5 defines (things like given-name, email, tel, street-address, postal-code).

The field might work perfectly for someone typing manually. The failure is specifically that its purpose isn’t exposed programmatically: nothing in the DOM tells a browser, a password manager, or assistive technology what kind of data belongs in this box, beyond whatever hints the input’s type or a nearby visible label happen to give.

Why does this matter?

Autofill isn’t a convenience feature for everyone; for a lot of users it’s the difference between completing a form and abandoning it. Someone with a motor impairment who finds typing slow and error-prone, someone with a cognitive disability who struggles to recall and correctly type their own address every time, or someone with low vision zoomed in far enough that most of the form is scrolled off-screen all rely on the browser filling fields in accurately rather than requiring careful manual entry field by field.

When autocomplete is missing or invalid, none of that machinery engages. The browser has no reliable signal for what a field wants, so it either guesses wrong, offers nothing, or fills in the wrong category of data entirely: a first-name field silently getting a full name pasted into it because the browser’s best guess from context was wrong.

Who is affected?

• Cognitive disabilities: rely on autofill to avoid re-typing information from memory, especially on long forms where recalling and re-entering the same details field by field increases the chance of a mistake.
• Motor impairments: benefit the most from autofill’s reduction in the sheer number of keystrokes or taps a manual form requires, particularly for anyone using a switch device, head pointer, or on-screen keyboard.
• Low vision: using significant screen magnification, where most of a form is scrolled out of view at any moment, depend on autofill to avoid the slow, error-prone process of manually locating and typing into each zoomed-in field.

What users experience

Marcus has a motor impairment and navigates the web primarily by keyboard, using Chrome’s built-in autofill to avoid the fatigue of typing out his full name, address, and phone number on every form. He reaches a checkout page whose address fields have no autocomplete attributes because the developer built custom-styled inputs from scratch without carrying the attribute over. Chrome’s autofill panel doesn’t appear at all for this section, so Marcus has to type his full shipping address manually, field by field, a task that takes him several times longer than the autofill-enabled billing section two steps earlier in the same flow.

How do I fix it?

Add the correct autocomplete value to every input that collects one of the categories on the WCAG 1.3.5 token list. This works because autocomplete is the specific, standardized mechanism browsers, password managers, and assistive technology all read to identify a field’s purpose; no other HTML attribute carries this level of specific, machine-readable meaning.

Match the token to what the field actually collects, not just its input type: type="text" tells a browser nothing about whether the field wants a first name, a last name, or a company name, while autocomplete="given-name", autocomplete="family-name", or autocomplete="organization" each say exactly one specific thing. For a multi-part address, use the more granular tokens (address-line1, address-level2, postal-code) rather than a single generic street-address when your form actually separates those fields.

Code Examples

<input type="text" name="fname">
<input type="email" name="email">
<input type="tel" name="phone">

<input type="text" name="fname" autocomplete="given-name">
<input type="text" name="lname" autocomplete="family-name">
<input type="email" name="email" autocomplete="email">
<input type="tel" name="phone" autocomplete="tel">
<input type="text" name="postcode" autocomplete="postal-code">

Each field now carries a specific, recognized autocomplete token that names exactly what it collects, rather than leaving the browser to infer purpose from type or field naming conventions alone, inference that’s unreliable across different browsers and autofill implementations.

Framework Examples

React’s JSX uses the camelCase prop autoComplete, not the lowercase HTML attribute autocomplete, a common source of this failure in React codebases, since the prop silently does nothing if it’s typed in the HTML attribute’s casing instead.

function NameField() {
  return (
    <input
      type="text"
      name="fname"
      autoComplete="given-name"
      onChange={(event) => handleChange(event.target.value)}
    />
  );
}

React renders autoComplete (capital C) down to the correct lowercase autocomplete HTML attribute in the DOM, but if you write autocomplete in lowercase directly in JSX, React passes it through as an unrecognized custom attribute instead of the standard one, and autofill silently fails to engage with no console warning to flag the typo.

Common Mistakes

Mistake: “The input type already tells the browser what the field is for.” type="email" or type="tel" narrows the expected format of the input, but carries none of the specific purpose information autocomplete does; it can’t distinguish a shipping address’s postal code from a billing address’s, or a work email from a personal one. The two attributes solve different problems and this criterion specifically requires the second one.

Mistake: “autocomplete is just a browser convenience feature, not an accessibility requirement.” WCAG 1.3.5 exists precisely because that “convenience” is a necessity for many users with motor, cognitive, and low-vision disabilities; the requirement treats programmatic purpose identification as a first-class accessibility feature, not an optional nicety layered on top.

Mistake: “I set autocomplete=“on” on the form element, so every field inside is covered.“ A form-level autocomplete="on" (the default) only controls whether autofill is permitted at all; it does not identify any individual field’s purpose. Each personal-information field still needs its own specific token like email or given-name for autofill and assistive technology to actually recognize what it collects.

How RedFlag Detects This

Automated: axe-core rule, runs on every scan. RedFlag calls axe-core’s autocomplete-valid rule as part of every scan, restricted to the WCAG 2.0/2.1/2.2 A and AA rule set. The rule inspects autocomplete attribute values on form fields and checks them against the standard token list defined by the HTML specification, flagging any value that isn’t a recognized token (a typo, an invalid combination, or an unsupported custom string).

False negative: the check validates that a value is a recognized token; it cannot tell whether that token is the correct one for what the field actually collects, so autocomplete="family-name" on a field that’s really asking for a company name passes the automated check while still misidentifying the field’s purpose. False positive: none typical for this check, since matching a value against a fixed, well-defined token list is something axe-core evaluates reliably. Manual step: for every field with a personal-information purpose, confirm the specific token matches what the field actually collects, not just that some valid token is present.

Manual Testing

1. Open a form field that collects personal information (name, email, address, phone) in Chrome or Firefox.
2. Start typing into the field, or focus it after the browser has previously stored relevant autofill data, and check whether the browser’s native autofill suggestion appears.
3. If no autofill suggestion appears for a field that should reasonably offer one, inspect the field’s autocomplete attribute in DevTools and confirm it’s present and spelled correctly.
4. For a field with an autocomplete value already set, confirm the token matches the field’s actual purpose: a first-name field should use given-name, not a mismatched or overly generic token.

Related WCAG Success Criteria

1.3.5 Identify Input Purpose: The purpose of each input field collecting information about the user must be programmatically determinable, when that purpose is one of the criterion’s defined categories. A missing or invalid autocomplete value is the direct, primary way to fail this criterion; it’s essentially the sole mechanism the criterion is built around.

Related Issues

Form input has no label covers the separate, more fundamental naming requirement every field needs; a correctly labeled field can still fail this rule if it’s missing a purpose-identifying autocomplete value on top of its label.

Form field has more than one label is a different labeling defect on the same class of personal-information fields this rule covers, often appearing on the same forms.

Input only uses placeholder as its label covers a related failure where a personal-information field’s only visible hint disappears the moment the user starts typing, a separate problem from missing autofill support, but frequently found on the same broken forms.

Form error is not clearly identified matters more, not less, when autocomplete is broken: users forced to type personal information manually are more likely to make an error the form then needs to identify clearly.

User must re-enter information already provided in the same process shares this rule’s underlying goal of reducing unnecessary manual re-entry: one prevents redundant typing within a single field via autofill, the other across an entire multi-step process.

References

• W3C Understanding 1.3.5: Identify Input Purpose
• W3C Technique H98: Using HTML 5.2 autocomplete attributes
• MDN: autocomplete attribute values