Posted on by Demelza Feltham in Design and development
Tags: Assistive Technology, Code, Foundations, WCAG
As well as labelling text fields with input and labels, and grouping forms with the <fieldset> and <legend> elements, 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:
Accessible form validation and error messages come in two forms, in-line error messages, and post-submission 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.
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.
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.
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.
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?.
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.
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.
Tips for accessible form validation and error messages:
aria-invalid="true" attribute to communicate errors to assistive technologiesrole="alert" or aria-livearia-describedby attribute to link error messages to the relevant form fields, ensuring accessibility for assistive technologiesRead more accessibility foundations posts or sign up for Accessibility Unlocked, our free six-day newsletter series designed to help you kick-start accessibility.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。