Labels in input fields aren’t such a good idea

There’s something that’s been bothering me lately. It seems to be some kind of form interface trend where the labels for text inputs are placed inside the fields themselves.

Example:

a form field where the label is shown inside the text input field

There might be some pros

Admittedly, this makes an interface slicker. It saves space where you’d usually have a label, then some padding, then the input field and probably a load of padding around the lot.

But what you’re gaining in a clean look, you’re completely losing through a total lack of usability.

So, I’m an interface idiot

You know the lowest common denominator, idiot users that we design easy interfaces for? The ones that need to be led by the hand, step by step, across your design to get to the call-to-action?

That’s me, that is. I am an incredibly naïve user. I skim read, I’m forgetful, I barely pay attention and when I do I’m easily confused.

This is what I see

Here’s an example from a site that is otherwise a shimmering beacon of awesomeness over the wasteland that is the web:

Project Noah

As part of Project Noah, you upload photos of nature. The aim is to identify the creature or plant in your photo, and part of that is providing the relevant links to that species’ page on Wikipedia and the Encyclopedia of Life.

Reference URLs on Project Noah, where the label is shown inside the text inputIt’s a beautiful interface, but I have an issue. I’ll go and paste in a URL, then I’ll select the other text box:

Reference URL input on Project Noah, where one URL input is filled in and the other is focused but emptyThen I have this thought:

Did I put the URL in the right box? Is Encyclopedia of Life the top input or the bottom input? How do I find out?!

It seems pedantic, but I genuinely do get this sense of panic that I’m entering it wrong and there’s no way to check that I’m doing it right. I have to click back outside the input box, so it no longer has focus, to check what the label was again.

WordPress

Another example from an interface that I use on a regular basis and generally love. In the 2.8 redesign of the WordPress admin, which is generally a huge amount better than before, the post editor title lost it’s label.

Before:

WordPress 2.7 post editorAfter:

WordPress 3.1 post editor

The problem is that the first input box you’ll click into is the top title input. It actually auto-focuses, and some clever script means that it puts the label back in after the auto-focus, but then the second you start typing you’ve lost that label. If you start typing, then backspace because you made a mistake, you’ve lost that label:

WordPress 3.1 post editor with no title label

Designers often make assumptions

It’s all very well to assume that the user will remember that the title belongs in that box, but what if it’s somebody has cognitive difficulties? What if it’s someone that’s just an idiot like me who clicks into boxes without paying attention to the label first?

It started as an example

Originally we used pre-entered text in an input field as an example, to help users understand the input required. WordPress itself has a great example of this on the Writing Settings page in the WordPress admin:

WordPress Writing Settings uses text inside input boxes to help users understand the input required

These fantastic triggers mean that users who aren’t necessary technically minded can see the type of input that’s required to set up post via email, match that to the information they have and easily enter it into the boxes.

When did these useful triggers become a way to hinder users, instead of help them?

The rise of the HTML5 placeholder leaves room for abuse

HTML5 has a fantastic new form input attribute for adding placeholder information into the input boxes so that you can easily give your users cues without the need for JavaScript or CSS hacks:

HTML5 form snippet

Edit:name” should actually be “id” here in the text input, I always get those two mixed up! (Thanks Mike, for the heads up)
HTML5 form previewI’m concerned that people will misuse or misunderstand the placeholder attribute as a way to replace form labels

But it’s not the same thing!

A label tells you what a form input requires, a placeholder gives you an example of the input required.

I’m no accessibility expert, but I can imagine the loss of a label isn’t going to help with screen readers. Forgetful people and people with cognitive disabilities will also struggle.

Please think of daft people like me

It might beautify your interface and make you look modern and cool, but a label isn’t the same as a prompt. We need to keep our forms as clear as possible and not let cool technology take over the understanding of basic user behaviour.

I don’t know if I’m alone in struggling with using these inputs, but I’d love to know everybody else’s opinions.

43 comments

  1. Great post Laura! I’ve experimented with placeholders instead of labels but any aesthetic gain is totally lost in usability. I have exactly the same problems you’ve highlighted. If us web designers/developers can’t handle it – what about everyone else? I say use both labels and placeholders.

    Reply

    • I agree that the use of both labels and placeholders is the way to go. If you are going to drop one, it should be the placeholder and the label should be more descriptive. But ALWAYS have a label. And don’t forget the ‘for’ attribute.

      Reply

  2. I’m definitely on the camp of using both labels and placeholders, but not placeholders by themselves. I recently tried manipulating a search field on my blog to remove the search button and place the word “Search” as a label inside the field. While it looked clean, it was confusing as to what it was after you click inside the box, and it wasn’t obvious how to send the search query (mainly because…well, there was no longer a search button).

    Not everything is obvious to everyone. Even though the design *could* look nicer without labels, a true designer will find a way to make them work visually.

    Reply

  3. As an Interaction Designer, I’ve been tackling and retackling this very problem in my forms for a while now.

    The current solution to the “activated, anonymous” problem involves standard HTML features, with a dash of jQuery to smarten things up.

    1. Layout your form with paired label and input combinations as normal.
    2. Use a safe offscreening technique on your labels to maintain accessibility and satisfy your visual requirements.
    3. Add the label text to each input as a ‘title’.
    4. Add a class of “hint” to each input.
    5. Use a bit of jQuery that, on load:
    a) sets the “value” of all your “hint” inputs to their title text,
    b) adds a class of “hinted” for that light grey text effect,
    c) set the “focus” event to remove the “hinted” class and clear the “value” *if* it’s the same as the title on focus,
    d) set the “blur” event to reinstate both the “hinted” class and the “title” as value *only* if the value is empty.

    It’s a little bit of faff, but I think it’s worth it for the experience benefits. If your user mouses over an input, they’ll get a tool tip (because of the title). And if they click out of the input without entering anything, they’ll get the hint back again.

    And, for an added nicety, you could set a corresponding icon as a background on each input on focus, too – particularly effective if you need to have several hinted fields close together.

    Anyway, hope some of all that is of use. :)

    Reply

  4. Oh, and one final step!

    6. When your form submits, make sure you empty every “hint” input if its value matches its title; otherwise you may cock up any validation you might otherwise have on your form.

    Reply

  5. Hi Laura,
    I’m passionate about accessibility and usability, and I agree completely; this trend for ultra clean interfaces is causing problems for people who might struggle with this thing called the web.

    These days some of the newest users are those who have been reluctant to do this “internet thing” because it is “complicated and scary”. We shouldn’t be making it any harder than it is. There is huge value in keeping things familiar, especially when it requires non-trivial interaction from the user.

    Thanks for raising the subject, it’s important not to forget the user in the pursuit for beauty!

    Mike

    Reply

  6. In these cases, using the title attribute on input fields helps (in a small way) since that is seen on hover. Quite simple to do but not always done (I admit I forget sometimes!)

    Reply

  7. By the way, the HTML5 example has an error.

    The for attribute of the label can only take an id as a value. But the corresponding input doesn’t have an id. See the HTML5 specification.

    Reply

    • Yes! I realised this when I wrote out a massive form with every single input using name= instead of id=. Always get those two mixed up :s

      Reply

      • dotnetCarpenter

        Someone noted on some website that I forgot, but it’s pretty damn useful. Put your inside your and use don’t have to specify for=”[id of input]“. And never have to remember the difference between name and id. Except that the server guy receiving the form data will appreciate you and give you coffee if you have sane name properties.

        Reply

  8. Good post – and I agree! There’s a worrying trend of people conflating label and placeholder, and an even more worrying one of people thinking that having placeholder text is in any way a replacement for a label element.

    I checked the WordPress example you mentioned, and they do include the input element which is good. In fact it looks like quite a clever implementation. The label element is actually absolutely positioned on top of the text input, rather than text written to the input’s value property. Then when you click on the label it focuses you into the input.

    Having said that it looks like they handle the no JavaScript situation less well. The label element is hidden and there is no visual hint as to what the field is for at all. I tried it with Voice Over switched on and it does read the label for the title input which is good, but then there is no label at all associated with the textarea for the body of the post, and the screen reader is completely lost.

    Reply

  9. Mats Svensson

    Putting help-texts or labels INSIDE the texfields,
    either with HTML5 placeholder, or some hack,
    is F useless and should NEVER be used.

    I have never EVER ever seen it done in a way that doesn’t break when you fill a field by drag&drop.

    Example:
    The help text in the field says “Name”.
    You select the text “Smith” somewhere and drag it and drop it in the field.
    It now says “NaSmithme” or similar.

    I guess you could build something that makes the field transparent , puts the help-text under (lower z-index), and then hides the help-text when the user start to fill it out.

    But NEVER actually put the help-text inside the field itself, like its always done now .
    This madness must be stopped!

    Reply

  10. Hi,

    One other thing missing is the ‘affordance’ of the field – during scanning behaviour.

    For example, adding text into a search box simply makes it less visible on the screen so you’re hobbling your interface discoverability.

    We’ve found the best balance is out of field help text – supporting but not interfering with people’s ability to evaluate the size, information required and type from the input box itself (seen in eye tracking + see http://www.lukew.com work).

    I think that if you test this stuff, you’ll find all sorts of problems. Visual clarity in the designers eyes does not translate to usability or conversion in a product – this stuff often looks nice and clever but can suffer from interrupting already known patterns for using an interface that people look for (e.g. an empty bloody box, not something filled with text).

    I had a similar discussion regarding phone formatting recently – splitting it all into nice little boxes for USA phone numbers looks pretty but imposes work and friction on the viewer – regardless of your design intentions. In that case, lots of clicks and eye focus work would have been imposed on the user, even though it looked ‘nice’.

    C.

    Reply

  11. I totally agree with your POV here. It’s the whole reason I made this jQuery plugin! https://github.com/remybach/jQuery.superLabels

    Reply

  12. Hi Laura,

    Great post. I’d be interested to hear what your point of view would be regarding the use of tool tips to display the form label in the event that the placeholder label is either replaced with input text or removed as in your WordPress example?

    Reply

  13. Excellent article!
    Forms are always a struggle. I’ll keep this in mind when making one.
    Thank you :)

    Reply

  14. Great article! “Web Form Design” by Luke Wroblewski goes over many of these exact examples!

    Reply

  15. Sorry guys I just didn’t have time to read all the comments to post mine, so my apologies if it’s a repost of someone else’s idea.

    I think this is a review of unfinished or undersigned examples. Or they are just buggy, and those bugs are the problem, not the design. Here’s why:
    * When I focus on the field, this should not make the label go away, the label should go away only when I start typing.
    *After not entering any text in that field and removing the focus, the label would remain, according to the above. Thus confusion cleared.
    *This design will obviously be not a good idea where all the fields look the same and there are plenty of them. It works best on login forms, where you can save some space and make people feel great about using your app.

    To sum it up, if the bugs are fixed and this concept is not over abused, it is a good idea :)

    Reply

    • +1 on that.

      Include labels for accessibility reason, but visibility of them isn’t necessary if you’re using the placeholder attribute. The placeholder text is preset on :focus, but hides after you start typing.

      Reply

  16. Good read, I thought I was the only person who does things like this!

    A few weeks ago something similar happened to me and I just had to refresh the page to double check that I knew what was going on.

    Reply

  17. Hi Laura,

    I agree with you 90%. The label is a much needed element that seems to be missing from a lot of web content. However, I would also like to comment that I think there are cases in which a label is not needed. For example, if a search field has a “search” placeholder and a search icon, a user will know what they’ve typed in there even once the placeholder text is gone. This would be similar to anytime a form contains icons.

    Another example is when the fields are very straightforward. For example, the contact form on my site has name, email, message. Once a user types in their name, for example, they would remember and know that the field was their name.

    I totally agree with the sentiment of your article that form labels are still needed and shouldn’t be removed just for aesthetics. Hope you don’t mind my devil’s advocate comment. :)

    Reply

  18. Well, thank you! Finally, someone writes it down, as simple as it should be.
    Win! :)

    Reply

  19. Nice point, people tend to forget that technology should help people :)

    Reply

  20. Nice article, Laura (and nice blog). It actually inspired me today while polishing a backend interface (in WordPress). You made me realize that it’s likely time to finally fix my own contact page ^__^ Thanks!

    Reply

  21. Nice article, Laura, thanks for sharing. It inspired me right today while polishing a backend interface I’m developing (in WordPress). And it made me realize that it may be finally time to rethink my contact page! :-o Cheers!

    Reply

  22. Aaron

    I agree with this post but always liked the clean look of using placeholders.

    I wrote a jQuery plugin that I think largely solves this problem. It works by dropping the label down below the field after it has focus or a value so the label is still visible, while maintaing the clean look of placeholders before the form is used.

    You can find it here along with a demo: http://jacware.github.com/fancyplaceholder/

    Let me know what you all think!

    Reply

  23. Great Article! This makes complete sense to me and you hit the points well. I can’t count how many times I forget what to put into a form.

    Reply

  24. It always drives me crazy when a form only has placeholders that go away on focus.

    I really like the aesthetic of having the label inside the input field – just don’t hide it on focus. Here’s an example of how I implemented it on one of the projects I worked on: goo.gl/pzdkg

    Reply

  25. Spencer Edwards

    Excellent post! I agree that this rising trend of only using placeholders as labels is actually knocking down the usability of a form. I tend to use both as well, as one does accent the other. There are ways to get a slick design while using both.

    Reply

  26. A quick update on this subject: Brad Frost has written up a great potential float label pattern (designed by Matt D Smith) on his website.

    Reply

  27. Stomme poes

    One disadvantage of that is, you’re using titles.

    -Read out by most screen readers (so we get label then title instead of just label)

    -HTML5 form validation is mixed, but titles may be added to the default browser error messages. This might actually work out nicely (if the error is, the user did not follow the title/label instruction) but for example in Opera it gets silly.

    But you could likely do very similar to what you have, using the label.firstChild or similar… saving titles for the other, above uses.

    Reply

  28. @stomme poes

    Thanks, that’s good to know. I wasn’t sure quite how 100% reliable/helpful this would be across all browsers and assistive technologies, so it’s great to get this sort of insight.

    I’ll update my approach as you’ve suggested here in future. Much appreciated!

    Reply

Leave a Comment

Your email address will not be published. Fields marked with * are required.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>