Match input types to the data
email, tel, url, number and date types influence mobile keyboards, validation and assistive technology. Telephone numbers are rarely numbers in the mathematical sense because leading zeroes, plus signs and spaces matter.
Use inputmode and autocomplete as additional hints, while keeping server-side validation authoritative. A keyboard layout must never be the only input restriction.
Make sure the keyboard does not hide the task
Focus the fields near the bottom of the page in iOS Safari and Android Chrome. The current field, its error and the next action should remain visible. Sticky calls to action, consent banners and chat controls commonly collide with the open keyboard.
- Test the first and final fields
- Test portrait and landscape
- Test browser zoom and enlarged text
- Check Next, Done and Back keyboard actions
Use realistic autofill data
Autofill can update several fields without keyboard events and expose validation code that listens only for typing. Use test names, addresses, phone numbers and a password manager; verify labels remain readable and country-dependent fields update correctly.
For sign-in and payment, test password managers, one-time codes and paste. Blocking paste usually harms completion and discourages strong generated passwords.
Make errors visible, specific and recoverable
After a failed submission, move focus to an error summary or the first invalid field and explain how to fix it nearby. A red outline alone is not sufficient for colour-blind users or screen readers.
Preserve correct data and provide clear states for server errors, timeouts and duplicate submissions.
Complete the slowest realistic success path
Submit once using a slower connection, long names, an international phone number, a complex address and an attachment where relevant. Record viewport, keyboard state, expected result and actual result at every step.