x

Brand standards

x
Menu

Forms and buttons

Building and styling forms to the Peel Region's brand and standards.

User instructions

Instructions that apply to the entire form should be placed before the <form> element to ensure that users are aware of the requirements before they begin. In-line instructions should be placed throughout the form within the label of the form control.

Instructions should always use active voice, not passive. When structuring sentences place the subject before the verb (action word). For example:

  • Instead of: "Proof of income must be provided for each business."
  • Use: "Each business must provide proof of income."

Write in first and second-person point of view. Use "we" and "you" whenever possible. For example:

  • Instead of: "The applicant should check for accuracy."
  • Use: "You should check for accuracy."

Don't use "please" in form instructions or error messages.

Download

Writing digital content

Required vs. optional fields

  • All fields should be considered required unless labelled as optional.
  • Do not indicate required fields (by using asterisks or any other method).
  • Include the word "optional" in parenthesis at the end and as part of the label text.

Demographic fields

Do not ask the folowing demographic questions: sex assigned at birth, gender identity, cultural background, language, religion, immigration status, disability, age, education level, employment status, family status, household income, housing status, etc. unless this data is essential for the service to be performed (e.g. a medical form).

Make all form entires undoable

As we don't use theResetbutton, it becomes essential to offer users another escape route for erroneous form entries. In the case of text fields or check boxes, the user can always erase the entry and revert to the original state.

When using radio buttons and drop-down lists, we must provide users a [default] option that is which results in nothing, especially if it's not a required either/or question.

Elements

Fieldset

Include: this is a group related fields arranged into logical blocks or sets. A legend tag is a caption for the fieldset.

Placeholder text

Avoid: placeholder text is not a replacement for labels. Even though it elimintes visual clutter, it may cause many usability problems.

Field labels

Provide labels to identify all form controls, including text fields, checkboxes, radio buttons, and drop-down menus. In most cases, this is done by using the <label> element. This element explicitly associates a form control with a label.

Standard fields

These fields are common controls on most forms. Where applicable, formats and validation rules are noted. These should be written exactly ash shows, including capitalization.

Field label

 Validation Comment
First name   Enter first and last name separately unless application requires a combined name.
Last name    
Email Validate for proper email format Do not label as "address"
Phone number 10 digits Allow user to enter an unformatted number (i.e., 9995551111) and automatically format as either (999) 555-1111 or 999-555-1111.
Address   Use an API to auto-complete and format address where possible.
Street    
City    
Province 2 letters Drop-down list of standard values
Postal code 7 characters including space
(A1A 1A1)		 Allow user to enter unformatted postal code with or without space and automatically format. Auto format upper- or lower-case entries.
Country    
Unit or apt.   Optional
Date 8 digits in YYYY-MM-DD format
(2023-03-15)

Use date picker calendar. Ensure the control is accessible on mobile when using a keyboard only.
Date of birth 8 digits in YYYY-MM-DD format
(2023-03-15)

Better to allow direct date entry as date pickers typically do not allow easy entry of dates far in the past.
Accessibility accommodations Text area Optional. May be required for services delivered in-person

Mobile keyboard for input types

These are subject to change and are easily be controlled with CSS.

Field type

Keyboard

Input type (example)

Text

Regular

 <input type="text" id="last_name" name="last_name" value="">

Credit card

Numeric

 <input type="text" id="x_card_num" maxlength="16" name="x_card_num" pattern="[0-9]*" value="" autocomplete="cc-number">

Email

Email

 <input autocomplete="email" name="email" id="email" type="email" value="">

Phone

Numeric

 <input autocomplete="tel" name="phone_number" id="phone_number" type="tel" value="">

Canadian postal code

Regular

<input type="text" id="postal" maxlength="7" name="postal" pattern="[A-Za-z][0-9][A-Za-z] [0-9][A-Za-z][0-9]" value="" autocomplete="postal">

Date

Date picker (regular)

Use a date picker. Depending on the use for date, limit the years. For example, if the event is happening in the future, do not show past dates.

Error handling

Validation error messages

  • Display an error message when a user enters data that does not meet the allowed values or validation criteria on that field.
  • Display an error message to identify required fields that were not completed.
  • Validation should be inline: that is, as soon as the user has finished filling in a field, an indicator should appear nearby if the field contains an error. Don't validate fields before input is complete (e.g. onblur form validation).
  • Error messages should be displayed in red. An icon to the left of the error message or validation summary will draw attention to the error and help users who are colour blind.
  • Error messages should be easy to understand and should provide simple instructions on how they can be resolved.

Common validation error messages

These should be written exactly ash shows, including capitalization.

Scenario

Error message
Required field not completed [Field label] is required.
Acknowledgement or consent checkbox not checked You must accept the terms and conditions to continue.
You must check the box to continue.
Entry is too long This number is too long. Enter up to XX digits.
This entry is too long. Enter up to XX characters.
Incorrect email format Enter a valid email address.
Incorrect phone number Enter a valid phone number.
Incorrect date format Enter date in YYYY/MM/DD format.
Two field values don't match Both [field label] should match.
Radio box not selected Choose an option that applies to you.
Checkbox not selected Choose at least one option that applies to you.

Submission button

There should only be one primary button in the area such as "submit" or "next." Other buttons should be styled as an alternate.

Do not use a reset button. It can hurt and hinder users in several ways:

  • Users may click the reset button by mistake instead of submit, resulting in all their work being removed.
  • Having multiple buttons increase clutter to the interface and makes it harder for the user to identify their next step

input[type=button], button{
  padding: 8px 10px;
  border: 1px solid transparent;
  background: #036;
  cursor: pointer;
  font-weight: 600;
  color: #FFF !important;
  display: inline-block;
  width: auto;
  margin: 0;
  transition: all ease .1s;
  min-height: 40px;
  top: 1px;
  margin-bottom: 1px;
  position: relative;
  box-sizing: border-box;
  border-radius: 5px;
  text-decoration: none !important;
}

input[type=button]:hover, input[type=button]:focus, button:hover, button:focus{
  background: #FFF !important;
  color: #054d84 !important;
  border-color: #054d84;
}

Alternate button style

The following example demonstrates the second button which has a CSS selector named "hollow" attached to it:

input[type=submit].hollow,
input[type=reset].hollow,
input[type=button].hollow,
button.hollow{
  background: none;
  color: #054d84 !important;
}

input[type=submit].hollow:hover,
input[type=button].hollow:hover,
input[type=reset].hollow:hover,
input[type=submit].hollow:focus,
input[type=button].hollow:focus,
input[type=reset].hollow:focus,
button.hollow:hover,
button.hollow:focus {
background:#036 !important;
  color: #FFF !important;
}