Search code examples
accessibilitywcag2.0

How should error messages should be handled for screen readers?


I am working on some accessibility testing. On the site, they have a registration form and use form validation techniques. Error text is shown under the form fields where the data inserted within the form field is invalid. Currently the error text appears on the fly and not on the form submission. As you tab through the form, errors appear.

By design, the form submit button is not visible until the form field data is valid. So doing an error check on form submission is not currently possible.

What is considered "best practice" in this situation? I feel they need to change the way this form is designed to meet WCAG.

There seems little point in using aria-describedby on the field and associated with the error message as the by the time the error appears, the user has moved to a new field. Should they be looking to show the submit button and then in turn allow the errors to be announced when the form submission fails? Or is there another issue with error text changing on the screen with no changes alerting the screen reader?


Solution

  • There is a lot of literature about accessible form validation and error notifications on the Internet. Here are a few pointers which you can make a search with:

    • Use aria-required to notify of required fields. The screen reader says "required" when tabbing into the field.
    • Use aria-invalid to notify of field that are currently invalid. The screen reader says "invalid" when tabbing into the field.
    • Link the error message with the field using aria-describedby. The screen reader provides a way to read the description while being inside the erroneous field.
    • Use aria-live to notify the screen reader of appearing or disappearing text. The text is read as soon as possible by the screen reader. It is well-suited for errors.

    As you can see, there's nothing wrong with validating on the fly with accessibility.

    I would have only one remark: the submit button should preferably be disabled, rather than invisible, when the input is incorrect. An invisible button may prevent from ENTER key submission entirely. Submitting the form by pressing ENTER will produce a warning if the button is disabled instead. Submission with the ENTER key is quite important for screen reader users, as it prevents them the pain of searching the submit button.

    Use the onsubmit event on the form, rather than onclick on the submit button, to make sure the JavaScript validation code is run before the form data is sent, regardless of how the form was submitted (click on submit or ENTER key).