NotGovUK
Unofficial
Internal
Components

Text input

Props
NameTypeDefaultDescription
idstring-'id' attribute to place on the base HTML element
classBlockstring-Block name override in BEM style classes applied to all elements
classModifiersModifiers[]BEM style modifiers to apply to the base HTML element
classNamestring-Extra classes to apply to the base HTML element
suffixstring-Suffix to show after the field
errorReactNode-Error message
hintReactNode-Hint
labelReactNode-REQUIRED. Label

When to use this component

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 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 visible labels; placeholder text is not an acceptable replacement for a label as it vanishes when users start typing.

Labels should be aligned 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.

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.

Read more about why and how to set legends as headings.

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. Read more about asking multiple questions on question pages.

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.

Fixed width inputs

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.

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.

Fluid width inputs

Use the width override classes to reduce the width of an input in relation to its parent container, for example, to two-thirds.

Fluid width inputs will resize with the viewport.

Hint text

Use hint for help that’s relevant to the majority of users, like how their information will be used, or where to find it.

The name you’ll use on promotional material.

When not to use hint text

Do not use long paragraphs and lists in hint text. Screen readers read out the entire text when users interact with the form element. This could frustrate users if the text is long.

Avoid links

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.

Numbers

Asking for whole numbers

If you’re asking the user to enter a whole number and you want to bring up the numeric keypad on a mobile device, set the inputMode attribute to numeric and the pattern attribute to [0-9]*. See how to do this in the HTML and Nunjucks tabs in the following example.

Must be between 6 and 8 digits long

You should also turn off HTML5 validation to prevent browsers from validating the pattern attribute.

There is specific guidance on how to ask for:

Asking for decimal numbers

If you’re asking the user to enter a number that might include decimal places, use input type="text" without inputMode or pattern attributes.

Do not set the inputMode attribute to decimal as it causes some devices to bring up a keypad without a key for the decimal separator.

Avoid using inputs with a type of number

Do not use <input type="number"> unless your user research shows that there’s a need for it. With <input type="number"> there’s a risk of users accidentally incrementing a number when they’re trying to do something else - for example, scroll up or down the page. And if the user tries to enter something that’s not a number, there’s no explicit feedback about what they’re doing wrong.

Prefixes and suffixes

Use prefixes and suffixes to help users enter things like currencies and measurements.

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.

Text inputs with a prefix

Text inputs with a suffix

Use the autoComplete prop

Use the autoComplete attribute / prop 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 prop to postal-code. See how to do this in the HTML and Nunjucks tabs in the following example.

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.1 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.

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.

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:

The name you’ll use on promotional material.

Error: Enter an event name

If the input has a prefix or a suffix

Error: Enter a cost per item, in pounds

Make sure errors follow the guidance in error message and have specific error messages for specific error states.

If the input is empty

Say ‘Enter [whatever it is]’. For example, ‘Enter your first name’.

If the input is too long

Say ‘[whatever it is] must be [number] characters or fewer’. For example, ‘Address line 1 must be 35 characters or fewer’.

If the input is too short

Say ‘[whatever it is] must be [number] characters or more’. For example, ‘Full name must be 2 characters or more’.

If the input is too long or too short

Say ‘[whatever it is] must be between [number] and [number] characters’. For example, ‘Last name must be between 2 and 35 characters’.

If the input uses characters that are not allowed and you know what the characters are

Say ‘[whatever it is] must not include [characters]’. For example, ‘Town or city must not include è and £’.

If the input uses characters that are not allowed and you do not know what the characters are

Say ‘[whatever it is] must only include [list of allowed characters]’. For example, ‘Full name must only include letters a to z, hyphens, spaces and apostrophes’.

If the input is not a number

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 is not a whole number

Say ‘[whatever it is] must be a whole number [optional example]’. For example, ‘Hours worked a week must be a whole number, like 30’.

If the number is too low

Say ‘[whatever it is] must be [lowest] or more’. For example, ‘Hours worked a week must be 16 or more’.

If the number is too high

Say ‘[whatever it is] must be [highest] or fewer’. For example, ‘Hours worked a week must be 99 or fewer’.

If the input must be between 2 numbers

Say ‘[whatever it is] must be between [lowest] and [highest]’. For example, ‘Hours worked a week must be between 16 and 99’.

If the input is not an amount of money and the field allows decimals

Say ‘[whatever it is] must be an amount of money [optional example that includes decimals and non-decimals]’. For example, ‘How much you earn an hour must be an amount of money, like 7.50 or 8’.

If the input is not an amount of money and the field needs decimals

Say ‘[whatever it is] must be an amount of money [optional example that includes decimals]’. For example, ‘How much you earn an hour must be an amount of money, like 7.50 or 8.00’.

If the input is an amount of money that needs decimals

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’.

If the input is an amount of money that must not have decimals

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’.