Forms cheat sheet

Provide labels or instructions whenever content requires user input.

Every source wants the status of a field to be clear. They differ on how to show it, and on how much weight their advice carries.

A visible label always, hint text for format, a required state where needed, and a message alongside the error styling. Specify label, hint, required state and error message for every field in the design, not only the default state.

Fields that collect information about the user must expose their purpose programmatically, so browsers can autofill them.

Information the user has already entered in the same process is either auto-populated or available to select, unless re-entering it is essential or needed for security.

When an input error is detected automatically, identify the item in error and describe the error to the user in text.

If an input error is detected and a correction is known, provide the suggestion to the user.

GOV.UK puts the error message after the question and hint text, in red, with a red border connecting it to the question. Do not clear any fields: keep both passing and failing answers.

GOV.UK always shows an error summary when there is a validation error, even if there is only one. It sits above the h1, links each error to its field, receives keyboard focus, and the page title is prefixed with "Error: ".

For legal commitments, financial transactions and changes to user data, at least one must be true. The submission is reversible, the data is checked and can be corrected, or the user can review and confirm before finalising.

No step of signing in may require a cognitive function test, such as remembering a password or solving a puzzle. The exception is when there is another method, or a mechanism to help, such as allowing password managers and paste.