GOV.UK form patterns: a practical reference

Forms are most of the journey on any GOV.UK service. The Design System covers them in depth, but in practice teams reach for the same dozen patterns over and over and trip over the same edges. This is a reference to the patterns we generate every day in Vibe, with the decisions you have to make to use them well.

For the canonical specs, see the Design System components and patterns on GOV.UK.

Radios vs checkboxes

The wrong choice is the most common form bug in alpha prototypes. The rule:

• Radios when the user picks one option from a small known list (under about seven). A licence type, a nationality from a short list, a yes/no answer.
• Checkboxes when the user can pick none, one or many. Conditions that apply, documents they have, notifications they want.

Two specific edges:

• A binary yes/no question is radios, not a checkbox. A checkbox means “I agree this is true”, which is the wrong mental model for “Do you have a National Insurance number?”.
• If the list of options is long (more than about 20), neither is right. Use an autocomplete or a select component.

Date input

The Design System date input is three fields side by side (day, month, year), each labelled, each accepting a partial value. Not a date picker. The reason: keyboard entry is faster than a picker for known dates (birthdays, application dates), and assistive technology handles three text inputs more predictably than a bespoke calendar widget.

Two rules to remember:

• Never use a date picker for a date the user knows. Date pickers are for choosing from a constrained set (available appointment slots), not for entering a birthday.
• Validate forgivingly. “1 1 90”, “01/01/1990” and “01-Jan-1990” should all resolve. The validation should reject impossible dates and ambiguous formats, not punish typing style.

Address lookup

The pattern is: ask for the postcode first, look up addresses, let the user pick from a list. Falling back to manual entry if the postcode isn’t found.

The procurement angle most teams miss: you need an address API (Ordnance Survey Places API, GetAddress.io, Loqate, or PAF). Decide before alpha which one, because the contract terms differ sharply between commercial and public-sector pricing and the service assessment panel will ask.

Error summary

The single most important accessibility pattern on a GOV.UK service. When form validation fails, the page reloads with an error summary at the top, listing every error, each linking to the field. The page title changes to “Error: [page name]”.

Three things teams get wrong:

• Summary missing on validation failure. If the form posts back without an error summary, screen-reader users have no way to know what failed. This is a service-assessment fail.
• Summary not focused after submit. The summary needs tabindex="-1" and to receive focus on render, so the next thing the user hears is the summary, not the page nav.
• Error messages that just say “Required”. GOV.UK error messages name the field and what to do: “Enter your date of birth”, not “This field is required”.

File upload

File upload looks simple and isn’t. The Design System component gives you the input; the patterns around it are where the work lives.

• State which file types are accepted in the hint text, not as a tooltip. “You can upload a JPG, PNG or PDF, up to 10MB.”
• Validate the type and size client- and server-side. Client-side is for fast feedback; server-side is for security. Neither is enough alone.
• Plan the error states. What does the page say if the upload fails halfway? If the file is virus-scanned and flagged? If the user tries to upload a second file when only one is allowed? Each of these needs a written error.

Long questions and follow-ups

When a question has follow-ups that only apply to some answers, the Design System has the conditional reveal pattern: a radio or checkbox option, when picked, reveals an additional field below it. The reveal must be inside the form so it submits with the answer; it must be properly associated with the option (aria-controls); the revealed field gets a visible focus state.

For very long questions, the pattern shifts to one question per page. Government services err heavily on the side of question-per-page because it improves completion rates, reduces cognitive load, and makes the back button do what users expect.

What Vibe generates by default

Every Vibe-generated form ships with:

• The correct Design System component for the field type, picked from the spec.
• Server-side validation in Express with messages written in the GOV.UK style (“Enter your date of birth” not “Field required”).
• An error summary at the top of the page on validation failure, focused on render, with each error linked to its field.
• Page title updates to “Error: [page name]” on validation failure.
• Conditional reveal patterns when the spec implies follow-up questions.

You can override any of it from the spec. “Use a text input instead of radios for the nationality question” is a one-line change.

For canonical detail, the GOV.UK Design System and the Service Manual are authoritative. Vibe.WithGov is an independent product and not affiliated with the Government Digital Service. See the FAQ for more.