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:

  • You can’t reasonably predict a user’s answer to a prompt and there might be wide variability in users’ answers.
  • Another type of input would make answering more difficult. For example, dates are easier to type in than they are to select from a calendar picker.
  • Users might want to be able to copy-and-paste in a response.

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.

Placeholder Text

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

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.

Grouping Inputs into Forms

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:

  • Email
  • Web Address
  • Search
  • Number (spinboxes, sliders)


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.

Do's and Don'ts



Common Button Labels and Usage

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,, for further information regarding call-to-action labels and usage.

Button Label:
Corresponding Action:
Add to Cart
Sign In/Sign Out
View Details
Learn More
Takes users to Cart page, with item added
Used for search buttons
Takes users back to entry point for a task
Used to save an item
Navigates users to change an item
Deletes an item on the page, usually with a verification step
Used as progression
Used as forward and backward navigation (Next is primary, Previous is secondary)
Used to submit a task or info
Used for choosing items in a task flow
Authentication standard, for consistency do not use Log In/Log Out or Signin/Signout
Used instead of “Select” in cases of product details or within learn content
For use in modal verification steps when more specific CTAs will not fit due to space
Used to link users to more learning content or contextual help
Used within modal windows

Individual Inputs

Text Input

<div class="dds__form-group"> <label for="firstnameInput-validation">First Name</label> <input type="text" class="dds__form-control" id="firstnameInput-validation" required="" aria-invalid="false" aria-describedby=""> <div class="dds__invalid-feedback" id="firstnameInput-validationFeedback"> Please enter your first name. </div> </div>

Text Input Disabled

<div class="dds__form-group"> <label for="disabledTextInput">Second Choice</label> <input type="text" id="disabledTextInput" class="dds__form-control" disabled=""> </div>

Text Input Read-Only

<label for="readonlyTextInput">Case Number</label> <input type="text" id="readonlyTextInput" class="dds__form-control" value="9876543" readonly="">

Text Area

<div class="dds__form-group"> <label for="exampleFormControlTextarea1">Please provide details about your request</label> <textarea class="dds__form-control" id="exampleFormControlTextarea1" rows="3"></textarea> </div>

Email Address

<div class="dds__form-group"> <label for="email">Email</label> <input type="email" class="dds__form-control" maxlength="256" name="email" id="email"> </div>


<div class="dds__form-group"> <label for="password">Password</label> <input type="password" class="dds__form-control" maxlength="256" name="password" id="password" aria-describedby="PasswordHelpBlock"> <small id="PasswordHelpBlock" class="dds__form-text text-muted">Must be 8-20 characters, contain letters and numbers, and no spaces or special characters.</small> <div class="dds__form-check"> <label class="dds__form-check-label" for="checkboxPassword"> <input type="checkbox" id="checkboxPassword" name="checkboxPassword" class="dds__form-check-input"> <span>Show Password</span> </label> </div>

Phone Number

<div class="dds__form-group"> <label for="name-3">Phone Number</label> <input type="text" class="dds__form-control" placeholder="(e.g. 555-123-4567)" maxlength="256" name="name-3" id="name-3">

Form (Input Group)

Form with Errors

<form class="dds__needs-validation dds__was-validated" novalidate=""> <div class="dds__form-group"> <label for="emailInput-validation">Email</label> <input type="email" class="dds__form-control" maxlength="256" name="email" id="emailInput-validation" required="" aria-invalid="true" aria-describedby="emailInput-validationFeedback"> <div class="dds__invalid-feedback" id="emailInput-validationFeedback"> Please enter your email. </div> </div> <div class="dds__form-row"> <div class="dds__col-md-4 dds__mb-3"> <label for="firstnameInput-validation">First Name</label> <input type="text" class="dds__form-control" id="firstnameInput-validation" required="" aria-invalid="true" aria-describedby="firstnameInput-validationFeedback"> <div class="dds__invalid-feedback" id="firstnameInput-validationFeedback"> Please enter your first name. </div> </div> <div class="dds__col-md-4 dds__mb-3"> <label for="lastnameInput-validation">Last Name</label> <input type="text" class="dds__form-control" id="lastnameInput-validation" required="" aria-invalid="true" aria-describedby="lastnameInput-validationFeedback"> <div class="dds__invalid-feedback" id="lastnameInput-validationFeedback"> Please enter your last name. </div> </div> <div class="dds__col-md-4 dds__mb-3"> <label for="usernameInput-validation">User Name</label> <input type="text" class="dds__form-control" id="usernameInput-validation" required="" aria-invalid="true" aria-describedby="usernameInput-validationFeedback"> <div class="dds__invalid-feedback" id="usernameInput-validationFeedback"> Please choose a username. </div> </div> </div> <div class="dds__form-row"> <div class="dds__col-md-6 dds__mb-3"> <label for="cityInput-validation">City</label> <input type="text" class="dds__form-control" id="cityInput-validation" required="" aria-invalid="true" aria-describedby="cityInput-validationFeedback"> <div class="dds__invalid-feedback" id="cityInput-validationFeedback"> Please provide a valid city. </div> </div> <div class="dds__col-md-3 dds__mb-3"> <label for="stateInput-validation">State</label> <input type="text" class="dds__form-control" id="stateInput-validation" required="" aria-invalid="true" aria-describedby="stateInput-validationFeedback"> <div class="dds__invalid-feedback" id="stateInput-validationFeedback"> Please provide a valid state. </div> </div> <div class="dds__col-md-3 dds__mb-3"> <label for="zipcodeInput-validation">Zip</label> <input type="text" class="dds__form-control" id="zipcodeInput-validation" required="" pattern="^[0-9]{5}(?:-9]{4})?$" aria-invalid="true" aria-describedby="zipcodeInput-validationFeedback"> <div class="dds__invalid-feedback" id="zipcodeInput-validationFeedback"> Please provide a valid zip. </div> </div> </div> <button class="dds__btn dds__btn-primary" type="submit" aria-invalid="false" aria-describedby="">Submit form</button>

No items found.

No items found.


Text input

Text input redlines


Textarea redlines


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.

  • NOTE: As of this writing, VoiceOver on iOS does not support fieldset and legend for forms. You can address this by using aria-labelledby="for-attribute-of-label id-of-legend id-of-additional-info" on each input in the fieldset. Using aria-labelledby will overwrite the default text read by the screen reader, so it is important to include all relevant information.
  • NOTE: As of this writing, VoiceOver on OS X does not support aria-describedby. Use aria-labelledby instead, and include all related fields, including, labels, legend, and hint text.

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 a text input is pre-populated with placeholder text, it becomes more likely that the user will think that the system has already supplied the expected response, and skip over it.
  • Placeholder text is “grayed out”, which can make it difficult to perceive the text, especially if it doesn’t meet contrast requirements.
  • If placeholder text disappears when focus is set on the input, it can be difficult for users to recall what information they're supposed to supply.
  • If the placeholder text remains until the user clears it (backspace, or highlight + delete), it can still cause confusion because the clearing action may not be obvious.

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.

Why is this Important?

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.

Related Resources

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)