Design simple forms with sensible grouping and clearly labelled elements

Techniques

Ask only for the information you require

• Completing forms requires significant cognitive load. Users get tired quickly when filling in information, which can lead to errors, mis-information or very basic responses.
• If your form has a mix of optional and mandatory information each question must be marked accordingly, adding to the cognitive load.

Tip: check your form for any optional questions – do you really need to ask this information at this point or could you collect it later?

Make sure it is obvious which fields are required

• Use the ‘aria-required’ attribute to denote required fields. You can also use the HTML ‘required’ attribute, however note that in some browsers, any empty fields with this attribute may prevent form submission, so your validation may not happen and your error messages may not be triggered.
• Do not simply use a red asterisk next to the form label to denote a required field:
  • an asterisk will be announced to screen readers as “asterisk”;
  • an asterisk will need to be defined somewhere on each page, close to the form – if your form is long this key may not be obvious.

Tip: rather than specifying required fields visually, consider a) informing the users that most questions are required, and b) specifying optional fields instead, using a text suffix to the question, for example, ”Title (optional)”.

Create a clear path through the form

• Use a single-column layout; avoid multi-column layouts unless absolutely necessary;
• Large groups of radio buttons and checkboxes can appear in two or three columns to make better use of the screen real estate but be aware that these will have to appear in a single column at mobile breakpoints so ensure you do not have too many options in one question, if possible;

Make your form is accessible by keyboard alone

• Provide alternative input options for complex form elements, such as allowing direct text input for date entry so users do not have to use a complex date picker.

Make sure ALL form elements have a label – this is non-negotiable!

• Every single or multiline text box, drop down list, radio button and checkbox must have a label. This is so assistive technology, such as screen readers, can tell users what they need to input into or select from the form fields they are presented with. Without a label, it is not possible to accurately complete a form;
• All form labels must be clear, succinct, sensible and unambiguous. Use simple language and be direct in what you are asking users to input or select;
• Make labels unambiguous. For radio buttons and checkboxes, try to make the label text self-explanatory, for example, 'Yes, I have read the terms and conditions' rather than just 'Yes'.
• Never use a ‘placeholder’ as the only form label. While they are recognised by some screen readers they are not a substitute for a label and, critically, once a field has been typed into the placeholder is no longer visible.
  • Users with memory problems such as dementia, and users with cognitive disabilities rely on permanently visible labels to remember what each field is asking of them. Relying on placeholder text makes checking the form for errors very difficult for users.
  • Default placeholder styles also frequently fail contrast ratio guidelines;
• If an input does not have a visible label because its expected input is obvious from the design, layout or proximity to other similar input fields – such as a search box, where the label is implied by the ‘Search’ text on the corresponding button – you must still include a label, although it is acceptable to hide it visually. You will need to inform your development team about the need, and required text for this label.
  • Note: users who are less digitally literate, or who have cognitive impairments may not be able to determine the purpose of an input field from its associated iconography alone, so a visible label is always recommended. Visible labels allow users who use voice input to navigate, to interact with form elements more easily.

Place labels above input fields and to the right of radio buttons and checkboxes

• Labels should be explicitly associated with their form fields to avoid ambiguity;
• Placing labels above input fields reduces the need to rework the page structure at lower breakpoints;
• Positioning labels above input fields also reduces scanning time and improves accuracy.

Always use the most appropriate form element for the question

• If it requires a few, free-text words, such as a name or street, use a text input box;
• If it requires selecting any number of options from a pre-defined list, use checkboxes;
• If it requires selecting a single option from a pre-defined list:
  • use radio buttons if you have fewer than 7 or 8 options;
  • use a dropdown if you have a large number of options, or if the default option is the recommended one.

Keep forms short and break them into manageable sections

• Be succinct – only ask for the information you need. A good way to test for this is to see how many ‘optional’ questions you have included. If any questions are optional then you should consider removing them;
• Split long forms into logically separate pages and allow users to move freely between pages;
• Indicate users’ progress through the form – for example, Step 2 of 4 – and allow them to navigate back and forth between pages;
• Make sure each section has an accurate and accessible name.
• If using a fieldset, make use of the <legend> element; otherwise, use a heading.

Group similar items together and order questions logically

Often there will be a number of input fields in a form that relate to each other, such as name and title fields or address fields – make sure you group these questions together. Groups of questions should then be coded in a way that is accessible to screen readers.

• Group form elements that belong together, for example, title, first name, last name, preferably with a <fieldset> element;
• Use a <legend> element to provide the title for a <fieldset>
• Use CSS to style the <fieldset> and <legend> items appropriately – you can remove all styling from these elements if necessary, however it will help users understand the nature of question blocks if you do communicate their grouping visually.
• If you have a lot of options in a dropdown you can also arrange these into groups with titles, using <optgroup>, to make them easier to read.
• Nested fieldsets can become complex to convey to users. If your form has several nested fieldsets, consider breaking your form up using headings instead (of the outer fieldset) or splitting your form over more than one page.

Alternatively, you can use ARIA to group from items. You should liaise with your development team to establish the most suitable approach.

Do not add a “Reset” button to your form

Reset buttons are almost never necessary and carry a very high risk as they can easily be selected by mistake.

Do not automatically advance the cursor to the next field when the preceding field has been completed

Automatically moving the focus to the next field can confuse screen reader users as they will naturally tab to the next field themselves – changing focus will most likely result in screen reader users missing form fields, causing errors.

This approach is often seen where a number or reference is made of several numbers or characters, for example, a bank sort code; a gift voucher with a long number, split into groups of four digits.

Do not submit a form or move to the next page unless the user has specifically performed that action

Only a button or link at the end of the page should move the user through the form. Do not use selections in dropdowns, radio buttons or checkboxes to advance forms or pages automatically.

Remember, this is a cross-team effort

• Labels must be associated with their respective form element – that, along with appending any help text to labels and coding the grouping of form elements, should be handled by your development team;
• Instructions and help text are key to users being able to successfully complete forms – your content producers may be able to help with instructions and text that helps user recover from errors.

Examples of good and bad form design

Table 1 - What to and what not to do when designing forms

References

WCAG 2.1

• 1.1.1 Non-text Content (A)
• 1.3.1 Info and Relationships (A)
• 2.4.6 Headings and Labels (AA)
• 3.2.2 On Input (A)
• 4.1.2 Name, Role, Value (A)

EN 301 549 v 2.1.2

• 9.1.1.1 Non-text Content
• 9.1.3.1 Info and Relationships
• 9.2.4.6 Headings and Labels
• 9.3.2.2 On Input
• 9.4.1.2 Name, Role, Value

Further reading

• 7 Rules of Using Radio Buttons vs Drop-Down Menus by Saadia Minhas
• 5 most annoying website features I face as a blind person every single day