Provide instructions and help users recover from errors

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, for example, driving licence, National Insurance number.

Include instructions

• Make sure you provide accurate, understandable and complete instructions at the top of the form. Ensure all fields and instructions are available before the submit button.
  • 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. Append this information programmatically, so that screen readers can relay it to users by using aria-describedby so that the description will be read out after the label.

• Any elements you want to reference will need to have an id to be able to use this technique as the aria-describedby attribute will need to point to these areas to get the appropriate label text.
  • For example, aria-describedby=”id-of-extended-description id-of-help-text”;
• You can concatenate several ids in the aria-describedby attribute, just separate the ids with spaces;
• Make sure there is always a label present, even if you have used aria-describedby.

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)”.

See WebAIM’s Accessible Forms page for example required fields 

Tell users what input format is required

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)

1. 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 providing clear and obvious error messages that include suggestions as to how they can correct the errors. 

Your design team may be able to help in the design of 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 (these are called form-level errors) and link each error to that place in the form (field-level errors);
• 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;
• Use aria-invalid=”true” on any inputs that have errors;
• Use ARIA to announce errors to screen reader users when they submit the form:
• Use role=”alert” or aria-live=”assertive”, or both combined – see this example of simple form validation using ARIA – assertive ARIA messages will interrupt screen readers so use them sparingly.

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.

Make use of auto-complete

When a browser or screen reader understands the type of data an input field is anticipating, it has the potential to call on information already stored on the system or browser, to ‘auto-complete’ the field. This has significant benefits for users who have problems with dexterity.

Additionally, assistive technology is capable of displaying additional icons or labels that a user may have specified to help users with visual or cognitive impairments better understand what the form wants from them.

Here is a list of input purposes that can be used with the 'autocomplete’ attribute when form fields collect information about the user. See also Understanding SC 1.3.5 Identify Input Purpose.

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.

Prevent errors from occurring when dealing with financial, legal or data systems

If you are creating webpages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, make sure you do at least one of the following:   

• Allow users undo the information or actions they have submitted;
• Check data entered by users for input errors and give the user an opportunity to correct them;
• Provide a mechanism for reviewing, confirming and correcting information before submission;
• Provide context-sensitive help.

This is to help users with impairments avoid serious consequences as the result of a mistake when performing an action that cannot be reversed. For example, purchasing non-refundable airline tickets or submitting an order to purchase stock in a brokerage account are financial transactions with serious consequences.

Remember, this is a cross-team effort

• Labels must be associated with their respective form element – this is your responsibility, along with appending any help text to labels and coding the grouping of form elements;
• 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. The design of forms should be handled by your design team; content producers may be able to help with instructions and text that helps users recover from errors.

Code examples

Using aria-describedby to associate help with a form field

1. <label for="password">Enter a password</label>
2. <input type="password" id="password" aria-describedby="password-help" />
3. <span id="password-help">Passwords should be 8 characters or more</span>

Using autocomplete on a ‘First name’ input field

1. <label for="first-name">First name</label>
2. <input type="text" id="first-name" autocomplete="given-name" />

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

• 1.3.5 Identify Input Purpose (AA)
• 2.2.1 Timing Adjustable (A)
• 2.5.3 Label in Name (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.1.3.5 Identify Input Purpose
• 9.2.2.1 Timing Adjustable
• 9.2.5.3 Label in Name
• 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)

Videos

• Improving Form Usability and Accessibility - Aquent Gymnasium

Further reading

• 5 most annoying website features I face as a blind person every single day
• Readability (Yale University)
• Simple form validation using ARIA
• WCAG Technique ARIA 19: Using ARIA role=alert or Live Regions to Identify Errors
• Hidde de Vries - How to make inline error messages accessible