E-mail List Archives
Thread: Form validation on blur or on form submission
Number of posts in this thread: 5 (In chronological order)
From: Steve Green
Date: Wed, Jun 06 2018 2:58AM
Subject: Form validation on blur or on form submission
No previous message | Next message →
Has anyone done any user testing to see whether people have a preference for form validation on blur or on form submission? I'm particularly interested in the results of testing with real non-technical users who are representative of the general public.
Also, did you identify any factors that affect these results, such as the length or layout of the form or whether the number of errors makes a difference?
I would have thought that the choice of validation approach is particularly relevant for screen reader and magnifier users, but did any other user groups have a preference for one approach or the other?
Regards,
Steve Green
Managing Director
Test Partners Ltd
020 3002 4176 (direct)
0800 612 2780 (switchboard)
07957 246 276 (mobile)
020 7692 5517 (fax)
Skype: testpartners
= EMAIL ADDRESS REMOVED =
www.testpartners.co.uk
Â
Connect to me on LinkedIn - http://uk.linkedin.com/in/stevegreen2
From: Swift, Daniel P.
Date: Wed, Jun 06 2018 7:04AM
Subject: Re: Form validation on blur or on form submission
← Previous message | Next message →
Steve:
A number of years ago we did some research on forms. In general, the shorter the forms, the better. I believe that we discovered that label on top of field was better, but we still use them next to each other to lessen the scrolling. On mobile and magnification, this changes to a single column of labels and fields.
We also do on-blur validation with validation occurring server-side in case JS is disabled and for sanitation. Even though I'm a technical person, I can speak on a non-technical level -- I've filled out many forms and find it incredibly frustration when an error is returned after post-back. The site owner gets extra fist-shaking if they've also cleared out part of the form as that invariably leads to a second submission complete with a second error.
Hope that helps!
Dan Swift
Senior Web Specialist
Enterprise Services
West Chester University
610.738.0589
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Steve Green
Sent: Wednesday, June 6, 2018 4:58 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] Form validation on blur or on form submission
Has anyone done any user testing to see whether people have a preference for form validation on blur or on form submission? I'm particularly interested in the results of testing with real non-technical users who are representative of the general public.
Also, did you identify any factors that affect these results, such as the length or layout of the form or whether the number of errors makes a difference?
I would have thought that the choice of validation approach is particularly relevant for screen reader and magnifier users, but did any other user groups have a preference for one approach or the other?
Regards,
Steve Green
Managing Director
Test Partners Ltd
020 3002 4176 (direct)
0800 612 2780 (switchboard)
07957 246 276 (mobile)
020 7692 5517 (fax)
Skype: testpartners
= EMAIL ADDRESS REMOVED =
www.testpartners.co.uk
Â
Connect to me on LinkedIn - http://uk.linkedin.com/in/stevegreen2
From: JR Accessibility
Date: Wed, Jun 06 2018 12:33PM
Subject: Re: Form validation on blur or on form submission
← Previous message | Next message →
While errors being returned after post-back can be frustrating, the
argument in favor of errors on post-back that I have from an accessibility
consultant is as follows.
(Begin quote.)
The errors can fire immediately on tab-out for a sighted user, but for a
non-sighted user, I believe it is better to catch the errors at the end (on
form submit).
The reason why is because when the user tabs out of the field, if an error
is announced (by screen readers), it often interferes with the new field
label being read that was just tabbed into.
Also, when the user tries to submit, it is a natural time to hear errors,
and at that time we can programmatically place their focus on the field
that has the error, making it easier for them to fix it than if they had
just tabbed out, then have to tab back into the problem field.
(End quote.)
I do agree that user research around this topic would be beneficial.
-----
From: "Swift, Daniel P." < = EMAIL ADDRESS REMOVED = >
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Date: Wed, 6 Jun 2018 13:04:53 +0000
Subject: Re: [WebAIM] Form validation on blur or on form submission
Steve:
A number of years ago we did some research on forms. In general, the
shorter the forms, the better. I believe that we discovered that label on
top of field was better, but we still use them next to each other to lessen
the scrolling. On mobile and magnification, this changes to a single
column of labels and fields.
We also do on-blur validation with validation occurring server-side in case
JS is disabled and for sanitation. Even though I'm a technical person, I
can speak on a non-technical level -- I've filled out many forms and find
it incredibly frustration when an error is returned after post-back. The
site owner gets extra fist-shaking if they've also cleared out part of the
form as that invariably leads to a second submission complete with a second
error.
Hope that helps!
Dan Swift
Senior Web Specialist
Enterprise Services
West Chester University
610.738.0589
From: Steve Green
Date: Wed, Jun 06 2018 4:08PM
Subject: Re: Form validation on blur or on form submission
← Previous message | Next message →
This is precisely my thought too. Historically (say up to perhaps ten years ago) validation was just about always done on form submission and I don't recall any users expressing dissatisfaction with this. It seems that new approaches such as validation on blur and even validation on key-up have become common without any user research that I am aware of.
We have a client whose existing website has a mixture of all three approaches and we have to decide which one to standardise on, so I would be delighted to find that they have been researched extensively and one approach was found to be better.
Steve
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of JR Accessibility
Sent: 06 June 2018 19:33
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Form validation on blur or on form submission
While errors being returned after post-back can be frustrating, the argument in favor of errors on post-back that I have from an accessibility consultant is as follows.
(Begin quote.)
The errors can fire immediately on tab-out for a sighted user, but for a non-sighted user, I believe it is better to catch the errors at the end (on form submit).
The reason why is because when the user tabs out of the field, if an error is announced (by screen readers), it often interferes with the new field label being read that was just tabbed into.
Also, when the user tries to submit, it is a natural time to hear errors, and at that time we can programmatically place their focus on the field that has the error, making it easier for them to fix it than if they had just tabbed out, then have to tab back into the problem field.
(End quote.)
I do agree that user research around this topic would be beneficial.
-----
From: "Swift, Daniel P." < = EMAIL ADDRESS REMOVED = >
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Date: Wed, 6 Jun 2018 13:04:53 +0000
Subject: Re: [WebAIM] Form validation on blur or on form submission
Steve:
A number of years ago we did some research on forms. In general, the shorter the forms, the better. I believe that we discovered that label on top of field was better, but we still use them next to each other to lessen the scrolling. On mobile and magnification, this changes to a single column of labels and fields.
We also do on-blur validation with validation occurring server-side in case JS is disabled and for sanitation. Even though I'm a technical person, I can speak on a non-technical level -- I've filled out many forms and find it incredibly frustration when an error is returned after post-back. The site owner gets extra fist-shaking if they've also cleared out part of the form as that invariably leads to a second submission complete with a second error.
Hope that helps!
Dan Swift
Senior Web Specialist
Enterprise Services
West Chester University
610.738.0589
From: Birkir R. Gunnarsson
Date: Thu, Jun 07 2018 9:37PM
Subject: Re: Form validation on blur or on form submission
← Previous message | No next message
You always have to do error checking on submit. That's the safe base level.
Question is, do you want to go above and beyond that.
I think that question starts with general usability testing to see
what, or a lack of a better word "regular usres" prefer.
If they prefer oninput/onblur validation they should have it.
The second phase I'd carry out the same esting with users of assistive
technologies, who interact differently with the page and decide
whether to make the more aggressive error validation available to them
by use of live regions.
On 6/6/18, Steve Green < = EMAIL ADDRESS REMOVED = > wrote:
> This is precisely my thought too. Historically (say up to perhaps ten years
> ago) validation was just about always done on form submission and I don't
> recall any users expressing dissatisfaction with this. It seems that new
> approaches such as validation on blur and even validation on key-up have
> become common without any user research that I am aware of.
>
> We have a client whose existing website has a mixture of all three
> approaches and we have to decide which one to standardise on, so I would be
> delighted to find that they have been researched extensively and one
> approach was found to be better.
>
> Steve
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of JR
> Accessibility
> Sent: 06 June 2018 19:33
> To: = EMAIL ADDRESS REMOVED =
> Subject: Re: [WebAIM] Form validation on blur or on form submission
>
> While errors being returned after post-back can be frustrating, the argument
> in favor of errors on post-back that I have from an accessibility consultant
> is as follows.
>
> (Begin quote.)
>
> The errors can fire immediately on tab-out for a sighted user, but for a
> non-sighted user, I believe it is better to catch the errors at the end (on
> form submit).
>
> The reason why is because when the user tabs out of the field, if an error
> is announced (by screen readers), it often interferes with the new field
> label being read that was just tabbed into.
>
> Also, when the user tries to submit, it is a natural time to hear errors,
> and at that time we can programmatically place their focus on the field that
> has the error, making it easier for them to fix it than if they had just
> tabbed out, then have to tab back into the problem field.
>
> (End quote.)
>
> I do agree that user research around this topic would be beneficial.
>
> -----
>
> From: "Swift, Daniel P." < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Date: Wed, 6 Jun 2018 13:04:53 +0000
> Subject: Re: [WebAIM] Form validation on blur or on form submission
> Steve:
>
> A number of years ago we did some research on forms. In general, the
> shorter the forms, the better. I believe that we discovered that label on
> top of field was better, but we still use them next to each other to lessen
> the scrolling. On mobile and magnification, this changes to a single column
> of labels and fields.
>
> We also do on-blur validation with validation occurring server-side in case
> JS is disabled and for sanitation. Even though I'm a technical person, I
> can speak on a non-technical level -- I've filled out many forms and find it
> incredibly frustration when an error is returned after post-back. The site
> owner gets extra fist-shaking if they've also cleared out part of the form
> as that invariably leads to a second submission complete with a second
> error.
>
> Hope that helps!
>
> Dan Swift
> Senior Web Specialist
> Enterprise Services
> West Chester University
> 610.738.0589
> > > http://webaim.org/discussion/archives
> > > > > >
--
Work hard. Have fun. Make history.