Enquiry forms that get finished on a phone

An enquiry form can look fine on a laptop and still lose people on a phone, one fiddly field at a time. Most of the fixes are a few words of copy or a few settings in the form’s code.

Desktop-built forms trip people up on a phone

A form designed on a desktop assumes a mouse and a full keyboard, and a phone has neither. These are the usual snags:

• more fields than you need to reply
• labels inside the box that vanish once typing starts
• the wrong keyboard, such as letters for a phone number
• buttons too small for a thumb
• errors that wipe what was typed

Ask only what you need to reply

To reply, you usually need only the person’s contact details and their message. Save the rest for the conversation that follows.

Google’s web.dev guidance says not to ask for data you don’t need, and favours one name field over separate first and last names. Drop the “confirm your email” box too: its sign-up advice says not to make people type details twice.

Add “(optional)” to the label of any field people can skip, such as “Mobile number (optional)”, as the UK government’s GOV.UK Design System advises.

Asking less also suits Australian privacy law. If Australia’s Privacy Act covers your business, Australian Privacy Principle 3 (APP 3) lets you collect only the personal information that’s reasonably necessary for what your business does. Most businesses with an annual turnover of $3 million or less are exempt.

Health service providers aren’t exempt at any size, so a small clinic’s booking form is covered. Under APP 3, collecting health details such as symptoms generally needs the person’s consent too. This is general information, not legal advice.

Keep a visible label on every field

Put a label above each field, and keep it there while people type. Placeholder text, the grey hint inside an empty box, isn’t a label. The W3C, the web’s standards body, says in its forms tutorial that placeholder text disappears once typing starts. Screen readers, the software that reads a page aloud, don’t treat it as a label either.

Nielsen Norman Group (NN/g) found that placeholder-only labels make answers harder to check, because the question has vanished. A short hint such as a sample phone number is fine under a permanent label, says Baymard Institute.

A linked label also makes a bigger tap area, because tapping it moves the cursor into the field (MDN, Mozilla’s developer reference). The for and id in the code example further down do the linking.

Set the input type so the right keyboard shows

Each field has a type attribute, a setting in its code that tells the phone which keyboard to show (web.dev). For example, type="email" usually brings up a keyboard with an @ key, and type="tel" usually brings up a phone keypad.

Email fields get a basic format check before the form sends (an empty one passes unless it’s marked required). Phone fields get no such check, because formats vary so much. Accept spaces, hyphens, brackets and country codes, as GOV.UK advises.

For postcodes, skip type="number", which MDN says is only for numbers you’d count up or down. A postcode isn’t a count, and Australian postcodes can start with a zero, such as 0800 for Darwin City. Use type="text" with inputmode="numeric", an attribute that asks for the number keypad without checking what’s typed.

Add autocomplete so the phone fills in saved details

The autocomplete attribute tells the browser what each field is for, so it can offer the person’s saved details. The standard values name, email, tel and postal-code cover most enquiry forms (MDN’s full list).

Correct values also meet the Identify Input Purpose rule in WCAG (the W3C’s accessibility guidelines) at Level AA, the middle of its three levels. Made-up values fail it.

Here are the email and mobile fields with all of the above:

<label for="email">Email</label>
<input id="email" name="email" type="email" autocomplete="email" spellcheck="false" required>

<label for="phone">Mobile number (optional)</label>
<input id="phone" name="phone" type="tel" autocomplete="tel">

Setting spellcheck="false" stops addresses being flagged as typos (GOV.UK recommends it).

Make tap targets big enough for a thumb

Make anything people tap about 48 by 48 pixels, with about 8 pixels between targets, as Google’s web.dev suggests. That’s double the WCAG 2.2 minimum of 24 by 24 CSS pixels (the unit web pages are sized in) at Level AA.

That minimum has a few exceptions, such as a link inside a sentence. The 44 by 44 figure you’ll often see is Target Size (Enhanced), at the stricter, optional Level AAA.

Show errors beside the field and keep what was typed

When an answer is wrong, say so beside that field and explain how to fix it. For example, “Enter an email address like name@example.com” explains the fix, and “Invalid input” doesn’t. When a form detects an error automatically, WCAG requires the field to be identified and the error described in text, with a suggested fix where one is known.

NN/g’s error guidelines add two details: use an icon as well as colour, and wait until the person has finished the field before showing the message.

Never clear the form on an error. NN/g and GOV.UK both say to keep what was typed, right or wrong.

If someone else builds your form, ask them whether it sets two attributes. Once the form has checked the answers, each wrong field should get aria-invalid="true", and its aria-describedby should point at the error text. These ARIA attributes are notes in the code for screen readers, so someone using one hears which field is wrong and what the error says (W3C technique ARIA21).

Say what happens next, on the button and after it

Label the button with what it does, in sentence case (capitals only where a sentence would have them), following GOV.UK’s button guidance. “Request booking” fits if you confirm the time later. Use “Book now” only if the booking is made there and then.

Say on the confirmation screen when they’ll hear back. GOV.UK’s confirmation page pattern says the page should tell people what happens next and when, and give contact details. Pick a reply time you can keep.

With those changes, the form is shorter and the phone fills in most of it. If someone makes a mistake, they don’t have to start again.

Last checked 10 October 2026 against every page linked above.