6

Many designers like to assign form field labels using the value attribute of the form field itself rather than a label or sometimes both, if they're mixing iconography with textual labels or providing prompts and data validation rule tips.

How do you implement form fields where it's either a requirement to have labels/prompts inside the form field or it's necessary due to space, style guide etc.

I find it annoying that I have to manually clear a field before I can enter text into it ... but if it's the only meaningful label then I kinda need it.

I'll always try to use unobtrusive JavaScript to set the value of the form field on page load and then bind a focus and blur event to clear the field for me and reinstate the default text if I leave the field blank.

I'll always also have an additional label even if the visual design doesn't include a visible one for accessibility.

However there are other issues around how does this field behave with just CSS disabled, just JS disable, neither CSS or JS, why do we design fields like this, is it useful/helpful or annoying and inconvenient? Has anyone done any research on this?

Example of a form field with label, form field with both a label and in-field prompt text and a form field with only in-field label.

flag

8 Answers

6

On my blog's search box I do it by putting text in the input field. The text is grey and italic to indicate that it's not regular input text. JavaScript clears the text when the field receives focus and replaces it if the field loses focus and is empty.

I have seen an approach that positions the label element over the input field to achieve the same appearance. When the user clicks, JavaScript moves the label offscreen. This is nice because the text isn't actually in the field (so won't be accidentally submitted). More importantly, it works even without JavaScript; in that case the label just appears to the left of the field as usual. And if done correctly it's universally accessible. See Making Compact Forms More Accessible. In-Field Labels is a nice jQuery implementation; there's also labelOver.

But in general, putting text in the field like this is not usually a good idea.

When users focus in the field, you really have to make the text disappear to avoid confusion. So just when the user is about to type into the field—right at that point when they might care what the label says—they can't see it.

This is even worse if the text in the field is additional prompt text (as in your second example above). In this case the text is only useful when the user is typing in the field.

This might be OK in some circumstances where it's fairly obvious what the field does anyway. For example, I use it in the search box at the top-right of my blog. But it's still not great. When used in a form with multiple fields, I have seen users forget what they are supposed to be typing. The only way to get the label back is to delete the text from the field. Clunky. And very frustrating.

So this is tricky enough even before you consider accessibility. It's best not to do it.

link|flag
I've always struggled with this issue since, from the accessibility point of view, you're supposed to have text inside the input field, but you're also supposed to have labels to them in the markup. I just followed the jQuery labelOver link you posted, but the sample that's given doesn't seem to work properly (Chrome). Unfortunately, the label inside the text field doesn't disapear when onFocus, or even when text is typed in, which makes the typed text unreadable. This seems like an interesting solution, could you give me another example of where this is used? Thanks! – Renata Neira Feb 11 at 17:33
1 
 Try In-Field Labels, which I also mentioned. I think the idea is good, but apparently it's tricky to get right cross-browser. – Bennett McElwee Feb 11 at 22:23
This is the best jQuery-based plugin that I've found, which slides the labels instead (either vertically or horizontally) - csskarma.com/blog/sliding-labels-plugin - though this is by definition less compact than simply fading them out as "In-Field Labels" does and therefore not as useful in tight spaces. – MarcusT May 13 at 11:35
4

I don't have the reference to hand but I'm pretty sure I heard someone from Yahoo mention at a conference that they found that putting text inside the form reduced completion rates by something ridiculous like 60%. So, based on that, best avoided.

Does someone have a proper reference for that quote?

link|flag
Is that due to the excise of having to clear the field first or does that include auto-cleared fields? – Nathanael Boehm Oct 21 at 12:36
Cool. I've certainly seen many users confused by the disappearing label "feature" - but I've not seen drop off rates that massive. Be fascinated to see the reference too if anybody has it! – adrianh Oct 21 at 22:12
they didn't discuss the reason or whether it was auto-clear or not (suspect it was tho), just the dropoff rate. I suspect it's a mixture of reduced recognition as a field (if not in a full-blown form), and confusion re: getting rid of the text. – Leisa Reichelt Oct 22 at 13:58
2

just wrote a post yesterday about this thing, http://usabilitythoughts.com/form-labels.html see Dimitry's comment also.

I don't really think it's a good idea to put the labels inside the fields, it limits your global view on the form, you can't recheck without submit etc.

link|flag
yeah - the recheck before submit one is a painful one for folk. – adrianh Oct 21 at 22:23
1

The way to handle this would be to write proper HTML first, using < input > and < label > in the appropriate fashion.

You should then be able to use JavaScript to write the content from < label > as value of the < input > field.

However I can already see this as too much work for too little benefit, hence I would not suggest using text inside < input > as a label for form elements.

This is not accessible and it is less usable also.

link|flag
Can you try explaining that again Jason? I don't quite understand. Are you talking about replicating the value of label into the input field? Or moving it? It's not hard to do - ~130 characters of JS, but I'm trying to figure out what goes where about what the benefit is. – Nathanael Boehm Oct 20 at 21:54
0

I think labels or additional prompt text that disappears on focus can work pretty well in a few situations, when you need the extra space:

  • a REALLY simple form that's not a primary input on a page (like the blog search field that Bennett pointed out).
  • GENERAL contextual information (for example, a location input on a search form that lets you know you can search by "city, state, or zip code"). This works well paired with a persistent label outside of the form field, as in your second example. It's so general that it's unlikely the user will need to refer back to it while typing.

That said, there's a lot of ways it can be easily abused

  • Long forms with many inputs.
  • Login forms (I've actually seen people use this treatment on password fields, so the prompt text "password" ends up looking like [* * * * * * * *].)
  • Specific validation patterns that the user will need to refer back to while typing (Phone: [ (123) 123-1234 ], for example)
link|flag
0

I tend to stay away from labels inside the feed because I haven't yet found a good way to get rid of it.

Javascript is great to get rid of the label on click, but what if the user forgets what the field for once he gets inside of it?

Like Adrian and his commenter mentioned earlier (good article by the way), it would solve the problem of the user forgetfullness. It brings up another one though if Javascript was turned off. It would make the field completely unusable. The label would still appear there and dim when the field is focused, but it would never fully delete it once the user started typing. It it wasn't completely unusable when JS is off, this would be the best solution. Find more info on this method at zurb.com: http://www.zurb.com/article/271/making-forms-convert-through-awesome-inli

Until I come across a better solution to the problems above, I'm not going to use in field labels. Here's what I do:

Label [ ] Email [ ]

or if I'm pressed for space:

Label [ ]

Email [ ]

It's by far the most usable solution I've found.

link|flag
0

Ok I've come up with an idea of how to handle this. It involves dynamically loading the title attribute (sorry, gets techy) into the value attribute of the input on page load, then on focus fades it out and then copies that same text, prefixes some text to it, throws it in a new element that then hands below the field. It's then faded out once the user leaves the field. Handles default/user text on focus, default/user/blank on blur:

http://sandpit.purecaffeine.com/text_in_form_field.html

Does this address some of the problems raised?

link|flag
I guess the question would then be - since you're leaving screen real estate for the tip - why bother having it in the form in the first place? ;-) – adrianh Oct 21 at 22:22
It's only going to fall in the spacing between form field elements anyway so it leaves the form nice and clean but persists prompt/helper text when in or out of a field. – Nathanael Boehm Oct 22 at 0:18
This approach is not accessible - input VALUE attributes are for values, not labels. The better in-field-labels use real LABEL elements and position/fade them inside the field so that accessibility is maintained. This is the best implementation I've found, which supports sliding in-field labels either to the left or upwards: csskarma.com/blog/sliding-labels-plugin – MarcusT May 13 at 11:32
Disagree - they're not labels, they're prompt text. But I like your idea too. – Nathanael Boehm May 13 at 22:10
0

I think that Nathanael's solution is one of the better that I have seen in a while. I am going to test this out myself. Great solution to address the graceful degradation point.

@lisa I dont have the link but have heard that same quote a few times in the last week.

link|flag
I'm pretty happy with it too; let me know your thoughts once you've tested it out because I'm planning on extending it to be a generic jQuery plugin. – Nathanael Boehm Oct 21 at 20:47
Plugin is up: sandpit.purecaffeine.com/persist-helper-text.html – Nathanael Boehm Oct 24 at 0:06

Your Answer

Get an OpenID
or

Not the answer you're looking for? Browse other questions tagged or ask your own question.