A user input element that allows for the exchange of information between the user and a form owner.
A text input or text area should be used when:
The length of the text input provides a hint to users as to how much text to write. Don't require users to write paragraphs of text into a single-line input, and use a shorter input to reinforce the length of a postal code.
Only show error validation after a user has finished interacting with an input. For example, after the field loses focus, the user presses Enter on the keyboard, or clicks a Submit button.
Avoid breaking numbers with distinct sections (such as phone numbers, Social Security Numbers, or credit card numbers) into separate input fields. For example, use one input for a phone number and not three (one for area code, one for local code, and one for number). Each field needs to be labeled for a screen reader and the labels for fields would be broken into segments that are not meaningful.
The correct placement for an input's label is above the input and left-aligned.
Display input labels that are clear and concise, although on smaller breakpoints labels can wrap.
Input labels should default to Title Case so long as the label is short, or when the input itself also uses Title Case. Use sentence case if the label reads like a complete sentence.
Inputs that are optional must be labeled as optional. The recommended method is to append " (Optional)" to the end of the input label.
Do not use an asterisk * to indicate required inputs because screen readers are inconsistent in the way that they read them.
An error prevention pattern that's used to offer clues about the data format expected within an input.
Avoid using placeholder text that serves as an input label or instruction. If placeholder text is no longer visible after users click into a field, users will no longer have that text available when they need to review their entries for accuracy. People who have cognitive or visual disabilities have additional problems with placeholder text.
Contextual help may appear immediately beneath an input as a line of text or a tooltip.
Provides instruction so that users can complete a form without error.
Try not to exceed 8-10 words.
Remove all non-required inputs in order to increase the completion rate of forms.
Alternatively, a form can reveal additional inputs when a prerequisite input is completed.
Use HTML 5 standards, so that mobile devices can benefit from improved features, for the following inputs:
A form validation checks user input against success criteria before passing the data to the server.
If there's at least one error, then a notification is displayed at top of page, below the page title, and it includes a list of anchor links to input-level errors. See Notifications for more details.
Title case, 2-3 words maximum.
Do not combine actions in a label (exception: "Customize & Buy").
If standard labels don't fit the button's purpose, align label with the task the user is attempting.
Please refer to the Dell Technologies branding website, https://brand.delltechnologies.com/faq/#voice, for further information regarding call-to-action labels and usage.
Organize forms into logical groups.
Keep tab navigation order in mind as well as the sequence in which inputs will be read by a screen reader.
Keep your form blocks in a vertical pattern. This approach is ideal because limited vision makes it hard to scan from right to left.
Display form controls in the same order in HTML as they appear on screen. Don’t use CSS to rearrange the form controls. Screen readers narrate forms in the order they appear in the HTML.
Use the <fieldset> tag to identify related elements in a group. Nested fieldsets should generally be avoided.
Use the <legend> tag as a caption for the fieldset, which announces its purpose. In screen readers, the legend text is generally read for each control in the fieldset, so the legend text should be brief and descriptive.
Use the <label> tag as a descriptive label for an <input> element, which enables toggle control in association with the text for that element (e.g. the user can select a radio button by clicking on the associated text). This is useful to some with motor disabilities.
Matching for="name" and id="name" values associate the label with the appropriate form control.
Because id must be unique on each page, only one label can be associated to each unique form element. This means you cannot have one label for multiple form elements. Additionally, screen readers do not support multiple labels that are associated to the same form element.
Do not use an asterisk * to indicate required inputs because screen readers are inconsistent in the way that they read them, and those with poor vision are sometimes unable to discern them.
For text inputs, the autocomplete attribute should be in place to let the user know what kind of data is expected to be entered. The attribute provides metadata to let the user know the intent of the input. It also provides autofill capabilities so previous entries can populate a form.
Use placeholder text sparingly because it can create many accessibility issues:
If the aria-multiline attribute is true, the input accepts line breaks (e.g. a Text Area). Otherwise, it's a simple text box. The intended use is for languages that do not have a text input element, or cases in which an element with different semantics is repurposed as a text field.
In most implementations, the default behavior of the ENTER or RETURN key is different between a single-line input and a multi-line text area. When a single-line <input type="text"> input has focus, the keystroke should submit the form. When a multi-line <textarea> input has focus, the keystroke inserts a line break. The WAI-ARIA textbox role differentiates these types of boxes with the aria-multiline attribute.
Maintain a touch target of 34 pixels in height to allow for easy touchscreen interaction.
Error messages should be easy to understand and clarify how to resolve each error.
Forms should not be subject to a time limit, unless its contextual to an auction or other live event.
Allow users to complete a form at their own pace, or provide a method for them to periodically extend the time limit.
People with cognitive disabilities can better understand the form and how to complete it thanks to improvements in the layout structure, instructions, and feedback.
People using speech input can use the labels via voice commands to activate controls and move the focus to the required inputs.
People with limited dexterity benefit from large clickable areas that include the labels, such as radio buttons and checkboxes.
People using screen readers can identify and understand inputs more easily because they are associated with labels, field sets, and other structural elements.
1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)
2.4.6 Headings and Labels: Headings and labels describe topic or purpose. (Level AA)
3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A)
4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)