The contact form works, you've tested it, and messages come through. Yet the number of inquiries is lower than what site traffic would suggest. A similar issue can happen in an online store: users add products to the cart, but some never finish the checkout.
The cause isn't always the visual design of the form. Sometimes a wrong input type, missing autofill, or validation triggering at the wrong moment is all it takes to make a simple form noticeably harder to complete on a mobile device.
Start with the number of fields
A form should collect data that is genuinely needed at that specific stage of the process.
In a contact form, the details needed to start a conversation are usually enough. Additional questions can always be asked later, once contact with the customer has already been made.
The same principle applies to checkout. The data should simply be sufficient to correctly accept the order, deliver the parcel, process payment, and issue the required documents.
Baymard research shows that for checkout usability, the number of fields a user has to handle matters more than the number of checkout steps. According to their analysis, most checkouts can be cut down to around 8 fields, whereas the average benchmarked was 11.3 fields.
That is why before redesigning a form, it's worth reviewing every single field to check whether the information gathered is actually used.
Not every sequence of digits is a number
One of the most common technical mistakes is using type="number" everywhere a user needs to enter digits.
This input type is meant for actual numerical values, such as product quantities, age, or a specific value that can be increased or decreased.
A phone number, postal code, tax ID (NIP), PIN, or order number might consist primarily of digits, but they are not numbers in that sense.
The HTML specification explicitly states that type="number" should not be used for values that merely happen to consist of digits. It cites credit card numbers and postal codes as prime examples.
A good rule of thumb is to ask whether stepper buttons that increase or decrease the value by one would make sense for that field. For product quantity: yes. For a postal code or phone number: no.
type="number" can also alter the field value
The problem goes beyond how the input looks.
HTML defines type="number" as a control intended for values that are valid floating-point numbers. The browser should not treat an arbitrary string of characters as a valid value for such a field.
That is why a postal code formatted as 80-180 doesn't fit type="number". Neither does a phone number with a +, spaces, or other formatting characters.
Depending on the implementation, this can block form submission altogether or cause the application not to receive the value in the format the developer expects.
A safer solution for values that serve as identifiers or digit strings is typically a text input paired with the appropriate inputmode.
Switching a field to text doesn't mean a mobile user has to see a standard alphabetical keyboard.
The inputmode attribute allows you to hint to the browser which on-screen keyboard best matches the expected data, without changing how the value itself is handled.
| Setting |
Use case |
inputmode="numeric" |
digit strings, e.g. certain codes, PINs, or other numerical identifiers |
inputmode="decimal" |
decimal values, e.g. weight or dimensions |
type="tel" |
phone number |
type="email" |
email address |
With type="tel" and type="email", browsers can automatically provide the right keyboard layout. inputmode is particularly useful when the field needs to stay a text input, but you want a specific input method on mobile.
Autofill shouldn't rely on the browser's best guess
Another frequently overlooked aspect of forms is autocomplete.
This isn't just about setting autocomplete="on" on the whole form. HTML defines specific tokens that describe the semantic meaning of individual fields.
For example, you can use:
name for a full name,given-name for a first name,family-name for a last name,email for an email address,tel for a phone number,organization for an organization name,postal-code for a postal code,address-line1 for the first line of an address.
It pays to use the exact values specified in the standard. An invented token like postalcode instead of postal-code fails to give the browser accurate information about the purpose of the field.
Shipping and billing addresses need to be distinguished
Autofill becomes especially critical in checkouts where identical data fields appear multiple times.
A store often has separate shipping and billing addresses. Simply marking both fields with postal-code does not provide full context.
HTML addresses this using tokens like shipping and billing, as well as named section tokens.
<input
name="shipping_postcode"
autocomplete="section-dostawa shipping postal-code"
>
<input
name="billing_postcode"
autocomplete="section-faktura billing postal-code"
>
This allows the browser to accurately identify which details to suggest in a specific part of the form.
In WooCommerce, inspect custom fields and plugin additions
Default WooCommerce fields come with pre-configured autocomplete values for standard address details.
Closer attention should be paid to fields added later via custom code or third-party plugins.
These might include a tax ID (NIP), an alternate phone number, custom company details, or data needed for a specific integration.
Simply injecting a field into the checkout doesn't mean it automatically inherits proper semantics and autofill configuration. After any major form modification, it is always worth going through the checkout on a real mobile device using address data saved in the browser.
autocomplete is vital for accessibility as well
Accurately identifying the purpose of fields isn't just about user convenience.
WCAG 2.2 Criterion 1.3.5 Identify Input Purpose at Level AA requires that the purpose of specific fields collecting personal user information can be programmatically determined where supported by technology.
In HTML, correct autocomplete values are one of the primary ways to meet this requirement.
Fixing your form can therefore improve autofill while eliminating issues flagged during an Accessibility audit.
Don't show errors before the user finishes typing
Another major source of unnecessary friction is validation that triggers at the wrong moment.
When someone starts typing an email address, an invalid format warning shouldn't appear after the first few characters. The address is incomplete simply because the user hasn't finished typing yet.
Baymard's form validation research shows that error messages should never appear prematurely. At the same time, users should be informed of an issue before they attempt to submit the entire form.
In most scenarios, the ideal trigger for initial validation is when the field loses focus (blur). If the user subsequently returns to correct the value, the message should react dynamically rather than staying stuck until the next submit attempt.
Exceptions can be made for fields where real-time feedback on complex requirements is helpful, such as password creation with strict character criteria.
Error messages should explain what needs fixing
Highlighting a field in red is never enough.
The error message must sit next to the relevant field and clearly communicate what the form expects.
A vague note like "Invalid value" forces the user to guess. Clear instructions are far more useful, for example: "Enter a phone number in the format 123 456 789 or +48 123 456 789".
Error status should never be communicated through color alone. The form must make the message accessible to assistive technologies as well.
A placeholder is not a label
A common shortcut when trying to simplify form UI is removing visible labels and relying on the placeholder.
The problem arises the second the user starts typing: the placeholder vanishes, leaving them without context on what the field was for.
A visible label is essential for longer forms, autofill, and correcting mistakes after a failed submit.
Placeholders can serve as optional hints or format examples, but they should never be the sole identifier for an input.
You don't need to rebuild everything from scratch. Start by auditing your current form against a few specific checkpoints:
- Review all fields using
type="number". If they hold an ID, code, phone number, or any value not meant to be incremented or decremented mathematically, change the input type.
- Test the form on mobile. Ensure each field opens a convenient, appropriate on-screen keyboard.
- Enable browser autofill. Go through the form on a device where your name, address, phone number, and email are saved, and check which fields get skipped.
- Check your
autocomplete tokens. Verify them against standard HTML specifications instead of relying on custom naming.
- Test invalid entries. See when error messages trigger and verify that they disappear or update once corrected without needing another submit click.
- Check your labels. Every key field should feature a persistent, readable label even after the user starts typing.
- Remove unnecessary fields. If a piece of information isn't strictly necessary to handle initial contact or fulfill an order, consider removing it from this step.
- Submit the form and inspect the full pipeline. Don't just check the success message—verify database storage, email notifications, and where the inquiry actually lands.
Submitting sample data and seeing a success message only confirms the bare minimum. It doesn't show how the form behaves across mobile devices, whether it supports browser autofill, or how intuitively it guides users through invalid input.
At DOCK, when developing Websites and Online shops, we evaluate forms as an integral part of the user journey. In a checkout, that means auditing the entire flow from cart to order confirmation; for a corporate website, from form view to delivery in your inbox.
If your form or checkout works technically but conversion rates suggest users are dropping off, get in touch with us. We can audit your implementation, mobile behavior, autofill support, validation logic, and full post-submit processing.
