Autocomplete Attributes That Let Browsers Fill Inquiry Forms

An inquiry form is usually the last step between a visitor who has decided to get in touch and a message that actually arrives. That step often asks for details the visitor’s browser already holds: full name, work email, phone number, company. When the form’s markup doesn’t say what each field is for, the browser has to guess. Sometimes it guesses right. Sometimes it offers nothing, and the visitor types everything again on a phone keyboard.

The HTML Standard has a direct answer to this: the autocomplete attribute and its list of named tokens. This article covers what those tokens tell the browser, what Chrome’s field data and an independent autofill study show about their effect, and how to add them to a service-site inquiry form without creating new errors.

---

Why inquiry forms leave autofill guessing

Most service-site forms are put together from a page builder, a form plugin, or custom components. Each one names its fields in its own way: field_3, input-a7f2, your-name. People read the visible label. Browsers mostly see the markup.

The WHATWG HTML Living Standard describes what happens when the markup says nothing specific. If autocomplete is missing, the field takes the default from its form’s own autocomplete setting, which is usually on. With on, the specification says user agents “would have to use heuristics” to decide what to suggest, working from clues like the field’s name, its position, and the other fields in the form.

Heuristics work well on common checkout layouts. Custom inquiry forms tend to break them in a few predictable ways:

1. Generated field names. Some builders change names or IDs on each deployment. Google’s Chrome guidance for sign-up forms notes that, to store data for later autofill, modern browsers need a stable name or id and an input inside a <form> element with a submit button.
2. Ambiguous labels. A field labelled “Website” could mean the visitor’s current site or a site they admire. A field labelled “Contact” could mean an email address or a phone number.
3. Split or unusual structures. Separate first-name and last-name boxes, or a phone number split across three inputs, give the browser more pieces to match correctly.

Each failed guess means more typing, right when the visitor is about to send the message.

---

What the autocomplete attribute declares

The HTML Standard defines autocomplete as a hint “to the user agent how to, or indeed whether to,” offer autofill. On a normal visible field, the value is either the keyword off, the keyword on, or a set of autofill detail tokens: named data types from a fixed list in the specification.

The tokens that matter most on a service site are short:

Field on an inquiry form	Token	What the specification says it means
Full name	name	Full name, free-form text
Email	email	Email address
Phone	tel	Full telephone number, including country code
Company	organization	Company name for the person in the other fields
Job title	organization-title	Job title, e.g. “Deputy Managing Director”
Current website	url	Home page or other web page for the company or person
Postal code (if you ask)	postal-code	Postal code, post code, or ZIP code

Optional prefixes add context without changing the data type. work or mobile in front of tel or email says which contact detail to use, and a section- prefix groups fields that describe the same person when one form collects two sets of details.

The specification also makes a point that bears directly on form design. Authors are “encouraged to use the broader fields rather than the narrower fields,” because split name parts tend to expose Western biases. Many cultures put the family name first, and some people have a single name. One name field is more flexible, and Chrome’s own guidance recommends a single name input for the same reason: it keeps forms simpler and makes autofill simpler.

Think of a printed shipping label next to a handwritten note: both carry an address, but only the label puts each piece where a sorting machine expects it. The comparison has a limit. Browsers don’t reject a form without tokens. They fall back to guessing.

---

How browsers act on the tokens

Once a token is present, the HTML Standard sets some limits on what the browser may do with it. When it fills a field, it must act as if the user had typed the value, and it must only use values the user could have entered. It also must not fill a value that makes the field fail its own constraints, such as a maxlength limit or a pattern. Within one form and one scope, filled fields must describe the same person, so the name, email, and phone it fills belong together.

The specification leaves the final decision with the user. A browser may let the user override the author’s setting, turning a field’s off back to on or switching autofill off completely. So autocomplete="off" is a request, not a lock. The specification describes it for genuinely sensitive values or one-time values, or for a page that provides its own suggestion mechanism. A name field on an inquiry form is none of those.

---

What the evidence shows, and its limits

Chrome’s field data. In December 2024, the Chrome team published an analysis of thousands of address and credit card forms across millions of page loads on the most visited sites in Chrome in the United States. Compared with typing every value by hand, sessions that used autofill had form abandonment about 75% lower and time spent filling the form about 35% lower. “Autofill-assisted” included sessions where only some fields were autofilled, which was the majority. The Chrome team adds its own caveats. The study is correlational, so people who use autofill may already be faster and more comfortable with forms. It covered the United States only, and autofill success rates vary by region. It also measured address and payment forms, not service inquiries.

Independent measurement of what the browser trusts. A preprint posted on SSRN, “Semantic Consistency in Browser Autofill,” looked at Google Chrome’s autofill across 26,663 real-world pages with forms (48,719 deduplicated forms and 159,235 fields). In a human-annotated benchmark of 719 fields, Chrome autofilled 68.15% of them, and 99.18% of those fills matched the field purpose a person would read from the visible page. Most of the misses were fields left empty, not filled wrongly. The researchers then changed the browser-facing signals while keeping the visible field the same:

• Removing a single semantic signal changed autofill behavior in 44.03% of tested cases, and every one of those changes reduced coverage. It never produced a wrong-category fill.
• Adding a conflicting autocomplete value was different. In 196 of 198 cases (98.99%), Chrome followed the conflicting token and filled the wrong kind of data.

This is a preprint, so treat its numbers as early results rather than settled findings. The mechanism it describes still matters for anyone building forms. Missing tokens tend to cost coverage, while wrong tokens cost correctness. The browser treats your autocomplete value as the authoritative answer.

“A missing token makes the browser guess. A wrong token makes it confidently wrong.”
— Windware Studio Practice Note

---

Where accessibility makes it a requirement

WCAG 2.2 Success Criterion 1.3.5, Identify Input Purpose (Level AA), requires that the purpose of each input collecting information about the user can be programmatically determined when it matches one of WCAG’s listed input purposes. Those purposes are taken from the HTML autofill field names. The W3C’s Understanding document is clear about what counts. Whether the browser actually autofills doesn’t matter, and browser heuristics alone don’t meet the criterion. The purpose has to be declared in the markup.

The reasoning goes beyond convenience. W3C notes that people with language, memory, or executive-function disabilities benefit when they don’t have to recall and retype personal details. People with motor impairments benefit from less manual input. Assistive technologies may also show familiar icons next to fields whose purpose is declared. W3C lists F107, incorrect autocomplete attribute values, as a documented failure of the criterion. A wrong token isn’t a partial pass. It fails the same way a missing one does.

The criterion has limits in both directions. It covers information about the user, so a “Project budget” select or a free-text “Tell us about your project” field doesn’t need a token, and inventing one would be the kind of mismatch F107 describes. It also doesn’t stop you from controlling autofill. W3C points out that you can turn off autofill at the form level while still declaring each field’s purpose.

---

A field-by-field method for a service inquiry form

Apply the tokens during development, then check them against what the visible labels say:

• Use one Full name field with autocomplete="name", unless you have a real business need for separate name parts.
• Use type="email" with autocomplete="email", and type="tel" with autocomplete="tel". Add work (e.g. autocomplete="work email") only if the label actually asks for a work address.
• Use autocomplete="organization" for company name and organization-title for role, if you ask for one.
• Use autocomplete="url" only when the label clearly asks for the visitor’s own or their company’s website. Leave it off a field like “Sites you admire.”
• Leave project-specific fields (budget, timeline, message) without a token rather than forcing one that doesn’t fit.
• Keep name and id values stable across deployments, and keep inputs inside a real <form> with a submit button.
• Don’t set autocomplete="off" on personal details for “security” or tidiness. Reserve it for one-time codes or genuinely sensitive values.
• Test with a saved browser profile on desktop and mobile. Every field should be offered the right data, and fields without a token should stay blank.

What goes wrong without this check

• A “Website” field gets the visitor’s email because a reused component carried autocomplete="email".
• A form plugin sets autocomplete="off" on the whole form, and returning visitors retype everything.

---

Practical takeaways for your next website

1. Declare intent, don’t hope for heuristics. Add exact HTML Standard tokens to every field that collects information about the visitor.
2. Accuracy beats coverage. A wrong token causes confident misfills, while a missing one mostly costs convenience. Audit reused components carefully.
3. Prefer one name field. It’s more inclusive across naming conventions and simpler for autofill.
4. Treat off as a narrow exception. Browsers may override it, and personal contact details rarely justify it.
5. Read the evidence with its limits. Chrome’s gains are correlational and come from US address and payment forms. The autofill study is a preprint. Both point the same way, so measure your own form’s completion rate before and after.

---

Ready to Discuss Your Website?

If you are planning a new website, a service redesign, or custom development for your business, we’re here to help you build inquiry forms that browsers and visitors can fill in quickly and correctly.

• Explore Our Services: Web Design · Web Development · Website Redesign
• Start a Conversation: Tell us about your project via our Contact Form or email us directly at [email protected].