Field types

Users know forms fields better than they think they do.

Fields are where the user inputs their information. Many users are familiar with field types that have a specific purpose. Therefore it is important to choose the right type of field that meets user expectations and avoids confusion.

Text fields

A text field is for small amounts of free text for example Name. The different types of text fields are listed below:

Label: Sits directly above the field to describe what the user should enter.

Field: The width of the field is by default full width of the container. In the case of Desktop and Tablet screens, there are two other widths to choose from for smaller fields. For input smaller than this, use the Variable small field:

  • Medium: 50% of container. (Max 18 char) Example usage: Phone number / Reference number
  • Small: 37.5% of container (Max 12 char). Example usage: Date input
  • Variable small: 45px min-width (Use for 1-4 char) Example usage: Time in Hours and Minutes.

Placeholder: Should only hold non-essential, example text, Since the text disappears there should never be a reliance on users to remember the text. Numerical inputs have ‘0’ placeholders (centre-aligned) to indicate the type of data to be entered. Placeholders are considered inaccessible as they disappear as soon as the user focus on the field. Treat them as visual indicators.

Plain text

A plain text field has no restrictions on the input. Apart from the character count, this is a field that can be used flexibly. It has little support in terms of browser side validation so it’s important that labels, hints and help text is used to show what the user has to input.

Character count: Not shown to the user. The maximum number of characters in text field should be 300 characters, unless there is need for more.

forms_plain_text example
Plain text fields are by default full width of container as the input will likely be variable in size.


An email text field provides inbuilt validation of the email address in many browsers.

Validation: Check that the input is a valid email address.

Hint: For example “This must be a email address, for example ‘’”.

Field: Uppercase inputs should be converted to lowercase on entry.

forms_email example
Company name emails are often represented in title case, for example, ‘’. On entry any CAPS are converted to lowercase.


A number text field can only contain numerical digits. Any field that has letters or special characters should give a validation error; for example reference numbers for dates that are thought of as numbers often have letters or “/” in them.

Validation: Inputs should be numbers only. Spaces and commas should be ignored.

Hint: For example “Use only numbers 0-9”

Field: When there are more than 3 digits separate with comma in groups of 3, for example, “1,000” or “1,000,000”. When no more that 4 digits are allowed the input should be centred. When a number of inputs are totalled at the bottom then they should be right aligned. On mobile ensure the number keypad is displayed on focus.

forms_number example
The minimum size for a text input field is 45px x 42px. This accommodates up to two digits (including decimal). If any numerical field within a fieldset is expected to have an input of 3 digits for example, then all fields should be the same width.


A telephone field does not have much browser support at the moment and due to the different types of phone numbers (local, distance, international, extensions) we have to develop our own validation. This is still in an alpha state and therefore cannot be robustly relied upon.

Validation: Check that it is a valid phone number.

Hint: For example “Please include area code”.

Label: Phone number rather than telephone.

Field: On mobile ensure the number keypad is displayed on focus.

forms_telephone example
Phone number fields can be displayed at 50% of the container with an 18 character limit. Use ‘Phone’ instead of ‘Telephone’ - it’s shorter and easy to understand.


A password field is used for the input or the creation of passwords only and will hide the user input by default, e.g. ‘*****’

Validation: Activated when the field loses focus. Passwords should have 8 or more characters and not include spaces. The error message should list all the things that make the entry invalid for example “Passwords can not have spaces”.

Tell user if the caps lock is on through a pop-up message.

Hint: The hint should list the criteria needed for a password for example “Passwords should have 8 or more characters”.

Character count: A countdown should be used to show the number of characters and turns green when the input is 8 or more without spaces.

Placeholder: Field must be blank in case users think it has autocompleted.

Field: Any input must be masked by asterisks or dots for example ‘****’

Show password: Show password is helpful to the user, especially if an account gets locked after a certain number of tries. However, there is a security issue with always being able to show the password especially when the browser stores the username and password.

Show password should only be used when creating and confirming a password.

Confirm password: When the password is successfully matched, there should be a tick to the right of the text field.

forms_password example
Passwords are masked within the field. If a user is creating a password, then the field should be followed up by a ‘Confirm password’ field.


There are different ways date fields can be displayed depending on how near or far away the date range is. It is up to the specific use case which date format should be used.

Validation: Should check for agreed format and if there are known restrictions, for example the date can’t be in the past. Format of the date has to be shown.

Hint: For example “Use dd/mm/yy format”

Placeholder: For example ‘e.g. 25/05/67’

Fieldset: Group related fields together horizontally - day, month, year. Once day has 2 valid digits the focus should automatically move to the month. The same behaviour is applied to the month.

Field: A plain text field that allows the user to directly enter the date. Alternative formats or mistakes are automatically corrected wherever possible (for example puts in ‘/’ automatically). Can be accompanied by a date picker.

Date picker: A date picker should be an addition and not a replacement for the input fields. This can make it easier for users to find the right date if within a year of the current date. For example the user knows it was last Saturday but doesn’t know the exact date. The date picker will allow them to pick the date rather than force them to work it out (they might not even know what today’s date is).

Today’s date should be highlighted when the date picker is selected. If it is a date range, then the first date selected should show while the second date is being selected. (If it’s likely that the dates are yesterday, today or tomorrow then buttons allow automatic selection.)

Dropdown for day, month, year: This reduces thinking time for the user. Note: Individual labels are not displayed for each dropdown field in this case. ‘Day’, ‘Month’ and ‘Year’ should be used for the Placeholder.

Time: Hours and minutes should be dropdowns. Hours listing 1 to 12 and minutes listing 1 to 60, in increments of 1, 5, 10 or 15 minutes. AM/PM radio buttons should sit alongside with AM auto-selected.

Legend: Clearly title each fieldset appropriately.

forms_date example
The example above allows user to choose whether they type the date in or choose a date from the date picker on the right. The hint below the label tells the user what format is required and the placeholder gives an example. DD MM YYYY (spaces) or DDMMYYYY (no spaces) should be converted to DD/MM/YYYY on blur (de-focus).

Fieldset: Group related dependent fields together. For example grouping of Radio buttons, Checkboxes and Date fields. Grouping enables error messages to be associated with several closely related fields.

Legend: Each title must be clear (usually a question). In a fieldset of dependent fields the legend adopts the default label styling, with the labels for each dependent field being given less prominent styling.

Label: Doesn’t look like a regular label. Sits to the right of the field by default. In cases where this doesn’t work, it can be placed above the field.

Field: Width should be appropriate size for expected input.

Placeholder: Should only hold example text. As the text disappears, the users shouldn’t have to remember the text. Numerical inputs have ‘0’ placeholders (centre-aligned) to indicate the type of data to be entered.

Validation: Fieldset error messages are positioned above the top field if related to all fields or directly below the corresponding field. When the error relates to all fields then it is supported by a red tint background box with red dashed border surrounding all fields. If the fields are placed horizontally on one line then they are treated as a single element with the error message below the fields and no surrounding box.

forms_related example
Labels are by default positioned to the right of fields within fieldsets. This allows fields within a form to be left-aligned making it easy for the user to scan the page and to navigate from one field to the next. Fieldset error box is used to encapsulate all fields that an error message applies to.

Address fields

Address picker: This should be at the top of the address fields. List all possible addresses under a postcode from database.

Fields: Address line 1, 2, 3, country and postcode.


Validation: Where possible entries should be checked against a valid postcode database.

Hint: For example “Must be a UK postcode, for example EH6 6QQ.

Field: Lowercase inputs should be converted to uppercase on entry. If possible users can select from a list of addresses with that postcode.

Alternative: “Don’t know postcode?” should always be provided if using a postcode lookup.

forms_postcode example
The postcode field should be set to display uppercase as the user enters letters even if the user inputs lowercase. This makes it easier for users particularly on mobile devices.

Text box

Label: Sits directly above the text box to clearly indicate what the user should enter.

Character count: Only shown for this type of field. Used when there is a limit or importance to the number of characters used. Positioned to the left below the field. The count should start at the maximum and work down as the user types. The border and negative number turns red if the character count is exceeded.

Default character limit is 700 characters. Medium and Large boxes have a limit of 1500 and 3500 respectively.

Text box: Default is full width of main pane and 4 line height. Height, should reflect expected content, so:

  • ‘Reason for leaving’ might be Small (4 lines)
  • ‘Main duties’ might be Medium (10 lines)
  • Personal statement might be Large (20 lines)

Maximum input is approximately double the initial set line height i.e. 10, 20 and 40 lines.

As the user enters text beyond the set height, the box expands. If the input box is bigger than the viewport then the cursor should align to the bottom of the viewport (above the keyboard on touch devices, and react when the keyboard is deactivated).

Validation: When the character count is exceeded, it displays negative numbers and turns red. When focus is lost on the box and character count is still exceeded the border turns 2px red and a red error message is shown.

forms_text_box example
Examples of Small, Medium and Large text boxes. If the expected input is to be long then use a Large text box to set expectation and avoid unnecessary masking of content. Initial views are set at 4, 10 and 20 lines respectively. Maximum input is approximately double this i.e. 10, 20 and 40 lines.

Label: Sits above the select element to show what the list represents.

List: Width appropriate to list entries. Unless a mandatory field, the list should always have all, none or zero value entry.

Placeholder: Should not be an example in case users think that it has already been automatically selected. Instead use prompts or titles, for example ’Please choose from list’ or ‘Month’ or leave blank.

forms_dropdown example
Examples of select boxes at size appropriate to the content.


Legend: Clearly title each fieldset appropriately.

Fieldset: Group all related checkboxes with corresponding labels under the one legend. Always group related fields together.

Grouping helps the user to scan the document and make sure that there is no missing information.

Hint: should go below the legend and indicate whether the the user can select on or many checkboxes.

Label: Positioned to the right of the check behaving like an unordered list. This allows users to move cursor down in a straight line selecting multiple boxes and easily identify the corresponding check box to the label (instead of a ragged right hand side). Check boxes should not be listed horizontally.

Validation: Error messages are positioned above the first checkbox supported by a red tint background box with red dashed border surrounding all the checkboxes.

forms_checkbox example
When checkboxes are used as part of a filter set and space is at a premium, then it is recommended that a minimum hit/touch area of 40px is honoured to avoid accidental select of neighbouring checkboxes.

Radio button

Legend: Give each fieldset a clear title (usually the question).

Fieldset: Group all related radio buttons with corresponding labels under the one legend. Always group related fields together, for example Yes, No. Radio buttons can be placed horizontally if there is a maximum of 2 options.

Label: Positioned to the right of the button behaving like an unordered list. Radio buttons should be clearly grouped and labelled.

Validation: Error messages are positioned above the first radio button supported by a red tint background box with red dashed border surrounding all the radio buttons. If radio buttons are positioned horizontally on one line then they are treated as a single element with the error message below the radio buttons and no surrounding box.

forms_radio example
If there are only 2 short options then they can be presented side by side. In this instance, error messaging is handled as it is on standard one line fields ie no encapsulating box and message appears below the fields.