Forms

As we’ll see from the guidance below, a project team needs to collaborate extremely closely to create an accessible form that is logical, labelled correctly and consistent. And, an accessible form allows all our users, not just those with physical and cognitive impairments, to finish their task as quickly possible.

There are many different things to think about when designing and building a form, including the look and feel, content design and semantic structure.

Visual design

Key considerations are:

• Single-column layout
  Presenting fields in a single column keeps visual momentum moving down the page and means users don’t have to reorient themselves by moving back up to the next column. (Exceptions to this rule are short, logical fields that may be presented on the same row like date of birth).
• Minimise clutter
  This can improve usability and accessibility for those with visual and cognitive disabilities. GDS recommend that you start by putting one thing on the page and splitting the form across multiple pages, although this can be confusing for those with dementia so care must be taken and clear signposting provided.
• Context clues / signals
  Things like progress indicators are useful for people who might easily lose their place, such as those with dementia.
• Contrast between text and background colour
  Read more in our colours and colour contrast article.
• Clearly defined boundaries or outlines
  This lets people with cognitive disabilities know the size and location of the click target in the form field.
• Text area height
  The height of the text area should be proportional to the amount of text to be entered
• Clickable areas
  Clickable areas should be large, especially for smaller controls, such as radio buttons and check boxes. Adequate spacing between each element should be created, to ensure that clickable regions do not cross over.

A good way to review the form is to use a straw, or make a narrow window with your fist, and view the page through that, scanning vertically but not horizontally. This can help you discover if content is hidden from users using screen magnifiers

Labels

Each field in a form must have a descriptive text label that clearly describes the purpose of the field. The label tells people how to interact with the field and what information to enter. Make sure that the label for the field is visible and persistent. Labels must not disappear when a user interacts with the field.

For text fields and dropdowns, always position labels (and their descriptions) above or to the left of form fields. This positioning helps people understand which field the label relates to. This also helps reduce horizontal scrolling for people with low vision, as well as making viewing labels on mobile devices easier as the virtual keyboard can often hide labels that are below or at the side or form fields.

To increase the predictability and understandability of the form for everyone, labels for radios and checkboxes should be positioned to the right of the form field.

To be accessible, labels must be correctly associated with their corresponding form field in code, otherwise people using screen reading software may not understand which label relates to each form field.

<label for=”first-name”>First Name</label>
<input type=”text” id=”first-name”>

Descriptions (hints and guidance)

Sometimes we have to ask our users questions that are complicated or quite personal. It’s important in situations like these to provide clear explanations to guide them to the correct answer and reassure them. We can do this by using a description as well as a label to provide further information.

Descriptions often referred to as hints or guidance, should be persistent and placed outside of the form field. Generally, descriptions should be positioned below the label but above the form field, in a way that makes it clear what they refer to.

To make the descriptions as accessible as possible, they should be associated with their corresponding field in the code. You can do this by using the ‘aria-describedby’ attribute on the form field with a value that matches the ‘id’ attribute on the element containing the description. This association allows screen readers to announce the description to users after the label and other information is read out.

<label for=”loans”>Regular Loan Payments</label>
<p id=”description”>This is the total amount of money you have to repay every month.</p>
<input type=”text” id=”loans” aria-describedby=”description”>

Tooltips

Avoid using tooltips to provide additional information about form fields. Tooltips pop up when the keyboard focus or mouse pointer is on the form field. These types of tooltips cause issues for a variety of users, but are especially bad for those operating a screen magnifier. In this case, the tooltip obscures the field underneath and prevents the user from being able to complete it.

In general, if the information is important enough to be included in the form, it shouldn’t be hidden in a tooltip, instead it must be visible and persistent.

Think about using an approach such as NEL’s expander pattern for an accessible way of providing additional information about a form field. If you do have to utilise tooltips, check with a development team that they can be made accessible.

Placeholders

Placeholder text provides an example of the expected information format for form fields that have not been filled in by a user. Placeholder text is used to provide a hint or suggestion of what to enter in the field, rather than the type of information to enter.

For a first name field, the placeholder text could be “e.g. Kelly”.

<label for=”first-name”>First Name</label>
<input type=”text” id=”first-name” placeholder=”e.g. Kelly”>

Placeholder text is often incorrectly used in place of a label. It is not a replacement for a visible text label as it disappears when users start typing. Disappearing text strains users’ short-term memory especially if the form contains more than several fields, as it makes it harder to check for and fix errors. It also puts an additional burden on users with visual and cognitive impairments. Use placeholder text to provide examples for users, but ensure you always provide visible and persistent labels for each form field.

Grouping fields

Often, you’ll need to group related form fields under a common title, so they have sufficient context. To do this, use the <fieldset> element to create the group and provide a title for the group using the <legend> element.

You must always group radio buttons in this way as the context for the group comes only from the title of the group, and not the labels for each radio button. The group title helps everyone understand the purpose of the group of radio buttons.

<fieldset>
<legend>Do you have a Nationwide current account?</legend>
<label for=”radio-1”>Yes</label>
<input type=”radio” id=”radio-1” name=”account”>
<label for=”radio-2”>No</label>
<input type=”radio” id=”radio-2” name=”account”>
</fieldset>

The <legend> element acts like a heading within a form. To improve the way screen reader users navigate a form, it’s perfectly acceptable to use headings within legends. This is a useful technique as it prevents you from adding additional headings within a form.

<fieldset>
<legend><h2>Your Details</h2></legend>
<!-- individually labelled form fields -->
</fieldset>

Required / Optional Fields

Showing which fields are compulsory on a form is something welcomed by our users who are short on time and helps them avoid making mistakes. Form fields must be labelled correctly however, otherwise users will experience unnecessary errors that can lead to confusion.

Required / optional form fields must be clearly identified to show how they can be recognised (if relevant). Avoid using colour alone to show required form fields. Instead, if most form fields are required then state this at the beginning of the form, and include the word ‘optional’ in the label of any fields that are not required.

Custom Form Fields

Try to use native HTML form elements as much as possible because they come with accessibility built in and are much easier to support and maintain. Find out why Nationwide’s design system NEL uses native form elements.

If you must use custom form controls, you must ensure they work for everyone and do not create barriers to access. Test any custom interactions with people who use assistive technologies such as screen readers, screen magnifiers and speech recognition software to identify problem areas.

Validation and error messaging

• Provide highly visible and specific error states using multiple cues like colour, icons, bold font weight, heavy border or outline
• Keep error messages simple. A user should know what’s happened, what went wrong and be given a solution to fix it
• When displaying validation errors or success messages, don’t rely on making the field green or red because it’s not accessible to those with colour vision deficiency or screen readers. Wherever colour is used, try to also display text and/or icons to communicate a message to the user.
• Error messages must be associated with their form fields in the code. This can be done by adding the error text into the label element for the field, or by using aria-describedby

Session timeouts

Read more in our session timeouts article.