Web Form Validation - Best Practices and Tutorials

Web Form Validation: Best Practices and Tutorials - Smashing Magazine http://www.smashingmagazine.com/2009/07/07/web-form-validation-best...
Web Form Validation: Best Practices and Tutorials

URL: http://www.smashingmagazine.com/2009/07/07/web-form-validation-best-practices-
and-tutorials/
By Janko Jovanovic July 7th, 2009 Design 60 Comments Publishing Policy
Ideally, users will fill the web form with necessary information and finish their jo
often make mistakes. This is where web form validation comes into play. The goal of web form validation is to
ensure that the user provided necessary and properly formatted information needed to
operation. In this article we will go beyond the validation itself and explore diffe
techniques, methods and approaches.
Validation methods
User’s input can be validated on the server and on the client (web browser). Thus we
client-side validation. We’ll discuss pros and cons of each.
Server-side validation
In the server-side validation, information is being sent to the server and validated
languages. If the validation fails, the response is then sent back to the client, pa
refreshed and a feedback is shown. This method is secure because it will work even i
browser and it can’t be easily bypassed by malicious users. On the other hand, users
information without getting a response until they submit the form. This results in a
The exception is validation using Ajax. Ajax calls to the server can validate as you type and provide immediate
feedback. Validation in this context refers to validating rules such as username ava
about validation with Ajax in this excellent tutorial (http://jqueryfordesigners.com/using-ajax-to-validate-
forms/) on jQueryForDesigners.
1 de 23 26/08/2010 10:31 a.m.

Client-side validation
Server-side validation is enough to have a successful and secure form validation. For better user experience,
however, you might consider using client-side validation. This type of validation is done on the client using script
languages such as JavaScript. By using script languages user’s input can be validated as they type. This means a
more responsive, visually rich validation.
With client-side validation, form never gets submitted if validation fails. Validation is being handled in JavaScript
methods that you create (or within frameworks/plugins) and users get immediate feedback if validation fails.
Main drawback of client-side validation is that it relies on JavaScript. If users turn JavaScript off, they can easily
bypass the validation. This is why validation should always be implemented on both the client and server. By
combining server-side and client-side methods we can get the best of the two: fast response, more secure validation
and better user experience.
(https://www.typepad.com/secure/services/register?acct_level=pro)
Rich, instant validation feedback is done on the client on TypePad
What to validate
There are several different types of validation you can perform: required fields, correct format and confirmation
fields.
Required information
The first and most obvious information that should be validated is required information – information without
which operation cannot be completed successfully. Thus, validation has to ensure that the user provided all the
necessary details in the web form and it has to fail if at least one of the fields is not provided. Required fields should
be clearly marked in order to inform users about what information has to be provided up front.
2 de 23 26/08/2010 10:31 a.m.

(http://www.komodomedia.com/blog/2009/06/social-network-icon-pack/)
Required fields on Komodo Media blog comment form are marked with “required” help text.
A common way to mark required fields is with an asterisk (*). However, not all users know the meaning of an
asterisk sign. Beginners or older users are very likely to have only a general idea of what an asterisk might mean.
This is the reason why it is a good practice to either put a note on the top of the form that indicates that all fields
marked with an asterisk are required or to use required field markers. In case that all fields are required there is no
need to place asterisks or markers in the form. A simple message that all fields are required is enough.
Facebook Required in Web Form Validation: Best Practices and Tutorials

(http://www.facebook.com)
Facebook doesn’t provide information about required fields. Users get information that all fields are
required only after they press the “submit”-button.
Last year, we conducted an survey on Web form design (http://www.smashingmagazine.com/2008/07/04/web-

form-design-patterns-sign-up-forms/). According to that survey “designers tend to remove all unnecessary details
and distractions which don’t help the user to complete the form”. More detailed analysis showed a trend of using
very few mandatory fields – more than 50% of forms used at most 5 mandatory fields, while optional fields were
often avoided. This can be useful to you when deciding on required fields.
Correct format
Apart from ensuring that users provide necessary information, validation has to ensure that users provide
information in the correct format. This applies to various cases such as email address, URL, dates, phone numbers
and others. If the information is not in the correct format, users should be informed and correct format should be
suggested. Probably the easiest way to validate the “correct” formatting is to use regular expressions.
Please notice that it is often a good idea to not impose a strict input pattern on the users; it’s better to
actually permit users to enter text in a variety of formats and syntaxes, and make the application interpret it
intelligently. The user just wants to get something done, not think about “correct” formats and complex UIs. Let
the user type whatever he needs, and if it’s reasonable, make the software do the right thing with it. This design
pattern is also often called forgiving format UI design pattern (http://designinginterfaces.com
/Forgiving_Format).
(http://www.carbonmade.com/signup)
Carbonmade sign-up form validates URL format, informs the user about the error and provides ways to
3 de 23 26/08/2010 10:31 a.m.

correct it.
To learn more about regular expressions be sure to read Essential Guide To Regular Expressions: Tools and
Tutorials (http://www.smashingmagazine.com/2009/06/01/essential-guide-to-regular-expressions-tools-
tutorials-and-resources/) or if you already know the basics: Crucial Concepts Behind Advanced Regular
Expressions (http://www.smashingmagazine.com/2009/05/06/introduction-to-advanced-regular-
expressions/). We’ll discuss some other format techniques later in the article.
Confirmation fields
When dealing with data that is important to the system, it is a good practice to let the users confirm their input
using additional confirmation fields. This way users can be certain that they provided correct information. A typical
case when confirmation field is used is for passwords, but it can be used in other cases like an email address.
(http://register.photobucket.com/?ref=joinus)
Photobucket sign-up form required users to re-type password they previously entered in order to ensure it
has been correctly entered.
A confirmation field should be placed next (or below) the target field. It has to clearly describe the purpose of the
field such as “Confirm your password”. If two values do not match, the user should be informed. As an option, you
can use a success indicator if values DO match.
The second part of our survey (http://www.smashingmagazine.com/2008/07/08/web-form-design-patterns-

sign-up-forms-part-2/) shows interesting information about confirmation fields. Email confirmation was
mandatory in only 18% of sites, while password confirmation was mandatory in 72% of web sites. Surprisingly,
large websites such as Facebook, LinkedIn, Stumbleupon and Twitter don’t require password confirmation.
Validation feedback
If validation fails, the system should let the users know it by providing a clear and unambiguous message (usually
one or two sentences) and ways to correct errors. Since users need to notice an error message immediately, it is a
good practice to position it at the top of a web form, before all the other fields. This will also allow screen readers to
easily access the message.
The message should be shown preferably in red since this is the color that people usually associate with errors and
it should contain an appropriate icon in order to get more attention. Icon should be globally recognizable, such as a
4 de 23 26/08/2010 10:31 a.m.

red circle with white cross. This will also help people with visual impairments identify the meaning of the message.
In addition to this, users should be informed about which input fields need to be checked.
(http://invoicemachine.com/signup)
The Invoice Machine Sign-up form doesn’t provide error feedback. Error message is missing and input fields
are colored with pastel red that is not easy to spot.
Apart from the error message and a list of invalid fields, the system should clearly mark fields that are invalid. This
can be done in one of the following ways (or any combination of them):
By providing red inline messages or markers next to every invalid field

By changing the background color or border color of invalid fields (to red)
By changing the color of field labels
By providing error tips (balloons) next to each field
If you provide error tips or help, be short and informative. For example, if date is in an incorrect, format provide
users with details on how to format it properly: “The date should be in the dd-mm-yyyy-format”. It is sometimes
also a good idea to have these hints as the initial value of your input fields. Thus, the user will first read the hint
inside the input box and when he/she will start typing the data, the hint will disappear.
Validation upon submit

The “classic” way to perform validation is when the user submits his data via the “submit”-button. The
validation is executed and if any errors are found, feedback is returned and displayed to the user. This way users
will be able to fill the form without any interruptions. But, that could be a disadvantage as well. Users will be able
to fix the errors only after they try to submit the form and get the response back from the server. This technique is
typical for server-side validation, but can also be done on the client side.
5 de 23 26/08/2010 10:31 a.m.

(https://www.getballpark.com/public
/signup?plan=5)
Feedback on Ballpark sign-up form occurs upon submit. It shows an obvious error message with incorrect
fields at the top of the form and marks each incorrect field with a tip.
Real-time validation (or instant validation)

In contrast to the previous technique, real-time-validation alerts users while they are filling in the form.
That doesn’t necessarily mean that the validation is performed on every single key press but rather when a field
loses focus. This way users will get immediate feedback about their input, e.g. if a username is available or if a date
is in the correct format. Obviously, instant validation occurs during typing in an input field or after the input field
loses focus. Usually, it is complemented with a text message, tip or a status icon.
(https://edit.yahoo.com/registration)
Yahoo registration form implements password strength meter that gives feedback as you type in the letters.
Instant validation should be implemented carefully and in appropriate cases because it might be distracting if
overused or misused.
6 de 23 26/08/2010 10:31 a.m.

(https://www.typepad.com/secure/services
/register?acct_level=pro)
Sign-up form on TypePad not just provides instant validation feedback that informs users of different
validation errors – it also indicates successfully entered information.
What to avoid?
There are two things you should really try to avoid when designing form validation. First, single error pages are
bad practice. Singe error page means that users are redirected from the Web form they filled to a page that shows
some feedback. In this case, users are forced to browse back in order to fix errors. When they browse back they will
have to memorize the information you provided in the error message. The same applies to feedback messages in
popup windows. Not only are popups annoying, but once they are closed all the feedback is lost.
An interesting finding in the second part of SM survey (http://www.smashingmagazine.com/2008/07/08/web-

form-design-patterns-sign-up-forms-part-2/) is that “30% of the forms displayed only an error-message at the top
of the form (no input fields were highlighted)” while “29% had highlighted input fields with corresponding
messages next to the input field (no error-messages were provided at the top of the page)”. Only 25% used both
error-messages and input fields.
Probably the most surprising facts are that 14% of sites still use JavaScript popup for showing validation feedback,
while Ajax validation is present only on 22% of sites. This shows big variations in validation feedback.
Better safe than sorry

Apart from the pure validation, there are several techniques that can help users make fewer mistakes. Although not
all of these techniques can be considered validation, they do help by guiding users and preventing them from
making mistakes.
Help hints
If a web form requires complex information to be filled in, help hints can significantly help users in the process of
filling in the correct information. By guiding them how to fill particular information, you let them fill the form
faster and avoid potential validation errors. Help hints are usually shown as simple text next to or above the input
field. The design of help hints should differ from the design of form labels. It is usually shown in smaller, grayed
text. The advantage of help information is that it is always visible to the user even if JavaScript is turned off.
7 de 23 26/08/2010 10:31 a.m.

(http://www.wishlistr.com/signup/)
WishListr provides useful help information on the right side of each field.
Help indicators (tooltips)

In contrast to help hints, tooltips initially hide information and make it visible “on demand”. They are usually
triggered by an icon with a question mark. Help information is shown by hovering over the help icon or clicking on
it. Once the mouse is moved away from the icon, the tooltip disappears. Help indicators can reduce clutter,
especially if help text is too long.
(http://tickettrunk.com/event/add)
Sign-up form on TicketTrunk contains obvious help indicators that provide help information on hover.
Dynamic tips
Similar to the previous case, dynamic tips are initially not visible to users. Once the user enters a particular input
field, related tip is shown. This way tips are emphasized and clutter in the form is reduced. Tips should be shown in
such a way that they don’t cover other information on the form. They are usually shown next to input fields, but
you should always try to place them on the right side of the fields since that is less distracting.
8 de 23 26/08/2010 10:31 a.m.

(http://digg.com/register/)
Digg registration form has discrete dynamic tips that show help information related to the field that has the
focus.
Masking and reformatting user’s input

Apart from validating user’s input and assisting users, web applications can also take part in providing correct data
by formatting user’s input. This can be done by masking input fields in order to force users to enter information in
an appropriate format. Mask is an expression that controls what users can enter in an input field. Masking can be
implemented easily with one of the following plugins:
meioMask (http://www.meiocodigo.com/projects/meiomask/)
iMask (http://zendold.lojcomm.com.br/imask/)
TypeCast (http://typecast.arapehlivanian.com/index.html)
jQuery Masked input plugin (http://digitalbush.com/projects/masked-input-plugin/)
(http://typecast.arapehlivanian.com/index.html)
Typecast (http://typecast.arapehlivanian.com/index.html) demo page shows different masking options.
In some cases users might fill partially correct information or correct information but in different format. In those
cases web application can provide a mechanism to correct and rewrite the user’s input. Some of the possible
scenarios when you might consider rewriting user’s input are:
if, for instance, a user enters URL without “http://” (http://”) prefix, the system can just add this string to the
9 de 23 26/08/2010 10:31 a.m.

beginning of URL.
if a user provides data in the dd-mm-yyyy-format, but the required format is yyyy-mm-dd, the system can
rewrite the date so it is well-formed
if a user provides credit card number without dashes, the system can add dashes to appropriate positions in
the credit card number
(http://www.tumblr.com/register)
Tumblr provides a sort of masking for URL.
These ideas are just some of the cases when this technique can be used. However, auto-formatting should be used
carefully and – if not used properly – can be confusing to users. Also, not all user’s input is predictable. If, for
example, user enters “www.smashingmagazine” and omits the extension, the system can’t assume that the
extension is “.com”, but should rather raise a validation error.
In this context it’s again worth mentioning the “forgiving format” design pattern. Instead of restricting user’s input
to a specific format you can allow users to provide various formats and let the system parse it. In many cases this
would require a lot of server processing; back-end would be responsible for parsing the input, extracting
information and converting it to appropriate formats for further processing.
(http://www.google.com/calendar/)
Google Calendar has a very clever implementation of this technique with one-field for adding events. Users
can enter information in various formats (even use “tomorrow” instead of date); the system parses it and
stores it as a new event. If user provides information that can’t be parsed, system assumes that this
information is event title and redirects the user to a longer version of the form with filled event name. This
way Google completely omitted validation.
According to our survey. 67% of sites use help text and tips, 10% of which use dynamic tips. Surprisingly, only 26%
of tips are positioned on the right side of the fields, while in other cases tips are positioned above, below and even
on the left side of input fields.
10 de 23 26/08/2010 10:31 a.m.

Are you human?

Web form validation wouldn’t be complete without mentioning Captcha. Captcha is a significant part of validation
as it is responsible for finding out if the user of a system is a human or a bot. In its simplest form, captcha consists
of an image showing text, numbers or an expression and a field that expects content of the image as input. The
earliest captcha generated images with numbers (e.g. “8356″) and that number was expected to be entered by the
user. If correct number wasn’t entered (or not entered at all), the form couldn’t be submitted. In fact, today most
spam bots are able to recognize the text embedded in a simple captcha-image, so it’s a good idea to pose some
question that only humans could answer correctly, e.g. “What color does the Sun have?” with correct answer
“yellow” in all its variations (“YELLOW”, “yellow”, “Yellow” etc.).
You may also want to consider the technique called Honeypot Captcha (http://haacked.com/archive/2007/09
/11/honeypot-captcha.aspx) where the idea is to create hidden form elements and check on the server side that
they remain blank. Another option is to create a form field with a label that says, “Leave this field blank” and then
is marked as a required field (thank you, Shawn McCool).
Simple captcha requires an answer to a semantic question.
The kind of captcha presented above caused a major problem in accessibility. Blind, visually impaired or dyslexic
users have difficulties or are even impossible to complete the web form with Captchas. As the Web evolved, so did
captchas and today there are implementations like ReCaptcha (http://recaptcha.net/) that have audio support for
users with disabilities.
(https://edit.yahoo.com/registration)
Captchas can show hardly recognizable words. Can you easily read the word on the left?
Still most users hate captchas (and there is a good reason for hating them!). Of course, people just don’t like filling
in forms. If they can’t do it fast and effortlessly, there is a high probability that they won’t do it at all. This is where
a captcha doesn’t help at all: it can take too much time for users to read (if text is messy) which happens oft in
practice. Remember, Captcha helps site owners, not their users. Therefore it’s always a good idea to avoid using
Captchas if you can avoid them. To read more about Captchas and accessibility, read Inaccessibility of CAPTCHA
(http://www.w3.org/TR/turingtest/).
(http://digg.com/register/)
Captcha on Digg registration form has audio support. If unable to read, users will be able to hear the letters
shown in the image.
Useful resources
Here are some of the frameworks, plugins and tutorials that might help you easily implement validation in your
11 de 23 26/08/2010 10:31 a.m.

forms.
LiveValidation (http://www.livevalidation.com/)
A small, open source JavaScript validation library. It enables real-time, rich client validation which can be
implemented easily. The best way to see its capabilities is to check out the example
(http://www.livevalidation.com/examples) page.
Validanguage (http://www.drlongghost.com/validanguage.php)
A validation framework that enables rich client-side validation.
JavaScript Form Validation (http://code.google.com/p/javascriptformvalidation/)
A JavaScript validation framework for creating inline validation. You can configure it through JavaScript code
or by using XML configuration file.
PhatFusion Validate (http://www.phatfusion.net/validate/)
A small JavaScript validation framework based on MooTools.
UniForm (http://www.sprawsm.com/uni-form/)
An attempt to standardize form markup (xhtml) and CSS. It can help you style error messages, help text,
indicators and so on.
jQuery Validation plugin (http://bassistance.de/jquery-plugins/jquery-plugin-validation/)
One of the most popular validation plugins. As expected from jQuery plugin, it enables validation in one line of
code, but you can also customise it. It has only 14 kb and is compatible with jQuery 1.3.2.
jForm (http://frontendbook.com/projects/jform/)
Another jQuery plugin that lets you implement validation easily. Not only that it performs validation but also
has the support for live tips. It is still in development phase but is worth checking.
Dynamic JavaScript Form Validation (http://www.leigeber.com/2008/04/dynamic-inline-javascript-

form-validation/)
Provides easy validation and attractive error messages.
jQuery Form Validator (http://www.position-absolute.com/articles/jquery-form-validator-because-
form-validation-is-a-mess/)
Another great jQuery validation plugin that performs live validation. It is fully customisable and supports
localisation as well.
Form field hints with CSS and JavaScript (http://www.askthecssguy.com/2007/03
/form_field_hints_with_css_and.html)
A useful tutorial on how to create help tips using CSS and JavaScript. Demo and source are included.
Validation Hints for your form (http://www.askthecssguy.com/2007/05

/validation_hints_for_your_form_1.html)
A great tutorial from Ask The CSS Guy that shows how to create inline validation with CSS and JavaScript.
Screencast: Quick PHP Form Validation with PEAR (http://www.havocinspired.co.uk/tutorial/screencast-
quick-php-form-validation-with-pear/#comments)
A nice example of how you can validate PHP forms using PEAR framework.
PHP Contact Form with jQuery Validation (http://www.raymondselda.com/php-contact-form-with-jquery-

validation/)
This tutorial shows how to implement the validation of a contact form using PHP and JavaScript.
How to Validate Forms on both sides using PHP and jQuery (http://yensdesign.com/2009/01/how-validate-
12 de 23 26/08/2010 10:31 a.m.

forms-both-sides-using-php-jquery/)
Shows how to implement both client-side and server-side validation using PHP.
Adding Form Validation to WordPress Comments using jQuery (http://net.tutsplus.com/tutorials/wordpress
/adding-form-validation-to-wordpress-comments-using-jquery/)
An interesting tutorial for all WordPress users.
Conclusion
You saw different methods and techniques that you can use to implement validation in your forms. Although there
are many possibilities, you should carefully plan validation for each project. Not all techniques provide a solution
for everything. Some of them are very helpful and easy to implement, but some lack usability and simplicity. If you
are new to web form design here is a short list of what to consider in Web form validation design). That might be
enough for you to start.
Rules of thumbs in web form validation design

Never omit server-side validation.
Don’t provide confusing validation feedback. It should clearly communicate the errors and ways to fix them.
Don’t let users think about what information is required, always clearly mark required fields.
Never provide validation feedback on a single page or in a popup alert.
Don’t use dynamic effects as compensation for a badly designed form. Fancy effects won’t hide a poorly
designed web form.
If you use Captcha, don’t forget to provide audio support and enable users to “reload” the Captcha.
Don’t forget to inform users when the form was completed successfully. It is as important as a good validation
feedback.
Janko Jovanovic
Janko Jovanovic is user interface designer, software engineer, blogger, speaker and artist. In
his free time, he writes about user interfaces on his blog JankoAtWarpSpeed and tweets
regularly on Twitter.
Homepage (http://www.jankoatwarpspeed.com)
Twitter Page (http://twitter.com/jankowarpspeed)
Tags: forms, validation
60 Comments
13 de 23 26/08/2010 10:31 a.m.

Tom Huynh July 7th, 2009 9:42 am

Great article, will use this on my forms!
1
July 7th, 2009 9:51 am

AdrianMG
Thanks for the referral to yensdesign.com ;)
2
Ken July 7th, 2009 10:02 am

Check out this captcha idea: http://ttix.org/ttix-register.php (just select “no, I need to create a
3
profile”, then scroll to the bottom to see it)
Shawn McCool July 7th, 2009 10:02 am

I appreciate the technique called honeypotting. Create hidden form elements and check on the
4
server side that they remain blank.
Also, I think it’s a great idea to create a form field with a label that says, “Leave this field blank”
and then is marked as a required field. I think that would be funny.
Love, Shawn.
omtay38 July 7th, 2009 10:24 am

Great article! One possibly confusing point I’ve noticed:
5
Under the “Server-side Validation” section, you include ajax is an option. Actually, ajax still uses
javascript (the “J” in ajax) which is a client side technology. If users have javascript disabled, any
server-side validation expected to execute through ajax will not work.
In fact, ajax is the perfect solution to your statement further down: “validation should always be
implemented on both the client and server.” Using ajax, you can preemptively validate forms using
the same client-side rules you would use upon form submittal. Then when the form is submitted,
re-validate to catch any errors that sneak through.
Some great ideas in here! I will defiantly be re-exploring my validation practices in the near future.
Radek July 7th, 2009 10:59 am

Another way to determine if the user is a bot, is by simply asking the question if the user is a bot
6
or not. However, if the bot is made for especially that site, it does not work.
Chris Reed July 7th, 2009 11:41 am

7
14 de 23 26/08/2010 10:31 a.m.
ReCAPTCHA always has one word a bit harder than the other. This is because ReCAPTCHA is
helping to digitize books. The harder of the 2 words is a word the digitizing software failed to read.
Here’s a youtube video that explains it very well:

http://www.youtube.com/watch?v=Aszl5avDtek
D. Carreira July 7th, 2009 12:29 pm

Hi!
8
I have an login form with jQuery and validation with php, you can see it here
(Sorry, but the site is in Portuguese…)
What do you think about the form?
Janko July 7th, 2009 12:45 pm

@omtay38: I see what confused you. I actually wanted to say that Ajax is an exception because,
9
although it makes calls to the server, it’s being done by JavaScript, on the client. Thanks for
noticing this :)
John G. July 7th, 2009 1:13 pm

Hmm, there’s much to think about here. I’m using fairly basic forms now, but possibly moving into
10
areas that will require more complex forms and more specific info requested. this post could help
a lot. Thanks!
Matt July 7th, 2009 1:14 pm

I would only disagree with using color alone to indicate errors. You mentioned it as an option. It’s
11
good in combination, but don’t ignore color blind people, I believe many can’t differentiate between
green and red (the typical good/bad indicators). The best solution is to show errors with bold text,
red background (pastel or something that fits your design) and an icon.

@Matt: You are absolutely right, that is what I mentioned – that message should be styled using
12
preferably red color but together with globally recognized icons, especially because of blind
people. :)
Rajeev July 7th, 2009 2:05 pm

Very boring Article
13
15 de 23 26/08/2010 10:31 a.m.

Brian Swartzfager July 7th, 2009 2:07 pm

“Since users need to notice an error message immediately, it is a good practice to position it at
14
the top of a web form, before all the other fields. This will also allow screen readers to easily
access the message.”
That makes perfect sense if the submission page is reload, but what if the validation is
accomplished via JavaScript?
I tend to code my pages such that if JavaScript is turned off and the page is reloaded, the
validation feedback appears at the top, but if JavaScript is turned on and there are validation
errors, the errors are displayed beneath the form/submit button, on the assumption that a) that’s
where the sighted users are on the page anyway, and b) that it would put the new content at the
right spot for the screen reader to pick it up. Whether that’s true or not, I don’t know.
tsilver July 7th, 2009 2:07 pm

Good article. Not sure that popup windows are a no-no. I’ve filled out too many forms where the
15
form didn’t submit and the errors were not obvious. I use a combination of popup message and
highlighted fields. Annoying? Maybe, but not all your site’s visitors are as web-savvy as you.
Regarding captcha, bots like to place URLs and html tags in inappropriate fields. It’s easy enough
to scan for them and reject the submission. I’ve used this technique very successfully to avoid the
need for captcha.
July 7th, 2009 2:21 pm

AG
No validation is good if it doesn’t take in consideration the accessibility factor. There’s no mention
16
in these resources on how to deal with people with impaired vision who don’t see red fields, don’t
understand * if these are not explained in context, or * are of a different color than text in order to
make them more “visible”.
To help these people it makes sense to use instant field validation and clearly explain the
requirements before the start of the form. Using a sound RECAPTCHA is also helpful, but place it
before they need to input the value in the field.

@Brian: Top positioned message should be used whenever possible. For example, in asp.net
17
there is ValidationSummary control that is by default hidden and renders if validation (client and
server) fails. It automatically display list of fields with issues. This can be done with pure
JavaScript as well.
@tsilver: if you filled out too many forms where the form didn’t submit and the errors were not
obvious that is a problem with design of those forms. But that doesn’t means that pop-ups are
good solution. When it comes to filling web forms, there is no differences between advanced
users and beginners – they all hate filling out web forms.
@AG: Sure, solutions are: help text (required), asterisk with help text, required field markers and
16 de 23 26/08/2010 10:31 a.m.

so on.
Kevin Choppin July 7th, 2009 3:01 pm

Nice read and good collaboration, thanks.
18
stelt July 7th, 2009 4:16 pm

This article needs at least a mention of Xforms
19
redheadtn July 7th, 2009 5:12 pm

I’ve been trying to find a good solution for how to make certain fields required IF other fields are
20
filled in.
i.e. – if the user checks this box, then these 3 text fields are required; if they don’t check that box,
those 3 fields are not required.
Anybody heard of any good if/then validation?
Venkatesh July 7th, 2009 6:46 pm

Hi.. good tutorial and explanation. thanks a lot.
21
July 7th, 2009 9:02 pm

Nick Yeoman
Sorry I can’t ready anything that says “Best Practices”, “Trans-Global”, “Plus”, “Extreme”.
22
Those crazy marketing terms bother me.
Yura Zaripov July 7th, 2009 9:26 pm

NIce tutorials. But i’m writing my plugin for jQuery – jQuery.validateThis.
23
Krizalis July 7th, 2009 9:34 pm

I think there’s another captcha which is good and I think you’ve missed out. It’s the ImHuman
24
plugin used on WordPress comment form. Have a look at this link ImHuan.
stu collett July 8th, 2009 12:07 am

Great article. The Ball Park sign up is the one that I find hard to interpret. It’s much better to
25
highlight where a user goes wrong next to the specific area, as it’s far more intuative than having
to look up at the top of the page then to figure out where it relates in the actual form.
17 de 23 26/08/2010 10:31 a.m.

Thanks for sharing
Tom July 8th, 2009 12:09 am

I do believe it’s also a checkpoint of the WCAG accessibility guidelines to have a summary of the
26
errors at the top of the page and clearly highlight each field with an error.
Nice summary!
Simon Day July 8th, 2009 12:11 am

What an excellent article and you do cover pretty much all bases. Another fine read!
27
Raymond Selda July 8th, 2009 12:29 am

Hi SM,
28
Thank you for considering my contact form tutorial as a useful resource. Thank you also Janko!
Cheers! :-)
Emil July 8th, 2009 12:35 am

Nice.
29
The reason Twitter and Facebook omit the confirmation of the password is that if you made a
mistake, you can always use the retrieve password function.
I think that it is more important to double validate the email, even though i would not do it, unless
on a special type of website.
Hanan Weiskopf July 8th, 2009 12:51 am

What a killer survey!
30
The Captcha issue is really a problem. I’d suggest a captcha that would show you a small
illustration of an animal (a cat, a dog, an elephant….) and ask you what it is (radio buttons). Does
anybody like that idea?
I also wonder what do some other commenting folks around here think of my sign up page:
18 de 23 26/08/2010 10:31 a.m.

Ben W July 8th, 2009 1:18 am

@ Hanan Weiskopf
31
There is a captcha like that, KittenAuth. There is an example here: http://www.thepcspy.com
/contact
But those kinds of captchas are still difficult for visually impaired users.
Rusty July 8th, 2009 2:17 am

The answer for captcha is very simple and staring us all in the faces.
32
Make a game of it!
Make it fun to do.
Something simple and quick to do.
Yura Zaripov July 8th, 2009 2:18 am

check password on javascript. have a look at this link
33
July 8th, 2009 3:28 am

Paolo Farago
Great article, I have spent many hours with validation and found a few other items to notice when
34
it comes to validation, for instance trimming fields before submission into a database (either
server or client side), sometimes users enter a space by accident when entering an email for
example and an error occurs and their not sure why because of a space at the beginning or end of
their input. Another validation that I see sometimes on forms is that there is no validation on non
required fields, which doesn’t make sense. I’ve also had to validate for users entering html or
javascript in the field, when an administrator goes on the back end to view the users content,
javascript is executed (typically from text fields with no length limitation or text areas). Something
else I try catching is dummy data. For example if you have a comment text area, I validate to see if
there are any spaces in the text.. obviously if someone is writing a comment and the comment
has no spaces but the length of the content 200, you can be pretty sure that someone just held
down a key for a while. Doesn’t catch everything but helps the administrator…
Always remember “data is gold”.
Janko July 8th, 2009 3:53 am

@Paolo: You made some good points, thanks!
35
19 de 23 26/08/2010 10:31 a.m.

theodin July 8th, 2009 4:16 am

very informative article, good points about the mandatory fields, there’s never any point in asking
36
for information you don’t deem important
Anrkist July 8th, 2009 4:53 am

Would be nice to see a web form article as well. =]
37
Jonny Ram July 8th, 2009 6:03 am

Another good looking, well done Registration/Login with live validation and clear instructions.
38
http://flipick.com
Ara Pehlivanian July 8th, 2009 9:13 am

Thanks for the link to Typecast (and the screenshot!)
39
Janeway July 8th, 2009 10:41 am

I’m sorry, I’m really disappointed. This blog has become all about code. The past several posts
40
are targeted specifically at code and web related issues. Design seems to have taken a back
seat, and now frankly, has just been shoved out the door altogether. Really, really disappointing…
Dan D July 9th, 2009 5:57 pm

Thanks for the referral to drlongghost.com / Validanguage. I saw a nice lil traffic spike thanks to
41
your article.
miketrix July 10th, 2009 2:22 am

I liked that! Very usefull. Thanks.
42
Alexander Bickov July 10th, 2009 4:45 am

I like big input fields
43
bycolor July 10th, 2009 5:18 pm

Janeway, you’re confusing “design” with “graphics”, I suppose.
44
This article really IS about design. Form design.
20 de 23 26/08/2010 10:31 a.m.

Anyway, I bookmarked this.
Albert July 11th, 2009 1:36 pm

Great article! I’ve always been in the look for solid form solutions. Right now Im using
45
simpleForms on my projects and its been working just perfectly for me.
http://www.mattvarone.com/web-design/simpleform-php-email-script/
saved as bookmark
Brente July 12th, 2009 9:13 pm

Thanks, great overview. Readers and Designers : It’s very important to understand that forms are
46
the way you enter ALL information to the web. Email, web form, twitter, etc. It’s all the same. It’s
critical and fundamental that you understand the usability of web forms. it’s the difference between
getting the info you want or not.
HostWisely July 15th, 2009 3:31 pm

I DOnt think server side validation will be an effective solution for low speen internet connections,
47
since the data has to travel from the client to server and back from server to client
Thanks
Web Hosting
Sam Granger July 17th, 2009 4:35 am

ReCAPTCHA also has audio support ;)
48
October 5th, 2009 4:08 am

Nishant Patil
‘Useful resources’ helped me to find want I want.
49
I always check that section in article. It’s really useful
Ryan Grissinger November 3rd, 2009 8:08 am

Great Article. Thanks a bunch!
50
Anna December 21st, 2009 1:43 pm

Very good article and examples!
51
max January 5th, 2010 3:29 am

52
21 de 23 26/08/2010 10:31 a.m.
its realy nice article
max January 5th, 2010 3:33 am

nice
53
Usdating January 10th, 2010 10:26 am

Great info on link building.. It will guide many in building good links on the Web
54
Mujahidh Haseem January 11th, 2010 7:57 pm

great article.which gave me the answers for my lots of doubt.
55
thanx lot.
January 19th, 2010 4:21 am

LINKBUILDING
good job done
56
Renan Campagnaro Soprani March 4th, 2010 2:30 am

I just find your site, and im passed by! I never seem before a lot of usefull information toghether.
57
You are the guy man, thank you for all the articles and information!
Greengeeks June 22nd, 2010 11:24 pm

Thanks for the exhausting article. I especially liked the resources.
58
Greengeeks
Vincent Catalano July 1st, 2010 10:37 am

Thanks for the information! This was a great article with lots of good examples and resources.
59
Excellent job!
Mark July 2nd, 2010 6:22 pm

You don’t need Javascript at all. Use Xforms instead.
60
Allow punctuation in numbers, be it commas, dashes, or spaces. This reduces the chances of a
user error, and don’t just strip them out, validate them. If the punctuation is wrong, there’s an
excellent chance the numbers are wrong too.
And no big drop down list for US states. Everyone in the US knows their own state’s 2 letter postal
22 de 23 26/08/2010 10:31 a.m.

abbreviation. It’s much easier to enter. Most Americans know the postal abbreviations for most
other states too.
23 de 23 26/08/2010 10:31 a.m.

Web Form Validation - Best Practices and Tutorials

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Web Form Validation - Best Practices and Tutorials

Enviado por

Direitos autorais:

Formatos disponíveis

Web Form Validation: Best Practices and Tutorials - Smashing Magazine http://www.smashingmagazine.com/2009/07/07/web-form-validation-best...

Web Form Validation: Best Practices and Tutorials

1 de 23 26/08/2010 10:31 a.m.

2 de 23 26/08/2010 10:31 a.m.

Facebook Required in Web Form Validation: Best Practices and Tutorials

Last year, we conducted an survey on Web form design (http://www.smashingmagazine.com/2008/07/04/web-

3 de 23 26/08/2010 10:31 a.m.

The second part of our survey (http://www.smashingmagazine.com/2008/07/08/web-form-design-patterns-

4 de 23 26/08/2010 10:31 a.m.

By providing red inline messages or markers next to every invalid field

By changing the color of field labels

By providing error tips (balloons) next to each field

Validation upon submit

5 de 23 26/08/2010 10:31 a.m.

Real-time validation (or instant validation)

6 de 23 26/08/2010 10:31 a.m.

An interesting finding in the second part of SM survey (http://www.smashingmagazine.com/2008/07/08/web-

Better safe than sorry

7 de 23 26/08/2010 10:31 a.m.

Help indicators (tooltips)

8 de 23 26/08/2010 10:31 a.m.

Masking and reformatting user’s input

9 de 23 26/08/2010 10:31 a.m.

10 de 23 26/08/2010 10:31 a.m.

Are you human?

Simple captcha requires an answer to a semantic question.

11 de 23 26/08/2010 10:31 a.m.

Dynamic JavaScript Form Validation (http://www.leigeber.com/2008/04/dynamic-inline-javascript-

Validation Hints for your form (http://www.askthecssguy.com/2007/05

PHP Contact Form with jQuery Validation (http://www.raymondselda.com/php-contact-form-with-jquery-

12 de 23 26/08/2010 10:31 a.m.

Rules of thumbs in web form validation design

Never provide validation feedback on a single page or in a popup alert.

Tags: forms, validation

13 de 23 26/08/2010 10:31 a.m.

Tom Huynh July 7th, 2009 9:42 am

July 7th, 2009 9:51 am

Ken July 7th, 2009 10:02 am

Shawn McCool July 7th, 2009 10:02 am

omtay38 July 7th, 2009 10:24 am

Radek July 7th, 2009 10:59 am

Chris Reed July 7th, 2009 11:41 am

Here’s a youtube video that explains it very well:

D. Carreira July 7th, 2009 12:29 pm

What do you think about the form?

Janko July 7th, 2009 12:45 pm

John G. July 7th, 2009 1:13 pm

Matt July 7th, 2009 1:14 pm

Janko July 7th, 2009 1:24 pm

Rajeev July 7th, 2009 2:05 pm

15 de 23 26/08/2010 10:31 a.m.

Brian Swartzfager July 7th, 2009 2:07 pm

tsilver July 7th, 2009 2:07 pm

July 7th, 2009 2:21 pm

Janko July 7th, 2009 2:46 pm

16 de 23 26/08/2010 10:31 a.m.

Kevin Choppin July 7th, 2009 3:01 pm

stelt July 7th, 2009 4:16 pm

redheadtn July 7th, 2009 5:12 pm

Anybody heard of any good if/then validation?

Venkatesh July 7th, 2009 6:46 pm

July 7th, 2009 9:02 pm

Yura Zaripov July 7th, 2009 9:26 pm