maxlength Hinders Usability

It’s true.  Everybody needs a little extra length — on their maxlength attributes.

Setting maxlength to the maximum allowed field length is common practice.  Which often leaves dormant validation on the server, just in case.

However, the dormant validation presents a potential usability problem.  There’s no opportunity to trap user errors.  If there’s a maximum length for a field, let your users exceed it.  You’ve already got an error message ready.  You might as well use it.

It might be tempting to think “prevention is better than cure”, but that’s not true here.  Users don’t always notice their input being ignored when they type, especially on password fields, and to a lesser extent on fields that are not wide enough to display all of its value.

Here are two real-world examples of the maxlength trap:

Scenario #1

At the end of an enrolment process, users were issued a system-generated user ID (12 characters) and separately sent an activation code (11 characters) by post.  Users were given 3 attempts at activating.  After three failures, they would have to enrol again.

The use of maxlength="11" on the activation code field resulted in many helpdesk calls from de-enrolled users, who hadn’t waited for their activation code to arrive by post.

So, if they weren’t in possession of an activation code, what were they using?  They were using their user ID, and perhaps they didn’t see maxlength in action because:

• They were looking at their scribbled down user ID.
• They were looking at their keyboard.
• They used copy/paste.

The system accepted the first 11 characters of their User ID as a valid activation attempt.  It gets worse, users then re-enrolled, which of course generated a new activation code, and then waited for it to arrive in the post.  Of course, their old activation codes arrived too...

Scenario #2

A department decided to introduce a minimum and maximum password length policy.  So the account creation and change password processes were amended to use maxlength to enforce the policy for all new passwords.  The login page did not use maxlength so existing users with longer passwords could still log in.

The introduction of maxlength resulted in a few users not being able to log in to the system.  Why?  Because they believed their password was longer than the system did.  They did not notice that their new password was being restricted by maxlength.

maxlength = max length + 1

The solution is simple.  Just set the maxlength attribute to one more than you allow, just one, no need to get carried away.  Now you can easily detect long fields and prevent users from falling foul of the maxlength trap.