Why do browsers always fill in the wrong forms? Autocomplete is not "the browser thinking it's smart", but rather an input semantics that design and development should jointly define

Users have already saved their names, email addresses and addresses in the browser, but every time they re-enter them on the corporate website, it is often not because the browser's capabilities are insufficient, but because the fields do not provide an input purpose that the machine can understand. Autocomplete can simultaneously enhance efficiency, reduce input errors, and assist some users with cognitive impairments.

01 The focus of WCAG 1.3.5 is to make common personal information input purposes programmatically identifiable

The current Identify Input Purpose document of W3C requires that when the fields for collecting user information conform to the defined scenarios, the input purpose should be determined by the program. HTML autocomplete token is a common implementation method.

This not only serves the browser Autofill, but also enables assistive tools to provide ICONS, languages or input assistance that is more suitable for users.

02 Designers need to stabilize the semantics of fields so that developers can mark them correctly

Is "contact information" a work email or any email address? Is the "name" a complete name or a separate surname and given name? If the product definition is ambiguous, autocomplete will not be correct either.

The semantics of the field should be clearly stated in the design requirements instead of guessing the token by oneself before the development and launch.

03 Common fields should use standard tokens instead of custom attributes

Standardized values are already available for names such as name, Give-name, family-name, email, tel, street-address, postal-code, etc.

Correct usage enables the browser to understand the relationship between different fields, especially long addresses and checkout forms.

04 "autocomplete=off" is not a universal solution for all incorrect padding

Some teams shut down the entire site just because the Autofill style looks bad once, leaving users to repeatedly type by hand. Browsers may also adopt their own strategies based on security and user preferences in scenarios such as login.

The field semantics, name and form structure should be revised first. Only special inputs that truly should not be saved should be handled with caution.

05 One-time verification codes can also reduce copy operations by leveraging input semantics

When the mobile receives the SMS OTP, correctly marking the one-time-code can enable the system to provide verification code suggestions and reduce the back-and-forth switching.

At the same time, paste and password managers should still be allowed. Do not create obstacles by splitting the interaction into six separate boxes and prohibiting paste.

06 The visual state after auto-filling must be readable

Browser Autofill may change the background color, and dark themes are particularly prone to text contrast issues.

Design acceptance should actually test the auto-fill status of Chrome, Safari, etc., rather than just looking at the empty form design draft.

07 Sensitive fields need to take into account security and user expectations

Whether data such as bank cards, security codes, and ID cards can be saved needs to be combined with the browser security model and business regulations.

Just because Autocomplete can improve efficiency does not mean that all sensitive information should be memorized for a long time by default.

08 A good form allows users to input as little as possible instead of showing more controls

Auto-filling, reasonable default values, address association and scanning all fall under the category of reducing input costs.

When the system already knows the user's account information, it should avoid asking repeatedly. Autocomplete is the most fundamental and cost-effective layer among them.

09 The fields Label and autocomplete address different issues

It can be seen that Label helps users understand "what to fill in here", while autocomplete provides machine-readable input purposes for browsers and assistive technologies. Just writing a placeholder cannot replace either of them.

For example, the "work email" still needs to have a clear Label; If the field meets the standard purpose and the appropriate autocomplete token is configured, the browser will be more likely to provide correct suggestions.

10 The state after auto-filling also needs to test the visual and verification logic

The browser may fill in the name, address and phone number all at once. If the form only triggers verification when the user inputs word by word and the button remains Disabled after automatic filling, a hidden Bug will be formed.

At the same time, check whether the auto-fill background color of the browser makes the text or borders unclear, especially for dark themes and brand-custom input boxes.

Frequently Asked Questions

Are Autocomplete and Placeholder the same thing?

No. Placeholder is a visual prompt, and autocomplete is machine-readable semantics that tells the browser the purpose of field input.

Do all fields need to be autocomplete?

Standard personal information and common inputs are particularly valuable, while custom business fields do not necessarily have corresponding tokens.

Can the entire site be autocomplete=off?

It is not recommended as the default strategy, as it may result in reduced filling efficiency and accessibility.

Can the verification code be filled in automatically?

Support the use of semantics such as one-time-code on the platform, and at the same time, normal pasting and auxiliary input should be allowed.

Do designers need to care about HTML attributes?

It is necessary to understand its impact on the experience and define the field semantics in the delivery. The specific code is implemented by the development team.