Website fixes: enquiries

Making it easy to get in touch.

These entries are about the step that matters most to a business: someone who likes what they see getting in touch. Most are small fixes, and they count most on phones, where people want to tap once rather than copy, switch apps and type.

Check your site freeAll website fixes

No direct way to get in touch on this page

What it means. The check couldn't find a way to contact you on this page: no tap-to-call link, email link, WhatsApp or Messenger link, form, or link to a contact or help page.

Why it matters. Someone ready to ask for a quote has to go looking. Some will try the menu or footer; others will go back to their search results and try the next business. People land on all sorts of pages from Google, not only the home page, so every page is a place an enquiry can start.

How to fix it. Make getting in touch possible from every page.

  • Put at least one direct way in the header or footer: your number as a tap-to-call link, your email address as a link, or a button to a short enquiry form.
  • Add a clear "Contact" item to the menu.
  • If your contact options come from a script, such as a chat widget or another service's form, check on a phone that they show and work. The check can't see them.

How the check spots it: This is a potential issue, a guess from the page's HTML as delivered, before any scripts run. It looks for tel: and mailto: links (including Cloudflare's protected email links), WhatsApp and Messenger links, any form that isn't a search box, and links to a contact or support page: an address whose path has contact, contactus, support, enquiry, enquiries, enquire or help as a part of its own, or get-in-touch (/contact-us/, /contactus, /contact.html and /get-in-touch all count). It goes by where links point, not what they say, and only by the path, so a link to support.example.com doesn't count. A number or email address in plain text doesn't count; see tap-to-call and email links. If only a contact page link is found, the report shows getting in touch takes another tap instead.

Getting in touch takes another tap

What it means. This page links to a contact, support, enquiry or help page, but offers no direct way to get in touch itself: no tap-to-call link, email link, chat link or form.

Why it matters. That isn't wrong, and plenty of sites work this way. But every extra page is another wait and another decision, and on a phone that's often when people drift off. If enquiries are the site's main job, a direct option on the page shortens the path.

How to fix it. Add one direct option where people will see it: your number as a tap-to-call link, your email address as a link, or a prominent "Get a quote" button that leads straight to a short form. If you'd rather keep enquiries on one contact page, to cut spam or ask the right questions, make the link to it a button that stands out rather than a quiet menu item.

How the check spots it: This is a potential issue, a guess from the page's HTML before any scripts run. It found a link to a contact or support page (such as /contact-us/, /contactus or /get-in-touch), but no tel: or mailto: link, no WhatsApp or Messenger link and no form other than a search box. Contact options a script adds, such as chat widgets, aren't seen. With no contact link either, the report shows no direct way to get in touch instead.

The form doesn't let phones fill in contact details

What it means. Phones and browsers can fill in a name, email address and phone number with one tap, from details saved on the device. They do it reliably when each field says what it's for with the autocomplete attribute. Some of your form's name, email or phone fields don't, or have autocomplete="off".

Why it matters. Typing a full name, email address and mobile number on a small keyboard is slow, and an enquiry with a typo in the email address can't be answered. Autofill takes a second and gets it right. It also helps people with motor or memory difficulties, which is why WCAG 1.3.5 Identify Input Purpose (level AA) asks that fields for a person's own details say what they are this way.

How to fix it. Add the matching value to each field, and remove autocomplete="off". MDN's autocomplete reference lists every value.

  • Name: autocomplete="name", or given-name and family-name for separate first and last name fields.
  • Email: autocomplete="email". Phone: autocomplete="tel".
  • Form plugins and builders often have an autocomplete setting for each field, and some add it when you use their Name, Email and Phone fields rather than plain text fields.

How the check spots it: It looks at text, email and phone fields outside search forms, and works out which ask for a name, email or phone number from the field's type, name, id and placeholder (type="email", a name like first_name or phone, a placeholder like "Your name"). Any of those with no autocomplete, or just "on" or "off", which don't say what the field is, is flagged. Fields it can't recognise aren't judged.

Contact fields bring up the wrong keyboard on phones

What it means. A field's type tells phones which keyboard to show: type="email" puts the @ sign close at hand, and type="tel" brings up a number pad. These email or phone fields are plain text fields, so people get the ordinary keyboard.

Why it matters. Hunting for the @ sign or switching to numbers is fiddly on a small screen, and it's where typos creep in. An email field also has the browser check that the address is well formed before the form sends, which catches some mistakes. Fewer typos means fewer enquiries you can't reply to.

How to fix it. Change each field's type to type="email" or type="tel". In form plugins and builders, that usually means using the Email or Phone field instead of a single-line text field.

  • Don't use type="number" for phone numbers. It's meant for quantities, doesn't handle the spaces and + sign people type, and can show up and down arrows.
  • A phone field doesn't check the number's format, because formats vary so much. That's normal.
  • Add autofill to the same fields while you're there; see letting phones fill in contact details.

How the check spots it: It flags <input> fields with no type or type="text" whose name, id or placeholder mentions email, e-mail, phone, mobile or telephone, or whose autocomplete is "email" or "tel". The report suggests the right type for each one.

The main action isn't obvious

What it means. Apart from a link to a help or support page, the check couldn't see the usual next step on this page: a link to ask for a quote, book, sign up, register, contact you, or go to a cart or checkout.

Why it matters. Most business pages exist to lead to one action. When it isn't obvious, interested people have to work out what to do next, and some won't bother. A button with unusual wording may still be perfectly clear to the people who see it.

How to fix it. Decide what you most want visitors to do from this page, such as call, ask for a quote or book, and give it one clear button near the top in words that say what happens: "Get a quote", "Book a time", "Call now". On a phone, check it shows on the first screen without scrolling.

How the check spots it: This is a potential issue, a guess from the page's HTML. It looks at where links point, not what they say: an address with quote, book, booking, cart, checkout, sign, signup, register, contact, contactus, enquiry, enquiries or enquire as a part of its own, or get-in-touch. It only raises this when the page's sole route to you is a support or help link, with no phone, email or chat link and no form, so it usually appears alongside getting in touch takes another tap. Buttons that work through a script, with no link address, aren't seen.

Keep exploring