Text box and text area

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.

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.

For more information on our input text field design can be found in our forms component.

Classes

Accessible form requirements

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

General guidelines

Autofocus the first field by default. This allows users to tab through elements in the form in a logical way (Atlassian, n.d).
<input type="text" id="name" name="name" autofocus>

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.

WCAG Guideline 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).