How to Cut Form Friction Without Losing the Fields You Need

Four corrections to the advice you have probably already read:

• Field count is a weak predictor of abandonment. Retrieval cost is a strong one. A nine-field form your visitor can autofill and answer from memory beats a four-field form containing one question that sends them to another tab.
• Removing a field does not delete the work. Somebody still needs that answer. You have moved it into a follow-up email, an enrichment tool, a sales call, or a guess. All four have a price, and only one of them is free.
• Form conversion rate is the wrong scoreboard for a field change. Judge it on qualified outcomes per 1,000 organic landing sessions, the one number that catches the case where submissions went up and revenue did not.
• The accessibility work and the mobile conversion work are frequently the same attribute. Marking up a field so a screen reader announces its purpose is the same markup that makes autofill fire on a phone. You do it once and bill it to whichever budget will pay.

Every field asks the visitor to do one of five things, and the five are nothing like equal in cost. Sort your form by this table before you sort it by length.

Two consequences fall straight out of this.

First, order the form by cost, ascending. Automatic and recall fields at the top build a small sunk cost before the expensive question lands. A visitor who has already typed their name and email is harder to lose than one who meets "annual revenue" as question one.

Second, one lookup field can outweigh five recall fields, in the wrong direction. Ask for a policy number and a meaningful share of visitors will open a second tab, search their email, and never come back. Deleting three optional fields will not touch that loss. Making the policy number optional here, or accepting a name and date of birth instead, will.

Run four questions against every field on the form. Write the answers down, because "we've always collected it" survives conversation and does not survive a written audit.

1. What decision changes if we don't know this? Name the decision. Routing to a specialist, a price band, a legal requirement, a shipping calculation. If nobody can name one, the field is habit.
2. Who reads it, and when? Name the person and the moment. A surprising number of fields turn out to be read by nobody, ever, because the rep asks the same question again on the call.
3. Can the visitor answer it here, without leaving or guessing? If not, it is a lookup or judgment field and it needs a different home.
4. Can we get it another way? Campaign parameters, the landing page itself, the query class that produced the click, the CRM record you already hold, or the first two minutes of a call.

Optional fields are not free either. Each one still costs reading time, a scroll, and a decision about whether skipping it hurts their chances. If a field is optional and nobody reads it, it is not optional. It is decoration.

Two different things get called the same thing, so define them before choosing.

Progressive disclosure shows a field only when an earlier answer makes it relevant. Someone who picks "existing customer" gets the account question, everybody else never sees it. The field count for any individual visitor drops, and nobody is asked something that does not apply.

Multi-step splits the same set of fields across screens, with the real submit at the end. Nothing is removed. The commitment is reshaped into several small ones, and you get partial data from people who quit at step two.

Rules that hold up in practice:

• Never split a form of four fields or fewer. You have added navigation cost and removed nothing.
• Split by topic, not by count. "About you" then "About your project" reads as a sequence. "Fields 1 to 4" then "Fields 5 to 8" reads as a stalling tactic.
• Instrument the steps before you build them. If you cannot see per-step drop-off, a multi-step form is a single-step form with the diagnosis removed.
• Show honest progress. "Step 2 of 3" is fine. A progress bar stuck at 80 percent with three screens to go destroys the trust you just bought.
• Preserve entered values on back navigation, and never ask twice. WCAG 2.2 Success Criterion 3.3.7 Redundant Entry is a Level A requirement that information already entered in the same process is auto-populated or available to select, unless re-entry is essential. It reads like a conformance line. It describes the moment a visitor closes the tab.
• Announce fields that appear. A conditional field rendered below the fold with no announcement is invisible to a screen reader user and to anyone who has already scrolled past. Move focus to it, or put it directly under the control that revealed it.

A visible on every input, every time. Placeholder text is not a label, and Nielsen Norman Group has been saying so since 2014 in Placeholders in Form Fields Are Harmful. The failure modes are all conversion failures: the hint vanishes the moment someone types, default placeholder contrast is usually too low to read comfortably, and anyone reviewing a completed form before submitting cannot check what each box asked for.

Format hints belong in persistent helper text under the label, connected with aria-describedby, not in the placeholder. WCAG's 3.3.2 Labels or Instructions is Level A and says the same thing in standards language.

On required markers, mark the minority: if most fields are required, mark the optional ones, and the other way round. An asterisk on every field tells the reader nothing except that the form is long.

Error text is where forms lose people who were willing to convert. Three rules: say which field, say what is wrong, say what a correct answer looks like.

WCAG covers this in two criteria worth quoting in a design review: 3.3.1 Error Identification requires the item in error to be identified in text, and 3.3.3 Error Suggestion requires a suggested correction where one is known and offering it does not compromise security.

Mechanically an error needs three attachments to work for everyone: the text associated to the input with aria-describedby, the input carrying aria-invalid="true", and focus moving to an announced error summary on submit failure. A container with role="alert" that already exists in the DOM and receives injected content is announced reliably. One created and inserted at the same moment often is not.

This is the cheapest friction reduction on the list and the one most often left undone. The right attributes turn a four-minute typing exercise on a phone into three taps.

Four notes that matter more than the table itself:

1. Use the token names exactly. The autocomplete values are defined in the HTML standard's form control infrastructure section. An invented token such as autocomplete="company" does nothing, and it looks perfectly reasonable in code review, which is why it survives for years.
2. autocomplete="off" on contact and address fields is self-inflicted friction. It usually arrives by copy and paste from an internal tool where stale suggestions were annoying. Remove it everywhere you cannot name a reason for it.
3. Do not use type="number" for things that are not quantities. Phone numbers, card numbers, postal codes and reference numbers are strings that happen to contain digits. The GOV.UK Design System text input guidance documents using inputmode="numeric" with pattern="[0-9]*" instead, because the number input adds spinner controls and can have its value changed by an accidental scroll.
4. Never suppress zoom, and keep input font size at 16px or larger. Mobile Safari zooms the viewport when a focused input has a font size below 16px, shoving your layout sideways at the exact moment the visitor starts typing. Patching that with user-scalable=no trades one problem for a worse one.

Now the crossover. WCAG 2.1 added 1.3.5 Identify Input Purpose at Level AA, requiring that the purpose of inputs collecting information about the user is programmatically determinable. In HTML you satisfy it with the autocomplete token list above. One attribute, two budgets. When accessibility work is hard to fund, this is the argument that funds it.

While you are in there, check tap targets. WCAG 2.2 added 2.5.8 Target Size (Minimum) at Level AA with a 24 by 24 CSS pixel floor. The control most likely to fail it is the consent checkbox, and a consent checkbox nobody can hit is a form nobody can submit.

Validation that fires too early is experienced as being told off for typing. The pattern that fixes it has a name, "reward early, punish late", set out in Smashing Magazine's A Complete Guide To Live Validation UX from September 2022. The shape of it:

Three specifics behind that table:

• Server-side checks are the expensive ones. "This email is already registered", "that promo code has expired", "we don't deliver to that postal code". Every one is discovered at submit, the worst possible moment. Where the check can run asynchronously on blur, run it there.
• Never block paste, and never silently rewrite input. Blocking paste in a card or code field forces manual transcription and creates the errors you were trying to prevent. Stripping the spaces out of a card number and then rejecting it is worse: the visitor is staring at input that looks correct.
• Write your own error text into the DOM. The browser's built-in constraint validation bubbles differ across browsers, disappear on their own, and are not reliably announced by assistive technology. Put novalidate on the form, keep the constraint attributes for semantics, and render your own messages.

An accessibility audit hands you a list sorted by success criterion and severity. A form needs the same list sorted by "does the visitor get to press submit". Our post on accessibility as a search experience problem makes the general argument. Here is the form-specific version.

Every failure in the right-hand column arrives in your analytics as "the form doesn't convert", and none of them arrives labeled as an accessibility problem, because you have no dashboard for that. The W3C's forms tutorial is the practical reference for building it right the first time.

One honest caveat, since it comes up in every meeting: no search engine publishes form accessibility as a ranking factor, and there is no accessibility report in Search Console. The case for this work is that it converts traffic you already earned. It is not a position argument.

Before touching a field, find out whether the form is even the problem. Plenty of "form friction" turns out to be a page that promised something the form does not deliver.

Step 1. Get organic clicks by landing page. In Google Search Console open Performance, then Search results. Set the date range to Last 3 months, which is steadier at page level than 28 days. Turn on all four metric toggles, open the Pages tab, and export to CSV. Our guide to measuring organic CTR in Search Console covers the export mechanics in more detail.

Step 2. Keep only the pages that end in a form. Quote pages, contact pages, demo pages, pricing pages with a gated element, checkout entry points.

Step 3. Pull organic sessions for those pages in GA4. Build a free-form exploration with Landing page plus query string as the dimension, Sessions as the metric, and a filter where Session default channel group exactly matches Organic Search. Match the Search Console window.

Step 4. Confirm the form events exist. GA4 enhanced measurement fires form_start on the first interaction with a form in a session, and form_submit on submission. Check Admin, then Data streams, then your web stream, then Enhanced measurement, then Form interactions. The catch worth knowing: these events fire for real elements on your page. A third-party widget rendered inside an iframe fires nothing, and you will read that as zero engagement rather than as missing instrumentation.

Step 5. Compute three rates per page. This is where the diagnosis happens.

• Start rate equals form_start divided by organic landing sessions. A low start rate means the problem sits above the form, not inside it.
• Completion rate equals form_submit divided by form_start. A low completion rate means the problem is inside the form.
• Qualified rate equals qualified downstream outcomes divided by form_submit. This is the number you must not lose while improving the other two.

Illustrative figures for the method, not SparkCliks data.

Notice what the third row means. A 19 percent start rate with an 83 percent completion rate is not a form problem at all. That page needs a clearer reason to fill anything in, or it needs to stop promising what the form does not deliver, which is a message match problem between the title tag and the headline. If the start rate collapsed recently, check what fires before the form: our post on popups and interstitials after a search click covers the usual suspects.

Step 6. Go field-level on the worst page. GA4 does not do this natively, so fire one event the first time each field is touched in a session:

// One event per field, the first time it is focused in a session.
const touched = new Set();
document
  .querySelectorAll('#quote-form input, #quote-form select, #quote-form textarea')
  .forEach((el) => {
    el.addEventListener('focus', () => {
      if (touched.has(el.name)) return;
      touched.add(el.name);
      gtag('event', 'form_field_focus', {
        form_id: 'quote',
        field_name: el.name,
      });
    });
  });

Read the result in DOM order. The last field with a healthy focus count, followed by the first with a collapsed one, is where people stop. Two caveats: this only sees visitors who started, and it tells you where they stopped, not why. The why comes from the retrieval class of that field.

The whole risk in this work is shipping a change that raises submissions and lowers revenue, then never finding out. The design below is what stops that.

Pick the metric first: qualified outcomes per 1,000 organic landing sessions. Not form conversion rate. Define "qualified" in one written sentence, at a stage that already exists in your CRM, before you change anything. Define it afterwards and you will define it to match the result you got.

Set the windows honestly. A baseline of 28 days untouched, then a change window of at least 28 days. If your qualifying stage takes three weeks to reach, a 28-day window measures submission count and almost nothing about quality. Extend it, or agree a leading proxy in advance and write down that it is a proxy.

Keep a control set. Comparable form pages you deliberately do not touch. Without one, a seasonal shift or a ranking movement reads as a result.

Check the guardrail before reading the result. Pull average position and impressions for the changed pages from Search Console across both windows. If position moved, the mix of queries reaching the page changed, and your comparison is measuring a different audience rather than a different form.

Change one thing. Removing two fields and rewriting the error messages in the same release gives you a number and no explanation.

Then read the outcome against this table:

Say the sample size problem out loud. If a page produces twelve qualified outcomes a month, no 28-day test separates an eight percent improvement from ordinary variance, and no amount of dashboard styling changes that. Run the test on your highest-volume form, or accept that you are making a reasoned judgment rather than a measurement. Both are legitimate. Presenting the second as the first is not.

One trap specific to bought traffic. If you run SERP Clicks, real human clickers search your keyword, click your listing, spend time on the page and optionally visit a second page. They do not fill in your forms, and they should not: a submission with no intent behind it is worse than no submission. Those sessions land in the denominator of every rate above and in the numerator of none. Exclude them from the analysis window, or test in a period with no campaign running. The same applies to Website Traffic and Realistic Traffic volume. And do not fall back on bounce rate as a quality metric, for the reasons covered separately. All of this sits inside the wider search experience optimization picture, where the form is one of several things happening after the click.

Open your highest-traffic form on a phone, in a fresh browser profile, arriving from a real search result. Then work down this list.

1. Classify every field into automatic, recall, judgment, lookup or disclosure. Reorder ascending by cost.
2. Run the four questions on each field, in writing. Delete or relocate everything with no named decision and no named reader.
3. Check the autocomplete tokens against the HTML standard. Every one of them. Remove stray autocomplete="off".
4. Check type and inputmode on email, phone and any numeric string field. Verify the keyboard that actually appears on a real device, not in the desktop emulator.
5. Confirm every input has a visible label with a for attribute, and that no label exists only as a placeholder.
6. Submit the form wrong on purpose, then type an email address slowly. Is each error tied to its field, announced, and written so it says how to fix the problem? Does focus move? Does anything fire before you finish typing?
7. Tab through the whole form without touching the mouse. Note anything you cannot see, cannot reach, or reach in the wrong order.
8. Measure the consent checkbox and its label. Under 24 by 24 CSS pixels is a submit blocker, not a nitpick.
9. Pull the three rates above and decide whether the problem is inside the form or above it, then write down your qualified definition and control set before shipping.