Audit mobile form keyboards and autofill
Specify mobile form labels, autocomplete and keyboard hints with country-aware phone handling, then test actual devices instead of assuming a keyboard hint validates data.
What does the field actually represent?
Start with the meaning of the value. An email address, telephone number and order reference are all strings, but they need different entry behavior. A reference containing leading zeros must not be treated as an arithmetic quantity. Choosing a numeric keyboard without checking valid characters can prevent people from entering legitimate values.
WAI recommends associated form labels. MDN describes autocomplete tokens for expected input purpose and explains that inputmode is a keyboard hint rather than a validation rule. These are separate responsibilities: a suitable keyboard does not replace a clear label or server validation. [Labeling controls] [MDN: HTML autocomplete attribute] [MDN: inputmode attribute]
A mobile input specification
| Field | Purpose and attributes | Acceptance check |
|---|---|---|
| Name | Visible Name label; autocomplete name | Spaces, accents and pasted text survive |
| Email input; autocomplete email | At sign and correction are easy; pasted value works | |
| Phone | Telephone input; autocomplete tel | Plus sign, spaces and supported international forms work |
| Postal code | Country-aware text field | Letters and leading zeros are not rejected blindly |
| Order reference | Text value, with a hint only if compatible | Leading zeros and permitted punctuation remain |
| Budget estimate | Explicit currency and numeric rules | Decimal handling and unavailable input are explained |
The matrix is a starting specification, not a claim that all browsers display identical keyboards. Record the browsers and devices you actually test. A desktop emulator can reveal layout problems, but the physical phone’s keyboard, autofill and paste behavior still need observation.
How should international phone numbers be handled?
Do not impose one local visual pattern on every supported country. MDN notes that telephone formats vary and telephone inputs do not automatically validate one universal format. Decide which countries the service actually supports, explain any necessary country selection and preserve a number the user can correct. [MDN: telephone input]
A US/Canada-focused service may still receive international numbers from travelers or distributed teams. Country focus is not proof that every valid caller uses the same entry format. If the backend normalizes numbers, keep the original value where appropriate and test that the displayed normalized value still represents the intended contact.
Test the routes people actually use
- Enter a value with the virtual keyboard and verify required characters are available.
- Paste the same value from a message or address book.
- Use browser autofill and inspect whether labels and values remain legible.
- Trigger validation, correct the field and confirm the previous value is retained.
- Rotate or zoom the device and reach the submit control without losing context.
- Return from another app and verify the form does not unexpectedly reset.
Test synthetic values only. Names with accents, a postal code containing letters, an email with a plus tag and a phone value with a country prefix are useful fixtures. Do not use a real customer’s details in screenshots or analytics debugging. The fixture should challenge the input rules without exposing private information.
What evidence closes the task?
The completed test record names the device, browser, field, entry route, accepted value and observed recovery. A screenshot of the correct keyboard is helpful but insufficient if a later server rule rejects the value. Verify the full entry-to-confirmation path in a safe environment.
I would remove an unnecessary phone requirement before spending time perfecting its keyboard. Every field should support the intended action. When the number is genuinely needed, make its purpose and supported format clear, then verify that the interface and server agree.
Sources
AI-assisted writing and an AI-generated editorial cover. Source links and checked dates are listed below; illustrative examples are labeled in the text.
- Labeling controls — checked 2026-10-18
- MDN: HTML autocomplete attribute — checked 2026-10-18
- MDN: inputmode attribute — checked 2026-10-18
- MDN: telephone input — checked 2026-10-18