Autofill depends on field semantics; missing or wrong annotation fills the wrong content

What it is

Browsers and password managers decide what to put in which box from semantic annotation: name, email, phone, address line, card number each have tokens. When annotation is missing, the engine guesses from name or placeholder text; when it is wrong, a phone lands in email, or an old address lands in “company.” Autofill is not “dump the user profile into the form.” It is slot matching under annotation constraints. A wrong match plants bad data even if the field remains editable afterward.

Why it happens

HTML autocomplete tokens, name, visible labels, and even neighboring text feed heuristics. Password managers add their own field classifiers. Only a box marked email should receive the email string; two boxes both called name may get the same string twice or swap given and family names. Single-page apps that use unsemantic custom widgets hide standard inputs, so the engine gives up or mistakes the control for search. A placeholder that says “enter mobile” while autocomplete is set to something other than a telephone token makes heuristics fight the explicit mark. Users see “the browser filled nonsense”; the root is misaligned slots.

Studying it

Build forms with controlled annotation: correct, missing, swapped, fake widgets. Fill them from the same browser profile and score slot accuracy. Compare heuristics-from-visible-label only with explicit tokens. Test password managers separately from native browser fill. Dynamically inserted fields (an extra address line) must retrigger fill after insertion. Do not use only the developer's already-trained profile.

Where it stops holding

People who fill by hand with autofill off are unaffected by annotation. One-time codes should not enter the profile; marking one-time-code is for SMS fill, not a profile slot. Native contacts APIs and Web fill are different stacks and may mix on mobile. Accessible names are sometimes weighted above visible labels, so a hidden label can detach visible copy from fill.

Applying it

• Give every fillable field an explicit autocomplete token; split names into given-name / family-name rather than calling both name.
• Custom input widgets must expose a real input or the platform's equivalent semantic API.
• Keep placeholder and label consistent with the token so a field does not look like a phone while marked as email.
• Verify with a clean browser profile that stores a standard personal record, trigger fill on the target form, and check cell by cell. Fix annotation before blaming the engine for swaps or empty slots.

Related

• Same group: C6.28.2 Autofilled content must stay editable before submit, not locked · C6.28.3 Autofill may insert mismatched history across origins, with privacy and error risk · C6.28.4 Autofill and validation timing must be coordinated so fill does not trip instant errors
• Adjacent: C6.07 Keyboard types and task fit · C6.10 Autocomplete
• Search: autocomplete attribute · autofill heuristics · field semantics