Forms

The examples on this page show how we manage forms and their fields, and their default styles. Recommendations are based on Adam Silver's article Form design: from zero to hero all in one blog post and the GOV.UK design system.

An example search form is available in core components.

Form error messages are covered separately.

Top tips

• Every input needs a label. Do not wrap inputs in labels, put labels above the input.
• Placeholders are problematic, so avoid using the placeholder attribute, especially for providing any meaningful instructions. Do not use it to replace a label.
• Use fixed width inputs for content that has a specific, known length. Postcode inputs should be postcode-sized, telephone number inputs should be telephone number-sized.
• Make form fields look like form fields: apply a border and make sure that fields are empty to begin with. A minimum height of 44 pixels makes them easy to tap on touch screen devices.
• Make sure any button looks like a button. Align them to the left edge of the last input (the right edge for right-to-left languages) where users naturally look for them. Use a verb for button text because the user is doing something, and relate it to what they are doing - avoid generic ‘Submit’ buttons.
• The select element should be a last resort as they’re really hard to use. Try radio buttons instead. If there’s a long list of options, use JavaScript to enhance the select into an accessible auto-complete field (not to be confused with the autocomplete attribute).
• If you have to use a select and selecting an option will result in a change of context (e.g. a page reload/refresh causing a change in focus), that change must be triggered by an accompanying confirmatory button, not by the change to the select value. Note that select works very differently outside the MacOS environment - using the arrow keys in Windows automatically switches between options, while on MacOS it first brings up the list of options.

Required fields

Well-designed forms usually avoid optional fields (one way is with branching questions). This means optional fields should be rare, and we want to highlight them to people:

• Add the required attribute to mandatory input fields (or aria-required="true" if for some reason you have to use a non-native element as an input).
• Highlight optional fields only, by adding (optional) to the end of the visible label text for fields that are not required.

How to add hint text

To provide hint text advising how to complete a field, add a div class="field-hint". Check the examples that follow to see where this should be added. The pattern differs slightly for checkbox and radio inputs compared to other input types.

Each instance of div class="field-hint" must have a unique ID that is used as the value of the aria-describedby attribute that must be added to the associated input.

Use the pattern id="hint-..., replacing the ... with your unique wording.

Provide hint text when users are more likely to make a mistake, such as when having to satisfy a complex set of password rules. Error messages should be a last resort. Keep hint text brief and to the point. Do not use long paragraphs and lists.

How to make filling in text fields easier

Use the relevant input type when asking for email addresses, URLs and passwords.

Adding the autocomplete attribute to common fields such as name, address, email etc. can help to speed up the form filling process for users. Here is a list of valid autocomplete values.

Use autocapitalize="none", autocorrect="off" and spellcheck="false" to stop browsers automatically changing user input on fields that expect grammatically incorrect data, such as email addresses and passwords.

How to make filling in number fields easier

In many cases, it's better to use input type="text" pattern="[0-9]*" inputmode="numeric" rather than input type="number" when dealing with numbers. Adam Silver has written about when to use the number input.

For telephone numbers, use the type="tel" and inputmode="tel" attributes on the input.

When asking for payment details, including the autocomplete attribute can help users complete their responses more quickly. Older browsers make use of the name attribute to achieve the same thing. Here is a list of payment autofill attributes.

How to make providing dates and times easier

For dates that the user will already know (e.g. birth dates) and dates that are easy to look up, use a series of simple text inputs. Note the use of fieldset and legend to group the separate text inputs together.

For other dates, due to inconsistencies with how different browsers and Assistive Technologies interpret input type="date", the current recommendation is to use a simple text input. Provide hint text to let users know what format to use.

Again, due to inconsistencies with how different browsers and Assistive Technologies interpret input type="time", it is strongly recommended to use a simple text input. The preceding example includes a select to help users specify a local timezone.

How to make checkboxes easier to use

Always position checkboxes to the left of their labels (to the right for right-to-left languages). This makes them easier to find, especially for users of screen magnifiers.

If required, hint text can be added for the entire checkbox group and/or for individual checkbox items. The preceding example shows how to do this.

How to make radios easier to use

Always position radios to the left of their labels (to the right for right-to-left languages). This makes them easier to find, especially for users of screen magnifiers.

Radio buttons cannot be unchecked once they are selected. So if the question is not mandatory, you'll need to include a ‘None’ or ‘Prefer not to say’ option.

If required, hint text can be added for the entire radio group and/or for individual radio items. The preceding example shows how to do this.

The purpose of segmented options is to show all available options outright, rather than hiding them behind a select. It can be used with either checkboxes, or with radio buttons as in the preceding example.

The basis of this pattern is the switcher layout. The default styles assume that there are three choices and are optimised for this. In the event of fewer or more choices, you can override the default min-width percentage by applying an additional class.

Considerations

The select element should be a last resort as they’re really hard to use. Before using it, try asking users questions which will allow you to present them with fewer options. This should lessen the need for the select element, which could be replaced with e.g. radios.

If using the select element to determine a change in browsing context (e.g. change to a map display or redirect to a different URL) it must be accompanied by a submit button, so that users can confirm their choice and make a correction if needed.

Accessible auto-complete

A select can be enhanced into an accessible auto-complete via JavaScript. Amplify uses the Accessible autocomplete NPM package, and there are a number of example customisations which can be followed.

Grouping inputs to line up side-by-side

The class input-group can be used to align form inputs horizontally with each other, by applying Flexbox behaviour. You can see an example of this in the preceding example for dealing with times.

Considerations

This class should not be used in conjunction with radios or checkboxes. The pattern has not been fully tested with these input types and may not work well on smaller viewports. Furthermore, radios and checkboxes are easier to read and quicker to scan when presented vertically.

Fixed-width inputs

There is a collection of CSS classes prefixed with input-width- which, when added to an input, will reduce the maximum width of the input field to better suit the intended contents:

Form validation

The best practice is to validate a form on submission. It is recommended to avoid default HTML5 form validation. To turn this off, add the novalidate attribute to the form element.

It is strongly recommended to visit the GOV.UK Design system for more details about form validation.

Client side validation

If client side validation is required, here are some suggested JavaScript libraries:

• Parsley
• PristineJS

Alternatively, you could roll your own thanks to Chris Ferdinandi's series on form validation.