13 ms·
Labels in input fields aren’t such a good idea
- talmand 14y agoI once ran into this problem of disappearing labels in the input fields leading to incorrect submissions. The design didn't allow for proper labels, being a standard first name and email address form in a small space, and the client wouldn't budge on it. Often we would see people putting their email address in the first input field. Eventually I used the email address verification Javascript from the second field on the first field. If an email address was found, it alerted to point that out and asked for first name in the first input while moving the email address to the second, correct input.
- steveax 14y agoYes, really bad trend. In addition to the usability issues the article mentions for sighted users, using placeholder without labels leaves screen reader users without any clue what the input is for.
- saravk 14y agoGood point about the screen reader. I've never considered it before. Thanks. Personally i dont like using labels and instead use placeholders with tooltips in my forms. But now i might have to reconsider that approach.
- jrabone 14y agoIt's all fun and games until the National Federation of the Blind sues you...
- pc86 14y agoDoes the ADA apply to websites hosted within the US?
- oftenwrong 14y agoSome quick Wikipedia research suggests to me that it depends on the exact circumstances, but in general it seems that any prominent company is vulnerable to lawsuits over website accessibility. http://en.wikipedia.org/wiki/National_Federation_of_the_Blind_v._Target_Corporation http://en.wikipedia.org/wiki/National_Federation_of_the_Blin... http://en.wikipedia.org/wiki/Access_Now_v._Southwest_Airlines http://en.wikipedia.org/wiki/Access_Now_v._Southwest_Airline... http://en.wikipedia.org/wiki/Ouellette_v._Viacom_International_Inc.#ADA http://en.wikipedia.org/wiki/Ouellette_v._Viacom_Internation... http://www.dralegal.org/impact/cases/smith-et-al-v-hotelscom http://www.dralegal.org/impact/cases/smith-et-al-v-hotelscom http://www.w3.org/WAI/EO/EO-Policy-USDOJ http://www.w3.org/WAI/EO/EO-Policy-USDOJ
- protomyth 14y agoThe courts seem to think so http://www.dba-oracle.com/oracle_news/news_web_sites_ada_compliant.htm http://www.dba-oracle.com/oracle_news/news_web_sites_ada_com... http://www.law.com/jsp/article.jsp?id=1202424114568&Settlement_Over_Targets_Web_Site_Marks_a_Win_for_ADA_Plaintiffs&slreturn=20130104135043 http://www.law.com/jsp/article.jsp?id=1202424114568&Sett... http://www.webstandards.org/2006/02/14/nfb-vs-target-in-perspective/ http://www.webstandards.org/2006/02/14/nfb-vs-target-in-pers...
- randomdata 14y agoAside from the other problems, placeholder is a standard attribute. If it is problematic for a screen reader to read that attribute, wouldn't that be a problem with the screen reader, not the HTML page?
- mjhoy 14y agoExcept that placeholder != label, semantically. The spec says: The placeholder attribute should not be used as an alternative to a label. For a longer hint or other advisory text, the title attribute is more appropriate. http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-placeholder-attribute http://www.whatwg.org/specs/web-apps/current-work/multipage/...
- im3w1l 14y agoWhat about this solution: http://stackoverflow.com/a/1755802 http://stackoverflow.com/a/1755802 Have labels, but hide them with css.
- account_taken 14y agoOnly good for simple login form of two fields. Most everyone knows that is login name and password.
- SquareWheel 14y agoAh, but was the first form username or email? You have to unfocus the input to check.
- adamauckland 14y agoAlso do I have to add the @domain.com in my web email login or does it know because it's a hosted service? As a user I'm confused.
- harshreality 14y agoIf it's a single-domain hosted email provider, a well-designed system would accept either the local part or the full email address, but using the full email address would avoid problems in the future in case the service expands to a second domain. The local part of an email address is not an email address. If it asks for an email address during login, assume it means an email address.
- saravk 14y agoYou can always prepend the form input with an appropriate icon (or even text). http://fortawesome.github.com/Font-Awesome/#examples http://fortawesome.github.com/Font-Awesome/#examples
- account_taken 14y agoUmm it starts with a placeholder so you know if it's user name or email. If you get it wrong an error is displayed. Kind of hard to mess up a login form.
- MartinCron 14y agoA trend that I just adore is letting people log in with either username or email on the same form, so it doesn't matter.
- cantlin 14y agoIt can be done right. * Use label tags in the initial render, JavaScript them into placeholders. * Do not remove the placeholder until the user has both focused and started typing. * Try and animate the placeholder to a safe location rather than removing it. * Restore the placeholder if the user pauses after removing their input. Personally, I favour example input in my inputs (as the author suggests) rather than embedded placeholders. Still, I can understand the assault on clutter from many designers, and I don't think the technique is so much bad as open to crappy implementations.
- ams6110 14y agoopen to crappy implementations I think that is the key point. A conventional label is simple and doesn't need all this extra support to be helpful to the user. I've never really liked the "label in the field" trend except in really simple forms where there's almost no chance for ambiguity anyway.
- adamauckland 14y agoAs one of the commenters on the linked article points out: this still breaks if you try to drag and drop text into the textbox unless you've been very diligent with the events to move the label out of the way. I never really thought why they were called 'placeholder' before but it makes sense; they are not labels, they are examples.
- EvilTerran 14y agoI've seen placeholders implemented as a separate element, positioned over the input with CSS, which neatly sidesteps most of the issues caused by having the placeholder text actually as the input value. It has its own problems, no doubt, but seems to work a lot better overall.
- jasonlotito 14y ago> Try and animate the placeholder to a safe location rather than removing it. There is no try. If you cannot move it to a reasonable location, do not use this method. Also, on other note: username is Not an email address. Do not ask me for my username when you really mean email address. Oh, and one more thing. Let me know (or make it easy to find out) what special rules you require for passwords on your login page. Your site is annoying because you probably require some special combinate of letters and numbers and possibly something else, which means I have to figure out which password pattern I should be trying.
- tocomment 14y agoSpeaking of this, what's the simplest way to add in-field labels to an existing form? (Assuming in not worried about the issues in this article)
- xarien 14y agoJust set the placeholder attribute. You'll need some js if you want to support browsers which do not process the attribute. I use Jason Garber's jquery plugin to imitate placeholder for browsers which do not support the attribute.
- talmand 14y agoAre you asking about adding in these labels to an existing form with HTML that you cannot change? Meaning, running Javascript across the form to inject placeholders into the existing fields?
- remybach 14y agoIf you're using jQuery, check out my plugin: https://github.com/remybach/jQuery.superLabels https://github.com/remybach/jQuery.superLabels.
- ulisesrmzroche 14y agoThis claim is useless without any data backing it up. Where's the proof that this is even an issue? If you're targeting screen-readers, then that's a progressive enhancement issue. If you just want to guide the user, then work on giving the user more information sooner. edit: I'm not saying you should use placeholders as replacements for labels, this will probably invalidate your HTML.(guess). I'm saying this is not a very good point until it's proven to actually get in the way of the user experience. I don't think we should treat our users like idiots, because they're not, so any time that gets included in a design decision, (the assumption that our users are dumb), I already know it's a bad one. Plus, if you have too many fields in your form, that you need to start adding labels for clarity, you should probably split that up and multi-page it.
- nirvdrum 14y agoIt adversely affects screen readers, so on the outset it is an issue. But the post is about the qualitative nature of the problem. I suppose this manifested as a quantitative problem with the time-to-complete task increasing. I agree it would be nice to see an actual user study comparing task completion time. I'd imagine there's already something in SIGCHI on the efficacy of disappearing prompts.
- ulisesrmzroche 14y agoIt does affect screen readers, but that's a progressive enhancement issue. You shouldn't be degrading the experience for someone who does not need one.
- steveax 14y agoSupporting screen reader users is not "progressive enhancement", rather, it is basic and essential.
- ulisesrmzroche 14y ago"Progressive enhancement is a strategy for web design that emphasizes accessibility, semantic HTML markup, and external stylesheet and scripting technologies. Progressive enhancement uses web technologies in a layered fashion that allows everyone to access the basic content and functionality of a web page, using any browser or Internet connection, while also providing an enhanced version of the page to those with more advanced browser software or greater bandwidth." http://en.wikipedia.org/wiki/Progressive_enhancement http://en.wikipedia.org/wiki/Progressive_enhancement @steveax, you're misunderstanding the concept. The idea is that users with screen readers will see labels, but those who don't can omit them. Progressive enhancement means building for screen readers first, for example, and progressively enhancing the experience for those who can support it. You forgot to include this part, bro. "... while also providing an enhanced version of the page to those with more advanced browser software or greater bandwidth.""
- cheezebubba 14y agoI wrote an iPhone app with placeholder text, but users kept leaving fields blank, thinking that the app was autofilling them. Ended up ripping all the placeholder stuff out.
- narag 14y agoCongrats for realizing and fixing it. A related problem: Chrome starts with "about:blank". When I start typing, it doesn't go away, so I have to manually select the text before.
- orangethirty 14y agoCorrectly used labels improve conversions.
- jaggederest 14y agohttp://davidwalsh.name/html5-placeholder http://davidwalsh.name/html5-placeholder Placeholder attribute in HTML5 handles this right - if you don't have anything in the field, it reverts to the placeholder text.
- Pewpewarrows 14y agoThat's only half of the argument. The other half being that, after having text in there (say, in the edit form of a CRUD app), your user no longer remembers what that field was supposed to represent to begin with.
- jaggederest 14y agoProbably browser-specific, but some browsers will show the placeholder or label with a hover, as well.
- gedrap 14y agoBut hovering to see the label is not intuitive at all
- Dylan16807 14y agoIt's not? The world of computers is filled with hovering for descriptions and details.
- gedrap 14y agoIt is but an input field is not really an element you would hover for more info. If additional info for the user is required, some question mark icon next to field does the job well because it yells 'hey! something might be confusing or not so obvious'. I might be an exception but can't recall a case when I would hover input field.
- julian37 14y agoYeah but that doesn't make it a good idea.
- mokit 14y agoWe had the same problem and our frontender came up with a nice solution. The label is inside the textfield but when focused, the label moves to the right of the textfield. An example can be viewed here: http://www.rainpharma.com http://www.rainpharma.com (the form in the center of the page)
- asmosoinio 14y agoIt causes a bug on the iPad browser: when tapping the field, my cursor goes to the right side, within the label. Which brings me to my opinion: often it is better to just not mess with things like this. Keep it simple.
- lukifer 14y agoAnother reason not to do this: browser autofill. Now and again, the browser will guess wrong on what value to insert, and now the user won't know what's supposed to go there. Even if they clear the value, no user will assume that de-focusing the input will reveal the label.
- byroot 14y agoI don't know for others but both Chrome and Firefox hide the placeholder only when the input value is non empty. So it do not disappear when to give focus to the field.
- Indyan 14y agoExactly. Off late, I have been running into this issue a lot. I use Lastpass to manage my authentication information, and I always let it auto-fill new signup forms. It's an incredibly smart piece of software, and gets things right most of the time. However, on occasions when it doesn't fill up a everything correctly, not having a label is a big disadvantage. I have to first clear out the text, de-focus the form-field (Tab or Shift+Tab), then read the field name and come back and fill up that field.
- SeoxyS 14y agoYou can have the best of both worlds (quick and dirty): http://jsfiddle.net/UMfAy/1/ http://jsfiddle.net/UMfAy/1/ <body> <form> <div class="cool-label"> <label for="name">name</label> <input id="name" type="text" placeholder="John Doe" /> </div> <div class="cool-label"> <label for="email">email</label> <input id="email" type="text" placeholder="john@doe.com" /> </div> </form> </body> body { background: #eee; } form { width: 250px; margin: auto; margin-top: 50px; } .cool-label { border: 1px dotted rgba(0,0,0,.3); background: #fff; margin-bottom: 10px; width: 100%; } .cool-label label { width: 60px; display: inline-block; text-align: right; float: left; height: 100%; margin-top: 5px; } .cool-label input { border: none; background: transparent; width: 175px; /* 250-70-5 padding */ padding: 5px; padding-left: 70px; margin-left: -60px; } .cool-label input:focus { background: rgba(0,130,255,.1); outline: none; }
- talmand 14y agoNice. But... You can use the labels themselves as the container for the inputs which leads to simpler markup by removing the divs. Not that it makes much difference in your example though.
- CCs 14y agohttp://jsfiddle.net/UMfAy/3/ http://jsfiddle.net/UMfAy/3/
- gbog 14y agoSorry but no. We are used to boxes surrounding actionable fields where we can type in content. Here your pseudo-fields is half editable, half not editable, which is weird. The "delimiting an active field" purpose of the visible box is broken. Maybe if you are Amazon or Google, you can try to implement such a thing, if you have strong reasons to believe it will help users. But if you are not Amazon or Google, you should avoid surprising your users with some weirdness, and just stick to proven UX.
- UnoriginalGuy 14y agoThe video learning site "lynda" has a really good set of videos on this: "Web Accessibility Principles" and "Improving SEO Using Accessibility Techniques." Essentially they teach you to build web-sites for disabled users and at the same time for search engines. The gist is that search engines really ARE disabled themselves, they're somewhat blind and dumb. So you really start to think about how information is presented on your site for more than just the fully-able users and when you look at "tricks" like putting labels within the placeholder element you immediately/instinctively know it is going to cause problems (for SEO and disabled users alike). Worth checking out if you're interested in this topic and have a "lynda" account.
- bherms 14y agoSee my demo: http://jsfiddle.net/VtAAs/7/ http://jsfiddle.net/VtAAs/7/
- mcgwiz 14y agoBefore we let the pendulum swing from one cargo cult to another, let's simply recognize that there are often more cues involved in conveying an interface's intention. A login form will be accompanied by a Login button, for example. In this case, the intention of the two preceeding input fields should be obvious. (A well-designed site would permit any unique user key, including email and username.) Placeholders, in this case, are generally acceptable. At the other extreme, a customer information form would have to rely more heavily on explicit, rather than inferred/implicit cues. This includes labels, and their heavyweight siblings, descriptive tool-tips and sidebars. Very complex forms may require extensive documentation. Most problems have a whole spectrum of possible solutions, supported by a wide variety of tools. Don't let a single aggressive voice narrow your understanding of that.
- gbog 14y agoI'd accept placeholders as labels the day I see a reason to remove labels. And, no, fashion is not a reason.
- bpatrianakos 14y agoWell your response implies the reason is stubbornness, and definitely not, as you say, fashion. The parent makes a great point and there are so many times when we're exposed to articles like this that promote a certain view as being the one true way. The original article makes some great points but so does your parent. If there's any wrong take on the labels vs. no labels debate its taking any one side at all. The right thing lies somewhere in the middle.
- gbog 14y agoSo everybody is right, everything is relative, and so on? Sorry but no. In some cases, maybe in most cases, the right thing in not in the middle. For example: having or not ads on Wikipedia, using or not useless animations in websites, allowing or not third-party to access private data, etc. So, removing a useful cue for user without strong reasons to do so is not "somewhat right", it is just wrong. It is a sin, and will send you to designers' hell (which is a room with thousands of 30' screens on the walls displaying random websites from 5 years ago).