Form Validation and Error Reporting

LiveWhale
1

When a LiveWhale form is submitted, some validation occurs. The error reporting varies depending on the type of error.

For example, if there are missing required fields, the user gets a message that says, “You must fill out all required fields.” The user can scroll up to see the fields that are in error labeled with red text.

If an invalid string is entered in an email field, the user gets a message that says, “You entered an invalid email address.” But there seems to be no indication anywhere in the form as to which field is in error. The user has to check all fields in the form to try to find the error.

This poses multiple problems. First, in both cases, it relies on the user to find the issue(s), even if the first situation is slightly easier due to the red color. But it is also an accessibility issue. Assistive technology will have a hard time identifying the issues, and relying on color alone to communicate anything breaks a fundamental accessibility rule.

So, I have some questions:

  1. To LiveWhale… are there any plans to improve the validation and error handling in LiveWhale forms? Possible in LW 3.0?
  2. To anyone… have you done anything (custom module, JS, etc) to address some of these concerns? Based on some quick testing, it appears that I could use JS to inject HTML attributes like required and type="email" to get the browser to do some of the error reporting before LiveWhale process the submission.
  3. If I wanted to pursue #2, besides required and email fields, are there other types of form validation I should be considering?
2

Thanks Jon,

Yes, I think a more integrated validation system would be an improvement, but it’s not something we have roadmapped for 3.0. Possibly it’d be a 3.1/3.2 type of change we might work towards sometimes next year, say.

In the meantime, one thing I’ve seen have some success is if you use one of the following custom module handlers to validate

You can add validation to every field using that method, and then return them all in one descriptive block. Part of the reason for the original situation you describe is that validation happens in “waves” in the core platform, and in each wave if a validation error is caught, it might halt processing and return just the error(s) found so far. Doing it with a custom module to capture and verb things the way you like, you have a chance of capturing more of the error case possibilities and returning them in one succinct list.

Hope this helps!

3

Thanks Karl. To everyone else… have any of you done something with the form submission handlers as Karl mentioned, and would you be willing to share?

4

One example we have. Doesn’t seem ideal, relative to what you want to achieve, but may be a start?

  public function onFormsSubmission($id) { 
    global $_LW;
    
    // if we just submitted the correct form
    if ($id === '59') {
      
      // make sure the email is @beloit.edu
      if (strpos($_LW->_POST['lw_form_59_1616596349008100'], '@beloit.edu') === false) {
        die(json_encode(array('error' => 'Please use your "@beloit.edu" email address.')));
      }
      
      // make sure a student is selected
      // [selection was filled with no-quote student profiles onOutput()]
      if (empty($_LW->_POST['lw_form_59_161659636727510'])) {
        die(json_encode(array('error' => 'Please select a student to write about. If the list is blank, there may not be any students who need a statement.'))); 
      }
      
      // make sure statement is long enough
      if (strlen($_LW->_POST['lw_form_59_161659636819383']) < 200) {
        die(json_encode(array('error' => 'Please write some more about this student. <em>(More than 200 characters.)</em>')));
      }
      
      // make sure statement is not too long
      if (strlen($_LW->_POST['lw_form_59_161659636819383']) > 1000) {
        die(json_encode(array('error' => 'Please make your statement more concise. <em>(Less than 1000 characters.)</em>')));
      }
      
    }
    
  }
1 Like