What’s wrong with the web forms these days?

[Tweet : nvALT]

Filling out forms on the web is an inconsistent and often infuriating experience. What follows are some of my major complaints. I’m not a UX professional, though as a front-end developer it’s definitely been part of my job. This post is written from a user standpoint, though. A frustrated, annoyed customer of e-commerce websites, a user who regularly signs up for services, and one who even occasionally fills out a contact form.


A lot of form issues are largely due to over-designing. It happens in Mac apps sometimes, too, where developers want to “spruce” up standard controls and end up breaking standard behavior. While the default controls and behaviors might not always be perfect, it’s a language that users understand.

Bad HTML practices include poor use (or lack of use) of tab indexes, or forms with “fancy” Javascript that breaks the default keys used to focus fields or navigate dropdown selections. This is basic functionality that should never be broken. Even beyond accessibility concerns, pissing users off during checkout on an e-commerce site is just bad business.

If you feel the need to change the design of a form field (and I get it, defaults are ugly and often wildly inconsistent between browsers and platforms), don’t change the functionality. This is especially true of dropdowns. It’s possible to build an autocomplete combo field that is still keyboard navigable. It’s possible to create a form field with placeholder text that becomes a label when the user starts typing without breaking tab index. It’s possible to create custom input fields that still indicate focus.

I think indicating focus on a field might be the second most frustrating issue commonly found in web forms. I never fill out a form by clicking each field; I tab between them. Tab order is annoying enough, especially when most elements can be focused with the tab key but custom dropdown fields are skipped, but it’s worse when I tab and have no idea where the cursor has gone. Highlighting the focused field with an outline is a standard part of the user’s language. Don’t break it without providing an obvious alternative, and for the love of jebus don’t remove the highlight completely.

Animated Forms

Stop this. I recently went through a signup process for Minnesota’s ACA insurance website. It was, if I recall, about 8 pages long. They separated the pages into multiple screens, and added a Javascript animation between them. Worse than just being slow and ugly, it could sometimes break when the crappy Javascript caused too much overhead in the browser. Refreshing the page would erase all of your current progress. If it had been anything other than insurance I absolutely had to have, I’d have been gone after the first try1.

As an aside, the revamped ABC app on Apple TV has similar issues. They added an animated splash screen on startup, complete with annoying and loud audio. Then every menu option leads to an animated splash page before you get to the destination, and you have to hit the select button twice to actually get to the next menu. It’s infuriating, and I rarely use it anymore.

Field Validation

This one is huge for me. When done correctly, inline validation can be wonderful. If you’re going to validate elements such as phone numbers, though, auto-formatting while the user is typing is important for clarity. Frustratingly, though, some automatic phone number formatting (where it will put parenthesis around the area code, auto-add region, and hyphenate the rest properly) doesn’t allow backspacing. On some sites I’ve had to completely leave the field and come back to start typing again. This entirely defeats the purpose. Use formatters, but make sure they work.

If your form validates live while the user types, provide a message letting them know what’s expected. For example, while typing an email address and validating it while typing, add a “Please enter a valid email address” label until it’s complete. But really, don’t do this at all. Validate it when the user leaves the field, and remove the error indicator when it regains focus. Showing an error while typing causes me to have a “just hold your got dam horses” reaction. I don’t need to feel judged before I even finish entering the information. I have no issue with password fields that show a strength indicator, but that’s a different story because it’s showing helpful information and doesn’t make me feel like someone is criticizing my typing speed.

Live validation also fails when it doesn’t account for autofill or paste. Recognize the Ctrl/Cmd keys as valid keyup triggers, and check the entire field again when it happens.

Email address validation is easy. Or it should be. There’s a very simple regular expression to determine if something is a valid email address. It should accept every legal character. I like to use Gmail aliases (email+alias@gmail.com) on sites where I want to easily filter junk mail to any address I provide, but I’d say about 30% of email validators don’t recognize the “+” symbol.

Even worse, and my number one complaint on the web, is email fields that don’t trim trailing whitespace when validating. This was never a big deal to me before iOS text replacement, but now any time I use my @@ shortcut to insert my email address, it adds a space after the replacement. Far too often I have to manually remove that space or the form will declare an error on submission. This is ridiculous. A space is never legal at the end of an email address, and can always just be trimmed off by the validator or processor. It can be done with Javascript prior to submission, or just let the processor do it when handling the form on the server side. Some sites automatically trim it off as you type, which is a good idea, but now that I’ve developed the habit of always hitting backspace, I frequently delete the last character of the email address. Thus, lack of consistency between forms becomes as big an issue as the original problem.

Less often but just as frustrating, I see forms that don’t properly update after an invalid field is corrected. This is especially horrible when the submit button is disabled until the form validates. This is a downfall of only validating on blur (losing focus), and I feel that submit buttons should never be disabled. If the user has corrected the field but not clicked/tabbed out of it, the submit button should handle validating the focused field.

Mobile Impropriety

There’s the obvious part of making forms compatible with mobile devices: responsive design. If I have to zoom and scroll the screen to fill out the form, you’re doing it wrong. You’d think this would only be an issue on older sites, from a pre-smart-phone era, but it’s not.

It’s also quite easy to specify the type of information a field is requesting. Doing so means that on mobile platforms, an appropriate keyboard can be displayed. When a form asks me for a purely numeric input and doesn’t give me the numeric keyboard on iOS, I have a negative emotional reaction. You wouldn’t like me when I’m angry.

I know that this post isn’t going to make a big difference in the vast ocean of the web. I just got bored with silently shaking my fist.

  1. That story gets even worse, as after the 15 minutes of form filling, I got a server error on the last page and had to do the whole thing again. Ultimately there was no verification that the form had been accepted and required a phone call anyway.