Provide instructions and help users recover from errors

Why is this important?

When asking users for information, much is open to interpretation. We can help users complete forms quickly, easily and accurately, by providing clear, accurate instructions and by making helpful suggestions when errors happen.

Poorly designed forms can be a significant barrier for users with impairments but if you work as a team and follow these guidelines you should be able to create forms that are highly usable and highly accessible.

Techniques

Set expectations accordingly

Tell users the purpose of the form, the number of pages or steps involved, and prepare them in advance if they need to know specific information to complete the form, such as their driving licence or National Insurance number.

Include instructions

• Make sure you provide accurate, understandable and complete instructions at the top of the form;
• Avoid using technical terms such as “required field” – to most people a field is where cows graze.
• If applicable, indicate how many pages or steps there are in this form;
• Help prevent users from making errors by including specific instructions or help against specific form elements;
• Ensure instructions are input method agnostic, for example, say “enter” instead of “type” or “click” – some users will need to fill forms in using speech.

Position hints and help text appropriately

If you want to add hints and tips to your form – such as “passwords must contain at least one number”, add that text next to the form field so that it is visible and associated by proximity. This help text can be appended to the form label through code – using aria-labelledby or aria-describedby – so that it is announced by screen readers.

Avoid using tooltips for help or instruction

Tooltips are not always accessible to keyboard-only or touch-based users, they can obscure page content when they appear and they can be easily missed by, or difficult to navigate for, screen reader and screen magnifier users. Instead, ensure the text is visible on the page. If you have a lot of help text, consider whether your form is too complicated or would be easier to explain if split into smaller sections.

Write instructions for low literacy

Writing instructions for lower reading levels benefits users with cognitive impairments, those for whom English is a second language, and users who may be distracted while trying to complete a form.

• Avoid 'big' words just for the sake of it;
• Avoid contractions (don’t, didn’t, couldn’t);
• Use simple question structures that avoid the need for extensive and complex punctuation;
• Be direct. If users need to complete a task tell them - avoid subtlety.

Use an active rather than a passive voice

Almost every resource on writing effective English provides a section that explains the importance of avoiding the passive voice. 

• Identify who is doing the action and make them the subject of the sentence, for example, a passive instruction might read, “A secure password is required”; an active instruction might read, “Enter a secure password”;
• Active voice helps with being concise – it is less wordy and more direct.

Identify required fields programmatically and visually

• Use HTML markup to denote required fields, using the attribute, “required”
• 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)”.

Tell users what format is required, for example, for dates

Where a specific input format is expected users should be informed visually and (where appropriate) programmatically.

• Specify input types using the type attribute if an appropriate option is available (type=”email”, type=”password”, type=”number”);
• Do not specify the expected format through placeholder text, as this will disappear on focus and users will lose their visual reference.
• Automatically change the data to the required type. 
• For example, a date field requiring the date to be input as 01/10/2021 automatically includes the ‘/’ (slash) symbols when a user inputs the date (or is already included, so that the user doesn’t have to change keyboard views, find symbols and then revert back to number pad mode)
• Ensure the format is explicitly explained in either the label text or the help text.

Be careful with timeouts

• ideally, avoid specifying timeouts and time limitations completely;
• Where you do have to impose a time limitation or timeout:
• warn users about them and allow them to extend the time limit with a simple action;
• ensure that users will be able to restart the process without losing the data they have entered.

Help users recover from errors by providing meaningful and useful error messages

It is highly likely, despite your excellent instructions and help text, that users will make errors when filling in your form. Help them to recover from these errors by designing clear and obvious error messages that include suggestions as to how they can correct the errors. 

Whilst error handling will be coded by the development team, you can help by designing well-positioned, specific error messages.

• Ensure error handling is done in a timely manner. If you are able to, validate form fields as they are completed. This makes them a lot easier for users to address;
• Carefully position error messages. Screen reader users and screen magnifier users require error messages to appear near to the form field that has the error. If they are not adjacent they may have difficulty finding the error;
• On submission, provide a summary of all errors at the top of the form and link each error to that place in the form;
• Reiterate the error message next to the area on the form that contains an error;
• Visually distinguish error messages from regular text – you can highlight them through the use of colours and borders, but only use these to support your messages, do not rely on style alone to convey errors;
• Explain the problem and how to fix it without using technical jargon.

Provide a summary of all questions and responses before submission

Allow users to review the answers they provided and give them an opportunity to revise them, before they submit the form.

Do not disable form submit buttons

By its very nature, users cannot interact with a disabled submit button. If you only enable the form submit button once all fields have been completed, users who have accidentally missed a field will not be given any indication that anything is wrong. If you allow users to interact with the submit button, error messages can be displayed which will provide clear instructions to users on how they can fix any problems.

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 – help text must look like it belongs to the form element without disrupting the flow of the form. Form design is your responsibility but your content producers may be able to help with instructions and text that helps users recover from errors.

Examples of good and bad form design

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

Table 2 - Examples of what to and what not to say

Videos

• W3C Perspectives – Notifications and Feedback

References

WCAG 2.1

• 2.2.1 Timing Adjustable (A)
• 3.1.5 Reading Level (AAA)
• 3.3.1 Error Identification (A)
• 3.3.2 Labels or Instructions (A)
• 3.3.3 Error Suggestion (AA)
• 3.3.4 Error Prevention (Legal, Financial, Data) (AA)

EN 301 549 v 2.1.2

• 9.2.2.1 Timing Adjustable
• 9.3.3.1 Error Identification
• 9.3.3.2 Labels or Instructions
• 9.3.3.3 Error Suggestion
• 9.3.3.4 Error Prevention (Legal, Financial, Data)

Further reading

• 5 most annoying website features I face as a blind person every single day
• Readability (Yale University)