Input
Use the text input component when you need to let users enter text that’s no longer than a single line, such as their name or phone number.
When to use this component
When not to use this component
Do not use the text input component if you need to let users enter longer answers that might span multiple lines. In this case, you should use the textarea component.
How it works
All text inputs must have labels, and in most cases, the label should be visible.
You should align labels above the text input they refer to. They should be short, direct and written in sentence case. Do not use colons at the end of labels.
Avoid placeholder text
Do not use placeholder text in place of a label, or for hints or examples, as:
it vanishes when the user starts typing, which can cause problems for users with memory conditions or when reviewing answers
not all screen readers read it out
its browser default styles often do not meet minimum contrast requirements
If you’re asking one question on the page
If you’re asking just one question per page as recommended, you can set the contents of the <label> as the page heading. This is good practice as it means that users of screen readers will only hear the contents once.
There are 2 ways to use the textarea component. You can use HTML or, if you are using Nunjucks, you can use the Nunjucks macro.
Get the Nunjucks macro for this example from the Camden Frontend library
If you’re asking more than one question on the page
If you’re asking more than one question on the page, do not set the contents of the <label> as the page heading.
Get the Nunjucks macro for this example from the Camden Frontend library
Use appropriately sized text inputs
Help users understand what they should enter by making text inputs the right size for the content they’re intended for.
By default, the width of text inputs is fluid and will fit the full width of the container they are placed into.
If you want to make the input smaller, you can either use a fixed width input, or use the width override classes to create a smaller, fluid width input.
Use fixed width inputs for content that has a specific, known length. Postcode inputs should be postcode-sized, phone number inputs should be phone number-sized.
The widths are designed for specific character lengths and to be consistent across a range of browsers. They include extra padding to fit icons that some browsers might insert into the input (for example to show or generate a password).
On fixed width inputs, the width will remain fixed on all screens unless it is wider than the viewport, in which case it will shrink to fit.
Hint text
Use hint text for help that’s relevant to the majority of users, like how their information will be used, or where to find it.
Get the Nunjucks macro for this example from the Camden Frontend library
Do not use hint text to explain anything that’s longer than a short, simple sentence. Screen readers read out the entire text when users interact with the form element. This could frustrate users if the text is long.
Do not include links within hint text. While screen readers will read out the link text when describing the field, they will not tell users that the text is a link.
Codes and sequences
Help the user visually check the code they’ve typed is correct by styling the input’s text to visually separate each character. This is important if you’re asking the user to enter a code or sequence they’re unlikely to have memorised, such as an application reference ID, account number or security code.
You do not need to do this for memorable information, such as phone numbers and postcodes.
Get the Nunjucks macro for this example from the Camden Frontend library
Prefixes and suffixes
Use prefixes and suffixes to help users enter things like currencies and measurements.
Get the Nunjucks macro for this example from the Camden Frontend library
Prefixes and suffixes are useful when there’s a commonly understood symbol or abbreviation for the type of information you’re asking for. Do not rely on prefixes or suffixes alone, because screen readers will not read them out.
If you need a specific type of information, say so in the input label or hint text as well. For example, put ‘Cost, in pounds’ in the input label and use the ‘£’ symbol in the prefix.
Position prefixes and suffixes so that they’re outside of their input. This is to avoid interfering with some browsers that might insert an icon into the input (for example to show or generate a password).
Some users may miss that the input already has a suffix or prefix, and enter a prefix or suffix into the input. Allow for this in your validation and do not show an error.
Get the Nunjucks macro for this example from the Camden Frontend library
Get the Nunjucks macro for this example from the Camden Frontend library
Use the autocomplete attribute
Use the autocomplete attribute on text inputs to help users complete forms more quickly. This lets you specify an input’s purpose so browsers can autofill the information on a user’s behalf if they’ve entered it previously.
For example, to enable autofill on a postcode field, set the autocomplete attribute to postal-code. See how to do this in the HTML and Nunjucks tabs in the following example.
Get the Nunjucks macro for this example from the Camden Frontend library
If you are working in production and there is a relevant input purpose, you’ll need to use the autocomplete attribute to meet WCAG 2.2 Level AA.
You will not normally need to use the autocomplete attribute in prototypes, as users will not generally be using their own devices.
Do not disable copy and paste
Users often need to copy and paste information into a text input, so do not stop them from doing this.
Avoid restricting the length of a user’s input
Using the maxlength attribute means there is no feedback to users that their text input is truncated. This is especially true where the text has been copied and pasted from elsewhere. This can cause users to accidentally provide incorrect or incomplete information.
A restrictive maximum length can stop users from formatting information in their usual way. For example, putting spaces in a postcode or commas in a large number.
Some assistive technologies do not tell users if an input has a maxlength set or if the user has passed the limit. Voice control software may insert additional spaces into the input.
If you must enforce a maximum length for technical reasons, inform the user of the limit in the hint, but allow them to provide more information. Only return an error if the value is longer than allowed after normalisation. For longer values, consider using the character count component instead.
How and when to spellcheck a user’s input
Sometimes, browsers will spellcheck the information a user puts into a text input. If a user enters something which is recognised as a spelling error, sighted users will see a red line under the word.
If you are asking users for information which is not appropriate to spellcheck, like a reference number, name, email address or National Insurance number, disable the spellcheck.
To do this set the spellcheck attribute to false as shown in this example.
Get the Nunjucks macro for this example from the Camden Frontend library
Browsers do not consistently spellcheck user’s input by default. If you are asking a question where spellcheck would be useful, set the spellcheck attribute to true.
Error messages
Error messages should be styled like this:
Get the Nunjucks macro for this example from the Camden Frontend library
Get the Nunjucks macro for this example from the Camden Frontend library
Make sure errors follow the guidance in error message and have specific error messages for specific error states.
Say ‘Enter [whatever it is]’.
For example, ‘Enter your first name’.
Say ‘[whatever it is] must be [number] characters or less’.
For example, ‘Address line 1 must be 35 characters or less’.
Say ‘[whatever it is] must be [number] characters or more’.
For example, ‘Full name must be 2 characters or more’.
Say ‘[whatever it is] must be between [number] and [number] characters’.
For example, ‘Last name must be between 2 and 35 characters’.
Say ‘[whatever it is] must not include [characters]’.
For example, ‘Town or city must not include è and £’.
Support all the characters the user might need to enter, including numbers and symbols.
Say ‘[whatever it is] must only include [list of allowed characters]’.
For example, ‘Full name must only include letters a to z, and special characters such as hyphens, spaces and apostrophes’.
Support all the characters the user might need to enter, including numbers and symbols.
Say ‘[whatever it is] must be a number [optional example]’.
For example, ‘Hours worked a week must be a number, like 30’.
If the input requires a decimal, use a decimal in the example. If the input allows both whole numbers and decimals, use both in the example.
Say ‘[whatever it is] must be a whole number [optional example]’.
For example, ‘Hours worked a week must be a whole number, like 30’.
Say ‘[whatever it is] must be [lowest] or more’.
For example, ‘Hours worked a week must be 16 or more’.
Say ‘[whatever it is] must be [highest] or fewer’.
For example, ‘Hours worked a week must be 99 or fewer’.
Say ‘[whatever it is] must be between [lowest] and [highest]’.
For example, ‘Hours worked a week must be between 16 and 99’.
Say ‘[whatever it is] must include pence, like 123.45 or 156.00’.
For example, ‘How much you earn a week must include pence, like 123.45 or 156.00’.
Say ‘[whatever it is] must not include pence, like 123 or 156’.
For example, ‘How much you earn a week must not include pence, like 123 or 156’.
Research on this component
This component is based on the text input component from the GOV.UK Design System.
You can take part in the ‘Text input' discussion on GOV.UK’s Design System’s GitHub and share your research.