Building forms

• Only ask for absolutely necessary information
  • Respect the user’s privacy and GDPR regulations
  • Be sensitive for example about asking the user’s age or gender
  • Make sure you the service is allowed to collect and hold the data, for example about an underaged user.

• Follow a logical, predictable order (for example first name, last name).

• Group related tasks under section titles to provide more context and make the interface easier to scan.

• Provide clear, descriptive headlines, fieldset legends and labels to help the user easily scan and get the gist of the form.

• Divide long forms into smaller steps to make it easier to understand and validate.

• Enable autocompleting values to provide automated assistance in filling out form field values.

  • Provide an appropriate autocomplete attribute to fields.

• Pre-populate known values if possible to make filling the form easier.

  • The user should not be made to input the same information twice.

• Pre-populate known values if possible to make filling the form easier.

  • The user should not be made to input the same information twice.

• Use gender-neutral language.

  • When asking for gender, refer to the example in the gender-neutrality chapter .

• Adjust the width to reflect the intended length of the content.

  • Align the width to the responsive column grid.

  • If an input is too long to be fully displayed in the field, truncate the value with ellipsis.

• Always use a dedicated input type if it is available. E.g. use the phone number input for inputting phone numbers.

• Make sure users can enter their information even on smaller screen sizes and mobile devices.

• Related checkboxes and radio buttons must be grouped to a fieldset with a legend stating the selection being made made.

• All static forms must have a submit button.

  • When form controls are used to dynamically change content (for example filtering a dataset), submit button is not necessary.

  • The submit button must be the only primary action in a form.

• The submit button should be the last element of the form

  • All required fields and important information considering the form must be placed before the submit button.

  • For example: user is required to approve terms or conditions, or read “small print” before submitting the form.

• Keep it simple. Don't confuse the user by overcomplicating the form.

  • The number of secondary and supplementary actions in a form should be kept as few as possible.

  • Actions should be grouped together, to help the user understand all the actions available in the form at a glance.

  • Icons can be used to differentiate multiple actions.

• Prevent accidental loss of data when performing destructive actions. For example clearing all form fields.

  • The user should be asked to confirm the action (for example with a modal).

  • In multi-page forms the action should only be performed to the current page.

  • After clearing all form fields, the focus should be moved to the beginning of the form.

  • When performing non destructive actions, the user can be informed about the change made, for example with a toast notification.

• Supplementary actions should always have both text label and icon, to differentiate them from text links.

  • The Small button variant can be used for inline actions.

Adjust the size of the input field or selection to indicate the length of the preferred input or average option.

• All form components must have a text label.

  • The label can also be substituted with an action button added to the form control.

  • If an action button is used to substitute a label, it must have a text label, not just an icon.

  • An exception is made in the HDS navigation search component which follows a widely used pattern.

• The label must be always visible to the user.

• Be descriptive.

  • The user must be able to understand the purpose of the form control from the label only.

• Keep it short.

  • Preferably use less than five words.

  • If the user needs more information for filling the information, it should be provided with assistive text or tooltip.

• aria-required="true" attribute must be always provided for required fields

  , even if they are not marked visually.

• If your form has at least one required field, explain the asterisk before the form. E.g. "All fields marked with * are required".

• If all fields in the form are required

  • This should be stated in the form-wide instructions at the beginning of the form.

  • The submit button can also be disabled before all fields are filled.

• Be descriptive.

  • Choose an icon that clearly describes the type fo input or purpose of the form control.
  • Do not use arbitrary or vague icons just for visual purposes.

• See HDS icon guidelines for more information about using and choosing icons.

• Disabled form controls can also be hidden from view but in most situations all fields – even the disabled ones – should be shown to the user.

  • Showing all fields makes easier or the user to understand all the possible actions in the form.
  • Previously hidden fields suddenly appearing into a form can confuse the user.

• As a rule of thumb, a disabled field should only be hidden, if the user

  • is not provided with a way to activate the field,
  • does not have the permission to change the fields value

Help the user by minimising unnecessary and redundant work needed for filling the form. Especially long forms can become tedious to fill, especially, if the same information must be entered multiple times.

• Provide a pre-selected default option if some option is known to be the most commonly used.

• Pre-populate known values if data is available.

  • The user should not be made to input the same information twice.

• Enable autocompleting input to assist users filling forms by pre-filling field values based on earlier user input (for example the user’s address).

  • The appropriate input purpose should be defined with autocomplete attribute where applicable.

  • The autocomplete attribute hints the browser that the field can be autocompleted, and the type of information required.

  • See more about

    input purpose terms used for autocomplete

    .

• If the form has a main heading, it must be the first element

  • The main heading should preferably be h1 element, even if visually styled as a smaller level heading.

• The the sub-heading should placed right after the main heading, and preferably be a h2 element.

• Keep it short and descriptive!

  • Main heading should be less than five words.

  • Sub-heading should be less than two to three sentences.

• The instructions should be placed after the heading and sub-heading, before the first form control or fieldeset.

• The inline notification component can be used for form-wide instructions if they contain something out of the ordinary.

• If your form has at least one required field, explain the asterisk before the form. E.g. "All fields marked with * are required".

• Keep it short and clear.

  • The user should be able to provide the right input based on the label and assistive text alone.

  • Assistive text should not be longer than the form control and more than two rows.

  • The assistive text should only be used for essential information. Avoid causing unnecessary cognitive overload for the user by giving too much information.

• Be clear and concise.

  • Although tooltips can provide more information than the assistive text, they should preferably be less than two or three sentences long.

• Provide a link to a separate page, if more detailed information is available.

  • Always open links from tooltips to a new window, so that the process of filling the form is not interrupted.

• Write placeholder text in a way that it can immediately be recognised as not being an actual value.

  • Format examples should be generic rather than real values. If the placeholder seems like an actual value, the user can mistake the field to be already filled.

  • Values examples should preferably start in a way that clearly indicates it is a placeholder. For example: Full name: “E.g. John Doe”, (in Finnish Koko nimi: “Esim. Matti Meikäläinen”)

  • Leave the placeholder empty if an example value that would be generic enough to be recognised as placeholder can’t be found.

  • Screen readers do not differentiate if the element is a placeholder or an actual value. Even though assistive technology users are usually accustomed to this, it can possibly cause confusion.

Prefer single column vertical layout over multi-column layout.

• Stacking form controls vertically to form a "F-shaped" reading path through the form takes more space but makes the users path from control to control smoother.

• If the user has to jump between more than one columns, the structure of the form, and reading path can become hard to follow.

Fields combining several inputs together with a fieldset, can be placed next to each other.

Group form-wide action buttons together. Best practice is to place action buttons at the end of the form, aligned to left and ordered by importance.

1. Submit (primary action)
2. Secondary actions

Align supplementary action buttons related to singe form control or fieldset after or bellow the control

Use spacing tokens for grouping form controls with proximity and separation

• Use smaller spacing between controls that belong together and larger spacing between groups of controls

Align form controls to column grid.

Adjust field width according to preferred input.

• Use the proper heading level: If the form heading is h1, the segment headings must be h2.

• The segment heading should describe how the form controls are related to each other and to the form as a whole

  • For example “Personal information” or “Payment information”.

• A set of radio buttons or checkboxes must be grouped together with a fieldset.

• Divide the form in approximately even sized steps
  • Show one theme per page. For example Contact information – payment information – selected options etc.
  • Give each step a short, descriptive heading with a h1 element.
• List all the steps needed to complete the form in a separate form navigation
  • Show the heading of each step in the navigation
  • Show the form navigation through the filling process.
• Show the user their progress page by page as they fill the form
  • Let the user navigate back to previous steps
  • Disable next steps before all previous steps have been filled (and validated)
• Validate the data after each step and let the user fix errors before proceeding to the next step

  • The user should only be allowed to proceed to next steps by clicking the "Next step" action button, to ensure the data is validated.

  • If the user navigates back to a previously filled step and changes any input value, the following steps should be disabled in the form navigation.

• Check the order in which individual controls in the form receive focus

  • By default the focus order follows the DOM order, so in most cases checking that the controls are in the right order in the DOM tree is sufficient.

  • If the focus order needs to deviate from DOM order, it can be customised with tabindex attributes.

• Pay special attention to focus order when dynamically changing page content, adding or removing form controls, or clearing values

  • As a rule of thumb, the change should be made downstream in the focus order, not upstream, so the user can find the change by navigating forward.

  • New content should be added after the current focus point.

  • When current focus point is removed, focus should return to the last heading or legend of the fieldset.

  • Focus must not leave the form when the content is dynamically changed.

• In multi page forms, when the user proceeds to the next or previous page, focus should be directed to the heading of the form or current form step, instead of the beginning of the entire page. This helps the user to keep focus on the task at hand.

• tabindex="-1" can defined for the heading, fieldset legend or other element where the focus should be directed after a dynamic content change or page change.

  • Not necessary in forms embedded into content. In these cases focus can start from page heading and follow the DOM order.