Find the actual address task
A mobile customer entering a delivery address may be balancing a phone, a parcel and a small keyboard. Asking for the same name or street twice adds effort and creates chances for disagreement between fields. Start by drawing the full task: contact details, delivery address, any separate billing address, and the final review. Identify which values belong to the customer and which belong to a recipient or business. W3C’s Identify Input Purpose guidance concerns inputs collecting information about the user; it does not mean every arbitrary business field has a standard autofill token. The design decision is which fields have a recognised purpose and how the customer can inspect and correct suggested values.
Observe the field names and sequence on a real narrow screen in both site languages. A Hong Kong address might include building, floor and flat details that do not map neatly to a rigid foreign template. Do not require an irrelevant region or postal code merely because a global checkout template has one. The HTML standard notes that localities order address fields differently and encourages forms to follow local conventions. Decide what information the carrier truly needs, make optional parts optional, and show a short example where the meaning of a field is unclear. The form should still support manual entry when the browser has no saved address.
Match tokens to the meaning of each field
The HTML autocomplete attribute can tell a browser that a field expects a name, street address, address line or telephone number. The HTML standard also permits shipping and billing tokens so the browser can distinguish two address groups. Use a token only when it accurately describes that field. A visible label still matters: a code value does not tell a person whether “Address line 2” means floor, room or building. W3C notes that a browser may autofill based on guesses even without correct metadata, but that guess is not the same as programmatically identifying input purpose under WCAG 1.3.5. Test the actual rendered form, not just the code review.
Avoid giving the same field two conflicting jobs. If a phone number is for the delivery recipient, label it as such; do not automatically present it as the buyer’s personal number. A company contact form may need a different design from a consumer checkout. Where one field can mean either email or username, W3C’s guidance recognises that a single input cannot always be given one perfect purpose value. Record these edge cases and test them with assistive technology rather than forcing a misleading token. When a browser fills a saved value, the site must allow the user to replace it. Autocomplete is an aid to entry, not proof that the address is current or deliverable.
Let customers reuse information deliberately
For a multi-step flow, ask whether the billing address is the same as the delivery address, rather than requiring the customer to type it again. W3C’s Redundant Entry criterion says information previously entered in the same process should be populated or available for selection when requested again, subject to stated exceptions such as when re-entry is essential, needed for security, or the earlier information is no longer valid. A “same as delivery” choice is one example W3C gives. It should show what will be copied and make changing the billing address straightforward. Do not assume that two addresses are equal merely because the user accepted autofill for one.
Keep the customer’s edit in the current step when moving between screens. If a browser suggests an old flat number and the customer corrects it, the later summary should reflect the correction, not restore the saved suggestion. Use clear labels for recipient name and contact details, and show the address as it will be sent to the delivery provider. If the provider needs a particular subdivision, explain it at the point of entry. Do not turn a useful reuse feature into a hidden synchronisation rule that unexpectedly changes a previously edited address. The business should specify whether later edits to delivery details also change billing details, and the interface should make that behaviour understandable.
Test a real mobile journey
Consider a customer ordering a gift for another person. The browser offers the customer’s home address, but the delivery address should be the recipient’s office. The user chooses to type the office details and keeps their own billing address. A sound form does not silently insert the home address into both sections or overwrite the recipient’s edit. On the confirmation step it presents the two addresses distinctly, with a route back to edit either one. This is a worked design scenario, not a report of a customer incident. It tests the exact moment when convenience could cause a costly misdelivery or confusing invoice.
Test at least three states on a narrow screen: no saved profile, one saved address, and two saved addresses with separate shipping and billing details. Use keyboard and screen-reader navigation as well as touch. Verify that visible labels remain available after text is entered, that required and optional fields are clear, and that invalid entries receive an actionable message without erasing earlier work. Try the Traditional Chinese and English versions independently; a translated label can become too vague even when the underlying token stays the same. Record the browser and device used, since autofill suggestions are user-agent behaviour and can differ between environments.
Set a measurable acceptance rule
The acceptance rule should be about customer control, not the number of autocomplete attributes added. Ask whether the browser places values in the intended shipping or billing group, whether a person can tell which address is being used, and whether edits survive until submission. W3C’s criterion is about programmatically identifying the purpose of recognised user inputs, whether or not the browser actually fills them. Therefore a test that merely observes one browser autofilling a field is insufficient. The team should inspect the markup, the visible label and the interaction together. Resolve conflicts between local address conventions and a global checkout template through user testing, not by inventing a token.
Begin with one high-friction form rather than changing every page at once. List each address and contact field, its business purpose, visible label, applicable standard token and whether it can be omitted. Then run the gift-order scenario and a normal self-delivery scenario in both languages. Ask staff to record each wrong suggestion and each edit that fails to persist. Fix the field model before styling the form. Astera can help implement and test the markup and workflow, while the business defines its delivery data requirements. The result should be an address form that saves effort without obscuring what the customer has actually chosen.
Respect shared devices and unexpected data
Autofill values may come from the browser or a profile on a shared family or workplace device. The website should not treat a suggested name or address as verified identity. In a guest flow, let the customer choose another recipient and correct contact details without creating an account. Avoid preselecting a saved address so early that the customer misses it. Show enough of the final destination to support a conscious decision, while avoiding unnecessary exposure of personal details on screens visible to bystanders. These are design precautions, not a claim that a browser will always supply wrong information. They make the form robust when the device owner and the buyer are different people.
Ask test participants to change one address line after autofill, navigate backward, then forward, and submit only after checking the displayed destination. This catches a common implementation failure: a visual field changes while hidden form state still holds the old value. The test should inspect the submitted record in a safe test environment, not merely the last screen. Also check that address suggestions never block a person from typing a location the suggestion service does not recognise. If delivery coverage is restricted, explain the restriction separately and provide an understandable error. A suggestion service can speed input; it must not become an unexplained gatekeeper for valid customer addresses.
Test the address journey
- Match each recognised field to its real purpose and a clear visible label.
- Keep shipping and billing values distinct and editable.
- Test empty, saved and edited states in both site languages.
