Foundations: form validation and error messages
Posted on by Demelza Feltham in Design and development
As well as labelling text fields with input and labels, form validation and error messages are also essential to making forms accessible to everyone.
Forms are crucial for interactive web experiences, but they can often lead to errors requiring validation. Inaccessible validation and feedback can cause frustration and can sometimes result in form abandonment. However, when made accessible, the process becomes seamless and frictionless.
This benefits everyone, but in particular:
- People browsing with a screen reader and braille displays who cannot see content and rely on the properly coded form validation and error messages to progress with the form
- People with cognitive disabilities who need clear and concise error feedback to understand the issue and how to fix it
- People with reduced focus or short attention spans who rely on both clear in-line error messages and post-submission error notifications
Accessible form validation and error messages come in two forms, in-line error messages, and post-submission error messages.
In-line error messages
When filling out a form, real-time error messages can appear thanks to client-side validation, a feature in modern web browsers. This checks and displays errors as the form is filled out, ensuring inputs meet specific criteria before submission. Native HTML validation is useful because it enforces rules and guides users on what’s expected. However, if not well-designed, in-line error messages can become overwhelming. For example, flagging a field as incorrect after just one character can be disruptive, especially if the person filling out the form hasn't finished typing.
The ideal implementation of in-line messages is to appear once focus has moved to the next form field. When an error is detected, the message typically appears "in-line" or adjacent to the field in error. This approach provides immediate feedback without prematurely registering an error, and saves people from the frustration of submitting a form with errors. It also reduces cognitive load, making the form-filling process smoother and less stressful.
For example, password fields often have length requirements that should be clearly communicated both visually and programmatically for the benefit of people browsing with a screen reader. By using attributes like minlength and maxlength, you can easily control the number of characters allowed in a text field. If someone uses too few characters, in-line validation can immediately alert them to the error.
Post-submission error message
When a form is submitted, server-side validation checks for errors. If the form contains errors, they should ideally be reported in a summary at the top of the page. This approach has the advantage of not interrupting the flow of anyone filling out the form, ensuring that only valid data is submitted. However, this method can be frustrating if multiple errors are found, as it can be time-consuming to correct them all. Additionally, addressing numerous errors at once can increase cognitive load, making the process of fixing mistakes more challenging.
The default approach is to use a combination of both. Client-side validation provides quick feedback with inline error messages. Server-side validation catches errors missed or bypassed on the client side and can report error summaries clearly and concisely. Using both creates a balanced and reliable validation system.
Common accessibility issues with form validation and error messages
Most common issues with form validation and error messages can be easily avoided. It is common to see, but easy to solve, with the following techniques.
The error state of the form is not communicated
When a form field with an error state gets focus, it doesn't always communicate the error to assistive technologies, leaving screen reader users unaware of the issue and failing to meet accessibility standard 4.1.2 Name, role, value.
The solution is to add the aria-invalid="true" attribute to the field with an error. This ensures assistive technologies can recognise and announce the error when the field is focused.
The error messages are not communicated to assistive technology
Sometimes, error messages are visible on the screen but not communicated to assistive technologies, preventing screen reader users from receiving important information, making it difficult for people with visual impairments to correct mistakes and complete the form accurately. This can also lead to a failure to meet 4.1.3 Status messages.
The solution is to ensure they are announced by adding role="alert" to error elements. Alternatively, use aria-live regions to ensure changes to error messages are promptly communicated. For more guidance on how to implement live region, see Why are my live regions not working?.
Error messages are not associated with the field in error
Sometimes, error messages appear visually connected to a field, but the markup doesn't support that relationship. As a result, screen readers don't recognise the error message as related to the field, making it harder for users with visual impairments to fix errors. It can also lead to a 1.3.1 Info and relationships failure.
The solution is to use the aria-describedby attribute on the control and set it to the id of the element containing the error message so screen readers can link the message to the correct field. Ensure that the id/aria-describedby relationship is only active when an error is present, or include the error message text in the DOM only when an error occurs. Otherwise, if the error message text remains in the DOM when the control is not in an error state, it may still be announced, even if it is hidden.
Write clear and helpful error messages
After addressing the markup for accessible form validation, focus on making error messages clear and actionable. Error messages must contain helpful guidance for resolving errors. Simply notifying people of a problem isn’t enough; clear instructions on how to fix it are essential. This will also ensure that success criteria 3.3.3 Error suggestion is fulfilled.
- Provide specific instructions: clearly describe what needs to be corrected. For example, if an email is entered incorrectly, explain what is missing or incorrect
- Include examples or suggestions: whenever possible, offer examples or suggestions to guide people in fixing the error
- Be concise and focused: ensure that error messages are brief and to the point; clear and concise messages help everyone quickly understand and resolve issues without confusion
Tips
Tips for accessible form validation and error messages:
- Combine in-line and post-submission validation: use a combination of in-line and post-submission error messages to provide comprehensive feedback
- Expose error states: add the
aria-invalid="true"attribute to communicate errors to assistive technologies - Ensure error messages are accessible: make sure screen readers can announce error messages by using appropriate attributes like
role="alert"oraria-live - Associate error messages with fields: use the
aria-describedbyattribute to link error messages to the relevant form fields, ensuring accessibility for assistive technologies - Provide clear instructions: offer specific and actionable guidance on how to resolve errors
Related standards
Next steps
Read more accessibility foundations posts, our WCAG primer or how assessments can help you identify issues in your websites, mobile applications, design systems, and other products and services.