Input field anatomy

The anatomy of input fields in our design system consists of several elements:

1. Labels: Labels are headings that identify the purpose or context of the input field. For example, a label might say "First Name" to indicate that the user should enter their first name in the text field. Standard label alignment is left-aligned with the field underneath. Labels are mandatory on all fields with some exceptions such as search fields used in the header.
2. Hint/Helper text: Helper text conveys additional guidance about the input field, such as how it will be used. It should only take up a single line and be persistently visible.
3. Required field indicators: To indicate that a field is required, display an asterisk (*) next to the label text and mention at the start of the form that asterisks indicate required fields.
4. Optional field indicators: Optional field indicators indicate that a field is optional. Clearly indicate optional fields by displaying the word ‘optional’ in parentheses next to the label text.
5. Placeholder text: Hints at what goes into a field. Placeholder text is optional. It should always be avoided unless communicating complex formatting requirements.
6. Trailing icons: Trailing icons are optional, they're often used to convey additional field functionality or options. This space should also be reserved to fit icons that some browsers might insert into the input (for example to show or generate a password) (UK.GOV n.d).
7. Validation messages
   1. Error messages: When text input isn't accepted, an error message can display instructions on how to fix it. Error messages are displayed above the input line.
   2. Success messages: When text input is accepted, a message can display to the inform the user. This is useful in situations like password generation where you can let the user know their password has met syntax requirements.

Visual style

Within our Design System we have 2 styles of input fields, outlined and filled.

Outlined text fields

Outlined text fields have more visual emphasis than filled text fields, making them stand out when surrounded by other content or components.

Filled text fields

Filled text fields have less visual emphasis than outlined text fields. They work best where there are many text fields that are placed together to reduce the visual weight of complex forms.

Input field sizes

Use the width of a text input field to suggest the length of information it should contain. It provides a visual guide for users. For instance, a postcode input field should be narrower than an email field.

By default, the width of text inputs is fluid and will fit the full width of the container they're 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.

Fluid width

There are 4 fluid widths for text-boxes.

Fixed width

There are 6 preset widths for text-boxes based on character numbers. 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.

Width is determined by the widest character which in most cases is capital ‘W’.

Research and rationale

Like most of our components input fields started off using the DTA designs as a base. As our Design System progressed, we saw a need to include additional styles with less visual weight as well as to investigate this pattern as a whole to understand why other Designs Systems had diverged from the original DTA patterns.

To inform our design choices we collated best practice research from a number of sources such as the Nielsen and Normans group articles, industry leaders, guidelines from Google's Material Design and the UK.GOV’s Design System and the IBM carbon Design System and experts such as author of Form design patterns book Adam Silver whose work focuses on highly accessible form patterns and the original sited research used by the DTA.

We also conducted a comparative review of forms patterns, looking at widths, heights, layout and features used by:

• UK.GOV
• IBM Carbon
• Material Design
• Adobe spectrum
• NSW Design System
• Atlassian
• Microsoft Fluent
• MOD.UK.

Borders

Based on research and advice from a third party accessibility audit of our components we chose to continue to use thick borders for our input boxes as seen in the DTA, borders must use the secondary-alt border colour which is crafted to meet a 3:1 minimum colour contrast ratio, W3C guidelines. Graphical objects that are very thin are harder to perceive, therefore have a higher contrast requirement of 4.5:1. Graphical objects that are thicker or are solid shapes have a lower requirement of 3:1. 1px is considered thin and 3px is considered thick. Because our forms are using 2px borders we opted to ensure our contrast ration actually closer to 4.5.

Outlined and filled styles

Some of the feedback we received on the current form component was that the thick and dark border styles often looked out of place with the rest of the page or when a form element was in an isolated location. We noticed that most other Design Systems reduced the border thickness to-compensate for this. As we didn't want to compromise the accessibility of our forms, we looked to our comparative analysis of forms patterns to see if there was an alternative approach to resolve this problem.

Our solution came from IBM Carbon, Microsoft Fluent and Google’s Material Design all of which employ a secondary form style called ‘Filled’. This style uses only a solid border at the base of the form and then different background colour shade for the fill. Within our Design System having only the 2px solid border at the base can soften the overall visual weight of the form field as well as give the form design a more modern aesthetic.

Both types of text fields use a container to provide a clear affordance for interaction, making the fields discoverable in layouts.

Size

During our review of Design Systems, we determined that the average size for a form field was between 32px and 48px high. This aligns with Apples Apple's Human Interface Guidelines and Google's Material Design Guidelines that recommend touch points should be at least 44px, Adam Silver also reinforces this with his recommendations that 44px height or more is good to ensure they're easy to tap (Silver, 2019).

In our Design System we chose to follow the NSW input components which used a height of 48px as this worked nicely with our underlying grid pattern and allowed for generous white spacing.

Colour

They often still work on light alternative and dark alternative backgrounds but care should be taken to check and ensure there are not contrast issues. It is recommended where possible to use only light or dark backgrounds for long forms for best performance.

Behaviour

One of the elements that was missing from the DTA’s form components that we discovered in our comparative review was the inclusion of a hover state for form elements. We chose to include this as an additional indicator to users that the form field is a clickable element, this was also consistent with Google Material Design’s (n.d) approach to text field behavior. In our component the hover state changes the border to colour to use the ‘Primary action colour’ which we have established with our Design System as an indicator of an interactive element.

When testing form behaviour, we also discovered that it made sense to use a consistent focus state for both the filled and outlined style of forms. The focus state which includes a 3px outline that surrounds the form element and a white background colour ensures optimum contrast for the user when they're inputting text. Making this state standout also aligns with Material Design guidance on focus states, suggesting that they should be highly emphasised and signified by an overlay, colour change.

Creating consistency wherever possible is part of our design principles and keeping focus states the same across all input fields aligns with this. Our belief is that it will help users recognise they're interacting with a form element no matter what its starting visual appearance is. This will be useful if a designer has used outlined and filled styles for different forms across the same website.

Hint messages

According to Material Design (n.d) best practice for hint messages is that they should only take up a single line and be persistently visible or visible only on focus. Our comparative review suggested hint text was commonly placed above and below the input field. During out testing though we discovered that browser auto-complete suggests would often cover the field if placed below. For this reason, we opted to follow the existing DTA convention of placing it between the label and input field, this is also what is recommend by the UK Government Design system (n.d) and Adam Silvers article on form design layouts (Silver, 2019).

Labels

Research informing guidelines for forms (Bargas-Avila et al. 2009) points to the best positioning for labels is to be above the text field as this results in a number of advantages:

• label length doesn't affect form field placement
• faster completion rates
• reduces the number of fixations (easier to scan).

The only adjustments we made from the original DTA source however was to increase the font-weight of these labels, enabling them to stand out better on the page which was in line with best practice of other Design Systems.

Required fields and optional fields

Research informing guidelines for forms (Bargas-Avila et al. 2009) and our own comparative review of common practices indicated that a red asterix was the best choice indicator to mark required fields. Using colour to highlight required fields was shown to lead to faster completion rates Pauwels et al. (2009).

The placement of the asterix in our Design System is at the beginning of the label, as it can draw attention to the field and make it easier to locate required fields when scanning multiple fields with labels of varying length.

For optional fields we chose to follow IBM Carbon (2023) convention of writing the word optional after the label.

Validation messages

Error and validation messages are positioned above the text field. This is because placing error messages under fields is problematic. Adrian Roselli (2017) author several books on web design offers the following simple arguments in his article on message positioning for why:

• auto-complete features in browsers obscure them
• on-screen keyboards can obscure them
• depending on how you programmatically associate this text with form fields, it may be an anti-pattern to announce afterward in screen readers.

We've also chosen to adopt Nielsen and Norman group's recommendations (Krause, 2019) that colour is used to help validations states stand out and that a transparent background shade of the same colour be added to the error field to make it salient on a page that includes many fields.

Validation Iconography

In our comparative review we found that icons were commonly included with error and validation messages. We chose to follow this convention and include icons in a validation messages. The incorporation of icons was also supported by Nielsen and Norman Group’s article on website form usability which states that Errors should be signaled through a variety of cues, not solely through colour and WCAG Level A requirements which state colour isn't used as the only means of conveying information. The article how to report errors (Krause, 2019) states that together with colour, using icons to the left of your error message will draw attention to the error and help users that are colour blind.

Planned improvements and research

There are a number of proposed features based on common functionality we noted in our comparative review that we intend to review as improvements to this component.

These include:

• use of tool tips in forms to replace placeholder text or provide additional context
• prefix and suffixes to help users enter things like currencies and measurements
• use of the Character Countdown component to inform users of how many characters they have left while typing in text fields
• autocomplete styling
• trailing icons such as show and hide options for password fields.

Classes

Variables

Accessible form requirements

Keep these considerations in mind if you're designing forms.

General guidelines

Never disable a submit button, even if all of the required fields aren't filled in. Instead, describe what needs to be done using validation and error messages (Atlassian, n.d).

For text fields with interactive trailing icons, the accessibility label should clarify its function (Google, n.d).

If you have multiple inputs for a field, don’t auto tab between them. It causes users to make mistakes (Silver, 2019).

Use 'autocapitalize="none"', 'autocorrect="off"' and 'spellcheck="false"' to stop browsers automatically changing user input on fields that expect grammatically incorrect data—like email addresses and passwords (Silver, 2019).
<input type="email" autocapitalize="none" autocorrect="off" spellcheck="false">

Use the <fieldset> and <legend> elements to group and associate related form controls (W3C,2019a).

Divide long forms into multiple smaller forms that constitute a series of logical steps or stages and inform users about their progress (W3C,2019a).

WCAG guidelines

Below details some of the guidelines for forms see the WCAG website for a more detailed accessibility guidance for each specific form element.

1.3.5: Identify input purpose

This a Level AA criterion that aims to make web content more accessible for people with disabilities by enabling user agents and assistive technologies to understand the purpose of input fields, like select boxes, collecting user information.

To comply with this guideline, you need to ensure that:

• the input field serves a purpose listed in the 'Input Purposes for User Interface Components' section of the WCAG 2.1 specification
• the content is created using web technologies that support identifying the expected meaning of the input field.

Some browsers attempt to aid the user by automatically filling form controls rather than having the user reenter their information each time. For example, a field asking for the user's telephone number can be automatically filled with the user's phone number.

1.3.1, 4.1.2: Use appropriate input types

Use the correct input type for the specific purpose of the text input, such as email, tel, password, or number. This helps with accessibility and provides appropriate input controls for different devices (WCAG, 2018).

1.4.1 Use of Colour

Use icons alongside error messages so that colour alone isn't used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element (WCAG, 2018).

1.4.3 Contrast (Minimum)

All border colours should be accessible and meet a 3:1 minimum colour contrast ratio to the background (WCAG, 2018).

2.1.1: Keyboard accessibility

Ensure that users can interact with the text input using keyboard controls. By default, text inputs should be accessible with the Tab key to focus and the Enter or Space keys to submit the form (if applicable) (WCAG, 2018).

1.3.1, 3.3.2: Indicate Required Fields

Clearly indicate required fields with an asterisk (*) or other visual indicators, and add the required attribute to the text input. Additionally, provide textual information, such as "(required)," for screen reader users (WCAG, 2018).

3.3.1, 3.3.3: Implement Accessible Error Messages

If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. (Level A).

When displaying error messages, ensure they're clear, concise, and accessible to all users. Use the 'aria-describedby' attribute to associate error messages with the corresponding input field (Level AA) (WCAG, 2018).

3.3.4 Error Prevention (Legal, Financial, Data)

For web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true: Reversible, Checked, Confirmed (Level AA) (WCAG, 2018).

3.3.2: Provide Clear Instructions

Ensure that any instructions or guidelines for filling out the text input are clear and easily understandable. This helps users avoid mistakes and better understand the expected input format. This is commonly seen in the form of hint text that appears below the labe (W3C 2019b).