Decide whose details the form asks for
A contact form may ask for the sender's name, email and telephone, but it may also ask for a recipient, a colleague or an account to be discussed. Those are different meanings. The W3C's Identify Input Purpose guidance concerns fields collecting information about the user, where a recognised purpose can be identified programmatically. Start by marking on the form design which fields describe the person completing it. Do not attach a personal autofill token to a field for someone else's details merely because both accept an email address. The browser can make a plausible suggestion that is still the wrong person's data, which is a business error rather than a cosmetic inconvenience.
Explain the business consequence of each field before coding it. A reply email determines where staff answer the enquiry; a callback number may be optional if email is sufficient; a contact name may be needed to address the person but should not become a hidden condition for sending. Decide whether the form is for a signed-in account holder or an anonymous visitor. If the account already has contact details, show which value will be used and let the person correct it where the workflow permits. A saved account value and a browser suggestion are different sources. Make their origins clear enough that a customer can catch an outdated or shared-device value before pressing Send.
Match labels, types and tokens
For a simple sender form, a full-name field can use the standard name token, an email field the email token, and a telephone field the tel token. The HTML standard defines these autofill field names; W3C technique H98 asks reviewers to check that a valid autocomplete value matches the field's label. The visible label still matters. A field labelled 'Your email for our reply' is much clearer than an unexplained 'Email', especially when another field asks for a customer's email inside the enquiry. Use a suitable HTML input type as well, but do not confuse type with purpose: type=email describes a format, while autocomplete=email says it is the user's email address.
Do not guess a token from a field's appearance. If the form asks for a company name, check the recognised organization token and decide whether it truly represents the user's organisation. If it asks for an order number, there is no reason to disguise that as a telephone or username. If a single field accepts either an email address or a customer number, it does not have one unambiguous personal purpose; W3C notes that mixed-purpose inputs can be treated differently when the technology cannot express both. Consider splitting the question into two clearly labelled paths if it improves the customer's decision. Keep token choices in a small field inventory so later redesigns do not silently break them.
Keep the same meaning in both languages
The autocomplete token is a fixed technical term; the visible label is written for the reader. An English form may say 'Your name' and a Traditional Chinese form '你的姓名', with the same name token if both collect the same person's full name. Translation cannot quietly turn a sender field into a recipient field. Likewise, do not swap given-name and family-name tokens to match the visual order of a Chinese name; those tokens describe parts of the person's name, not where a box appears on screen. If the business only needs a single full name, one well-labelled name field can avoid forcing visitors into an unsuitable two-part convention.
Write labels that survive the browser's suggestion panel and a narrow phone screen. Put the label outside the field rather than relying on placeholder text that vanishes when a value appears. State whether a phone number is for a callback, delivery or account verification; the same data type can serve different customer decisions. If telephone is optional, say so in both languages and avoid a validation message that later treats it as mandatory. If a customer changes language after filling the form, retain their entered values and keep the semantic purpose of each field stable. Test the switch with an autofilled value, not only with an empty form.
Let the customer review the filled values
Autofill is an offer from a browser, not a guarantee that the contact details are current or that the device belongs to one person. W3C says actual browser autofill is not the test for its input-purpose criterion; the programmatic purpose is. Still, a business should test the real customer journey. After a suggestion is accepted, make the resulting text visible, editable and legible. Do not immediately submit the form or lock the field. The customer should be able to remove a wrong suggestion, type a different address and see the final value before submitting. This matters on shared office computers and when a person enquires on behalf of a business.
Consider a visitor whose browser proposes a personal email while the enquiry concerns a company purchase. The form labelled 'Your reply email' can still use the email token, because the person is entering an address for a reply, but the page should invite a final review of where the answer will go. If the business requires a company address, say that explicitly rather than trusting autofill to infer it. If a signed-in account email is fixed for security reasons, explain that choice and provide the correct account-change route; do not present an editable-looking field that silently discards the customer's changes. The goal is a correct reply destination, not a high autofill acceptance rate.
Validate the submitted details independently
A semantic token helps a browser understand a field, but it does not prove ownership of an email address, deliverability, or that a telephone number reaches the intended person. Validate the necessary format and business constraints when the form is submitted, with a correction path that preserves the customer's other answers. Server-side handling must apply the same essential rules because a client can submit a request without using the page. Treat a malformed value and an unreachable address as different conditions; the first may be caught immediately, while the second may only become apparent after sending. Do not claim that enabling autofill has verified any identity.
Keep data collection proportionate to the enquiry. If the shop can answer by email, avoid requiring a telephone solely because a template includes one. If staff need a callback, explain why and when they will use the number, using a scope the business can actually meet. For an attachment or free-text question, do not invent a personal-data token to make a tool report look complete. W3C's criterion is scoped to known purposes for user information, not every input on a page. A short field inventory should record which fields qualify, which do not, and why. That makes the accessibility review honest and gives future editors a clear basis for changes.
Test semantics and the real journey
Inspect the rendered HTML rather than trusting a design file. For each personal contact field, compare the visible label, its programmatic label, input type and autocomplete token. Confirm the token is valid and describes the same person and same data as the label. Then try common browser and mobile combinations with saved details, no saved details and a deliberately stale detail. Review keyboard access, focus order, suggestion visibility, editing and error recovery. Repeat in English and Traditional Chinese. A browser may choose not to offer autofill in a particular state; that alone does not mean the semantic markup failed, so record the observed state separately from the markup assessment.
A useful release scenario is a shared-device enquiry: the browser suggests the previous user's name and email, the new visitor notices them, replaces both, submits, and receives a confirmation that states the chosen reply address. Another scenario is a signed-in visitor switching languages halfway through. If the form incorrectly sends to the old suggestion, or the language switch remaps a field, fix that flow before release. Keep examples synthetic and do not enter real customer details into test accounts. The final acceptance question is practical: can a customer tell whose details are requested, use or reject a browser suggestion, and know where the reply will arrive?
Before you proceed
- Does each personal field's token match its visible and programmatic label?
- Can a customer reject or edit an autofilled suggestion before submission?
- Do both languages ask for the same person's information?
