6

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?

Super Jade
  • 5,609
  • 7
  • 39
  • 61
user2007920
  • 123
  • 1
  • 9

3 Answers3

12

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

Alexander Nied
  • 12,804
  • 4
  • 25
  • 45
QuentinC
  • 12,311
  • 4
  • 24
  • 37
  • Thank you, that is very helpful. (sorry if you had multiple notifications for my reply, i kept hitting enter instead of shift enter). – user2007920 Nov 17 '19 at 10:41
  • aria-required is in use and i was going to suggest aria-describedby. My main concern was that the user would not have the error read to them as the ficus would have moved to the next field, leaving field 1 with an error and associated aria-describedby label, but the user would not be aware of the error. Given there is no form submit button due to the validation not being complete, the user would need to cycle through the form looking for evidence of why the form isnt functioning as expected. – user2007920 Nov 17 '19 at 10:41
  • Is it acceptable to design in this way? i was under the impression that WCAG requires the user to be notified of that change. – user2007920 Nov 17 '19 at 10:41
  • That's precisely what aria-live is for: read text changes in elements which don't have focus. If your error message on the previous field is also aria-live=polite, then the screen reader will read it when it appears. For the submit button, when it is completely absent, the first thinking is more going to be "it doesn't work" than "I missed something". Disabling the button with a very simple message "some fields are incorrect" next to it is much better. – QuentinC Nov 17 '19 at 17:09
2

Depending on your notification role=alert or aria-live might solve you issue.

role=alert "The alert role is used to communicate an important and usually time-sensitive message to the user. When this role is added to an element, the browser will send out an accessible alert event to assistive technology products which can then notify the user about it. The alert role is most useful for information that requires the user's immediate attention" - Taken from MDN, Using the alert role

aria-live "The aria-live attribute allows all of us to notify screen reader users when the content is updated in specific areas of the page." - Taken from CCCAccessibility

Ambassador Kosh
  • 459
  • 5
  • 19
0

Very helpful. For what it’s worth, you shouldn’t have invisible or inactive buttons. Inactive buttons being the worse of the two as they don’t inform the user why they’re inactive. Better to have an active button and then highlight the issue when the user tries to submit.

TravisL
  • 1