One of the most important types of interaction for clients using our products.

Don't just put together a form, design it.

Forms are crucial interaction patterns in our products, facilitating tasks such as registration, purchasing, and support. They should be designed thoughtfully to enhance user experience and efficiency.

• Organize inputs into related groups.
• Sequence inputs logically.
• Use single column layouts for simplicity.
• Implement multi-step forms for lengthy processes.
• Match field sizes to input types.
• Remove unnecessary fields.

• Facilitate user tasks like data entry, configuration, and transactions.
• Collect essential user information efficiently.

• Avoid using forms for simple interactions that can be handled with fewer inputs.
• Do not use forms when information can be gathered through alternative, less intrusive methods.

• Header: Clearly state the form's purpose.
• Labels: Use concise, descriptive text.
• Input Fields: Design to minimize user effort.
• Selection Controls: Use radio buttons, checkboxes, toggles, and dropdowns appropriately.
• Buttons: Prioritize placement from right to left.
• Links: Use for non-transactional actions.

• Focus: Automatically focus on the first input.
• Validation & Errors: Provide clear, consistent feedback.
• Keyboard Navigation: Ensure full keyboard accessibility.
• Order & Alignment: Align left and order logically.

• Avoid multiple fields for single data points.
• Prefer radio buttons over dropdowns when possible.
• Use conditional logic to streamline forms.
• Optimize for speed and responsiveness.

• Avoid placeholder text due to poor contrast and cognitive load.
• Implement accessible coding practices.
• Utilize WAI-ARIA guidelines for form elements.

• Checkboxes
• Radio Buttons
• Dropdowns
• Buttons
  By adhering to these guidelines, forms can be designed to enhance usability, accessibility, and overall user satisfaction.

Where appropriate, use HTML5 input types to ensure ease of use, particularly on touch devices. The email input type is especially useful in mobile browsers, but all types to consider include:

• email
• range
• search
• tel*
• url

*Note: On mobile devices, tel type puts the user into the number keypad rather than the regular keyboard. Use tel as the preferred type when coding a numbers-only input.

Use the following types with caution, as the implementation in some (or all) browsers may be confusing and vary dramatically in presentation:

• month
• color
• date
• datetime
• datetime-local
• time
• week

All major browsers support the number input, but display may vary. Because several browsers include some kind of spinner UI (up/down arrows to increment the input), some users may be confused by the type of field, while others are familiar with it. To mitigate this problem, you can use input attributes and browser-specific styling in your implementation, or consider an alternate input, such as tel.

Forms should generally be executed with input elements of type="submit". Use this tag rather than <input type="button">.

Attach all JavaScript triggers to form and field events, however, rather than click events of a button or link. The allows users to submit forms or tab through form fields with keys, within a touch device keyboard, or by other methods (especially those used by accessibility browsers); attaching events to form submits circumvents problems that may arise from any alternate input scenario.

In most cases, JavaScript validations are not necessary. Some situations may make client-side validation more useful to the user, however.

You may potentially want to use client-side validations when:

• the form is submitted via AJAX. Generally, this will make action flow more fluidly for the user.
• the form contains a file upload input. Because of security issues, uploaded files are detached on page load, which makes round-trip validation poor UX (as the user is forced to reattach the file). (Note that some browsers expose more attributes of uploaded files than others, making specific validations relating to file size, type, etc., inconsistent across browsers.)
• the form contains typeahead inputs that might be lost upon reload.
• moving from page to page in some kind of creation Wizard. Whether this pattern applies may depend on how the Wizard is implemented and dependencies between input fields from page to page.
• looking for specific patterns on fields such passwords, where the text is obscured from view.

While client-side validation is often an expedient and helpful pattern, consider certain drawbacks:

• Because resources may be much slower to load in mobile devices, users may begin filling out forms before JavaScript is applied to the form, leading to uncertain execution.
• Is the validation executed on submit or on field change? Users commonly skip or half-complete fields for many reasons while filling out a form, and preemptive errors can lead to frustration for the user.
• Browser autocomplete may act in unexpected ways, resulting in a false test outcomes.
• If a form is long (or a viewport too small), inputs may be out of view on form submit, requiring a scripting solution.
• As always, consider how JavaScript will interact with assistive technology devices and software; ensure the user gets a clear idea of what is happening by employing alert dialogs as described by WAI-ARIA best practices.

• Do not put the user in "double-jeopardy" if at all avoidable. This means the user should rarely see a second set of errors after satisfying errors shown before form submit.
• To avoid the above scenario, validate on form on submit rather than on input. However, a multistep input, such as typeahead field or password confirmation, may be validated on change for better interaction flow.
• Implement the same error styling to the elements as the user would see from a server-side validation.
• Clear errors on re-validation. Depending on the input type, as in the case of password field, it may be possible that clearing the error on field change may be more helpful to the user.