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.

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
• Headings
  Designing a logical flow of headings that breaks content into sections improves the readability of a form’s content
• 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 let’s 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 and form fields

• Descriptive labels
  Make sure all form fields have descriptive labels that stay visible even after the field has been filled in
• Disappearing text
  Don’t use placeholder text inside form fields, or text that disappears when it is interacted with. Disappearing text strains users’ short-term memory especially if the form contains more than a dozen fields, and makes it harder to check for and fix errors. It also puts an additional burden on users with visual and cognitive impairments.

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.

Key considerations are:

• Hints and guidance should be persistent and placed outside of the field
• Should usually sit above the form field
• Any text should be readable by screen readers

Tooltips

Avoid using tooltips which pop-up when the focus or hover is on the form field. These 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, it shouldn’t be hidden.

If you do have to utilise tool tips, check with your development team that they can be made accessible.

Errors and error handling

• 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

Required / optional fields

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

Key considerations:

• Required / optional form fields must be clearly identified with a key to show how they can be recognised (if relevant)
• Avoid colours to show required form fields. If the majority of 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.
  Alternatives to this where there is a mix of required and optional fields include using an asterix (ensuring that the key shows what the asterix means), and including the word ‘required’ in the label.

Session timeouts

Read more in our session timeouts article.

<h2Code

• Try to use HTML form elements as much as possible, and test any custom interactions for use with screen readers and keyboard only
• Avoid automatically moving the focus based on a user’s keyboard input. E.g. In a date of birth field don’t automatically move the focus to the month field when the user adds 2 numbers in the day field – the user must move the focus themselves