Form Input Types
Use form patterns to capture user data in a consistent, optimized manner.
# Overview
Forms are the primary means of communication between users and a website or application. Consistent implementation of form patterns improves overall usability by creating a familiar interactions across digital experiences.
Forms allow users to:
- Sign up or sign in to an account
- Manage their preferences
- Select a product or adventure to purchase
- Enter personal information
- Provide feedback
Cedar provides components for the basic HTML input elements: CdrInput, CdrSelect, CdrCheckbox, and CdrRadio. Input groups that contain logically related form inputs or groups of radio or checkbox elements can be constructed using CdrFormGroup. These Cedar components provide built in labels, controls, and error state logic. Form controls can be constructed using the CdrButton or CdrLink components. Other components may be used to further enhance forms.
# Guidelines
- Ensure the entire field, including validation messaging, is in-view and unobstructed when a field is selected
- As each Cedar component may have specific accessibility or usage guidelines, it is recommended to check the documentation for any components you are using
- The CdrInput component sets some default attributes to help ensure a consistent experience, see the CdrInput documentation for more information
# Examples
- Don’t automatically opt-in users to email marketing offers
- Set
typeattribute to "email" - set autocomplete value to "email"
# Phone Number
- Explain why a phone number is required and/or how the data will be used
- If a phone number can be provided optionally, consider placing the input behind a link
- Provide a formatting hint to help the user input the correct format
- Add special characters automatically but also accommodate ones typed by the user
- Set
typeattribute to "tel" - Set
autocompleteattribute to "tel-national" if no country code is required - See the CdrInput documentation for information on setting up an input mask
# Name
- Use a single “Full name” field whenever possible as ”First name” and “Last name” fields are not culturally inclusive
- Consider giving the user the option of choosing a “Prefered name” to be used in instances of personalization (eg. marketing emails)
- If first and last names are required for payment validation, consider adding helper text clarifying the need to match the card and splitting the data on the back-end
- Avoid optionally asking for a middle name or initial
- Set
autocompleteattribute to "name" - Validate for at least two words if the full name is required for payment processing
# Address
- Place the secondary address field behind a link
- Be descriptive with what types of information a secondary address field might contain
- Use an address finder, if available
- Assign appropriate autocomplete value—note: “address-line1” vs. “address-level2”
# Postal Code
- To reduce typing effort and reduce errors, ask for the postal code before the City and State fields so they can be automatically populated
- Size the field to the data expected
- Invoke special “numeric” keyboard by passing
:numeric="true"to CdrInput - Dynamically change keyboard type depending on country selected—some countries may have letters in their postal code (eg. United Kingdom)
- Set
autocompleteattribute to "postal-code" if no country code is required - Use an
inputlistener to control the format of the input - Use the
maxlengthproperty to restrict input to the maximum expected length
# Credit Card Number
- Once identified, dynamically provide a thumbnail icon of the card type
- Use the field label “Card number” as charge cards and debit cards are accepted card types alongside credit cards
- The numerical spacing of the data should match the physical card
- Invoke special “numeric” keyboard by passing
:numeric="true"to CdrInput - Actively validate the card number field
- Auto-detect the card type based on the card number
- Once known, match the numerical sequence of the field to the physical card
- Ensure the user doesn’t need to re-enter their number if they go back a step in the checkout flow
- Assign appropriate autocomplete value: “cc-number”
- See the CdrInput documentation for information on setting up an input mask
# Security Code
- Provide a format hint based on card type
- Size the field to the data expected by using an
inputevent listener - Invoke special “numeric” keyboard by passing
:numeric="true"to CdrInput - Use an
inputlistener to limit input to possible values for the security code - Use the
maxlengthattribute to restrict input to the maximum possible length for the security code - Assign appropriate autocomplete value: “cc-csc”
- Dynamically update format hints based on card type
# Expiration Date
- Use the MM/YY format
- Size the field to the data that’s expected
- Invoke special “numeric” keyboard by passing
:numeric="true"to CdrInput - Assign appropriate autocomplete value: “cc-exp”
- See the CdrInput documentation for information on setting up an input mask
# Country
- Assign appropriate autocomplete value: “country”
# Gender
- Never ask for a user’s gender unless absolutely necessary
- Always provide a reason why the information is required and how it will be used
- Give the user the option to self-identify
- Consider adding an additional, optional field for users to further clarify their answer
- Size the field to the data expected
- Assign appropriate autocomplete value: “sex”