How to optimise contact and checkout forms to stop losing customers

How do you optimise a form? Validate on blur rather than in real time, show errors in both a page-level summary and a per-field message, and follow GOV.UK‘s three-step error pattern. Cut every field you don’t truly need, label inputs clearly, and make error states accessible. Do that and you stop losing customers at the two moments that matter most: the contact form and the checkout.

TL;DR: Validate on blur, pair an error summary with per-field messages, reduce fields aggressively, and test on real users.

Form optimisation is the difference between a visitor who completes a purchase and one who abandons it. Average e-commerce checkouts carry around 23.48 fields when the best-performing ones use just 12–14 (baymard.com/blog/checkout-flow-average-form-fields), and roughly 70% of carts are abandoned before completion (baymard.com/lists/cart-abandonment-rate). The fixes, though, are well documented and repeatable — grounded in guidance from the GOV.UK Design System, the Nielsen Norman Group (NNGroup), and the W3C.

This is a practical companion to our conversion rate optimisation guide — start there for the bigger picture, then use this checklist to fix your forms.

Why form optimisation matters

Poorly designed forms cause abandonment. Every unnecessary field, premature error, and confusing message adds friction at the exact point where a user has already decided to act. Removing that friction is the highest-leverage work you can do on a contact or checkout flow.

Visibility of system status is the founding principle. As NNGroup’s first usability heuristic puts it, a design should always keep users informed about what is happening through timely feedback (nngroup.com). A form that fails silently — or shouts errors before the user has finished typing — breaks that contract.

The four UX rules that stop form abandonment

Validate on blur, not while typing

Validating before a user has finished is the most-cited hostile pattern in form design. NNGroup compares real-time validation to grading a test before the student has had a chance to answer (nngroup.com). The GOV.UK Design System goes further, advising teams not to validate when a user leaves a field but to wait until they submit (design-system.service.gov.uk). The pragmatic middle ground NNGroup recommends is on-blur validation — check a field once the user moves to the next — reserving inline real-time checks for complex inputs such as password-strength meters (nngroup.com).

Show error summaries and per-field messages together

The two work as a pair. An error summary at the top of the page lets users locate every problem at once, while a message beside each field minimises working-memory load (nngroup.com). Use the same wording in both, and make each summary item an anchor link that jumps to the field it describes.

Reduce fields aggressively

If the best checkouts use 12–14 fields and the average uses 23.48 (baymard.com/blog/checkout-flow-average-form-fields), the lesson is blunt: cut everything that isn’t essential. Match each field’s width to its expected input, use a single-column layout, and order fields logically (nngroup.com).

Use labels above inputs, not placeholders

Labels belong above the input, in sentence case, and should never be replaced by placeholder text — placeholders vanish the moment a user starts typing, which is a particular problem for people with memory conditions (design-system.service.gov.uk).

The GOV.UK error pattern (the accessible gold standard)

The GOV.UK three-step pattern is the most reliable accessible approach to form errors (design-system.service.gov.uk):

1. Prepend “Error: ” to the page title so screen readers announce the problem immediately.
2. Show an error summary at the top of the page with role="alert", headed “There is a problem”, and move keyboard focus to it.
3. Show a message next to each invalid field, using the same wording as the summary.

Wording matters as much as placement. GOV.UK recommends choosing between instruction style (“Enter your first name”) and description style (“Date must be after 31 August 2017”) depending on what reads naturally (design-system.service.gov.uk). NNGroup adds that messages must be constructive, preserve the user’s input, and avoid words like “invalid” or “illegal” (nngroup.com). “An error occurred” is never good enough.

Accessible markup checklist

Accessible forms depend on a small set of ARIA attributes used correctly:

• aria-invalid — set to true only after validation has run, never before the user has interacted with the field (w3.org).
• aria-describedby — associate each error message with its field so assistive technology reads them together (w3.org).
• role="alert" on the error summary so it is announced immediately (w3.org).
• aria-live="polite" for inline field feedback, so the screen reader finishes its current announcement before reading the error. The live-region container must already exist in the DOM on page load for most screen readers to announce injected content (w3.org).

Never rely on colour alone. Around 350 million people worldwide have colour-vision deficiency, so every error needs at least two channels — colour plus an icon, text, or a border-weight change (nngroup.com).

How to implement in WordPress

GOV.UK instructs developers to add novalidate to form tags and avoid the HTML required attribute, because native browser messages behave inconsistently across browsers and can’t be styled to match a design system (design-system.service.gov.uk). Smashing Magazine’s accessible-validation guide backs the same approach (smashingmagazine.com) — and remember that server-side validation must always sit behind any client-side checks.

For plugins, Gravity Forms (with legacy markup disabled) and Formidable Forms produce accessible markup; for WPForms, enable “Modern Markup” in General Settings (gravityforms.com). Install the WP Accessibility plugin on every build — it adds labels to standard fields, removes problematic tabindex values, and forces error handling on empty search strings (wordpress.org).

If you’d rather hand this to a team, our WordPress hosting and maintenance service covers exactly this kind of accessibility hardening, and our web design service builds forms to this standard from the start.

How to implement in Shopify

Shopify’s Dawn theme — like most themes — leans on visual-only browser validation without programmatic associations for assistive technology (testparty.ai). Follow Shopify’s own accessibility best practices and add aria-live="polite" so cart additions and filter results are announced to screen readers (shopify.dev). For empty carts, Dawn’s main-cart-items.liquid provides an empty-state with a “Continue Shopping” button you can extend with featured collections (github.com). Validate themes with shopify theme check before you ship. Our Shopify design and development service applies these patterns across the storefront.

What to avoid

• Validating before input is complete — the single most common hostile pattern (nngroup.com).
• Colour-only error states — they fail WCAG 1.4.1 and exclude colour-blind users (nngroup.com).
• Errors hidden in tooltips — NNGroup warns against alert icons that require a click to reveal the message (nngroup.com).
• Missing ARIA associations — inputs without aria-describedby links leave screen-reader users guessing (testparty.ai).
• Blank 404s — a dead end with no search bar or navigation, when it should return a proper 404 status and offer a clear way back (searchenginejournal.com).

Optimise your forms, keep your customers

Form optimisation isn’t a redesign — it’s a set of disciplined, accessible defaults: validate on blur, pair summaries with per-field messages, cut fields ruthlessly, and mark up errors so everyone can recover. Apply the GOV.UK pattern as your baseline, test on real users, and the forms that used to leak customers will start converting them.

Your form might be costing you sales. We audit contact and checkout forms for UX and accessibility, then implement the fixes that stop abandonment. Book a free form audit.