Forms are a container for interactive controls used to submit information.
While their content may get complicated, our forms are designed to present a hierarchy that is straightforward to implement as well as use. Most forms will utilize a header, some amount of field sets (each containing fields or form controls), actions, and an optional footer.
In most cases, the form header will only include the form title. The title should succinctly describe the purpose of the form.
Field sets are used to group related form controls. When grouping fields, be sure to include a <legend> to both contextualize how the fields are related and ensure a clear hierarchy.
The form below utilizes two field sets, "General Info" and "Authentication Settings", each containing multiple fields.
Though each field type may have its own set of guidelines, their general anatomy is similar. Every field should have an accompanying label - or legend for radio or checkbox groups.
Fields should also include various error messages for possible invalid states. Error messages should be associated with their field via the aria-describedby attribute.
Fields may utilize field hints to provide context, formatting help, or other guidelines to the user. Do not use the placeholder attribute for these purposes (see why below). Hints should be associated with their input via the aria-describedby attribute.
Field hints remain in place when an error message is displayed. In these cases, both messages should be associated with the input via aria-describedby:
For more details about when and how to use different field types, please refer to their individual documentation.
All forms should include an actions section that contains a button for submitting data. This section may also include secondary actions such as "Reset".
Button labels should clearly indicate what action the user is taking, e.g. "Add User" instead of "Submit".
This section is automatically hidden when forms are in a read-only state.
This optional section may contain form meta-data, support links, or "legalese" copy.
Some forms require a read-only state. This can be achieved by adding the data-readonly attribute on your <form> and readonly on your <input>s. When in a read-only states, forms will automatically hide the actions section.
Users who utilize their browser's auto-translation feature will still see placeholder text in its untranslated state. In order to prevent triggering a change in page layout or logic, browsers skip over translating certain attributes, placeholder included.
Placeholder text disappears when a field is interacted with. For this reason, it's not suitable for formatting guidelines or necessary context.
Placeholder content is limited to static text. Additionally, placeholder text is truncated beyond the width of its input.
Field value confusion
Low-contrast placeholder styling may be illegible for some users; however, there's evidence to suggest that placeholders with compliant contrast can be mistaken for field values.
Users who turn on High Contrast Mode (or its equivalent) will see placeholder text at the same contrast level as the input's value, making them even harder to distinguish.
Regardless of styling, users with low digital literacy may not understand the purpose or behavior of placeholder text.