We have a registration form that is currently designed with no labels outside of the textboxes. Is there any data on whether this presents usability issues for some people? Intuitively, this feels like a usability problem, but are there any usable studies indicating one way or the other?
Are there many sites that use this type of approach?
I remember a presentation at An Event Apart 08 by an accessibility expert who used this as a bad example. Basically once you click on or off the input you have no idea what was supposed to go in it. It doesn't help if you want to correct a typo that the field clears whatever you put into it, as well.
No I don't recall there being any hard data presented against it.
I don't have public data -- but worked as a UI designer at Google for about 5 years. Generally that type of widget was prohibited because it (1) failed accessibility, as others have pointed out, and (2) failed usability even for people who didn't have accessibility issues.
Basically, having gray text in the boxes makes them look disabled to a lot of people. Users wouldn't bother to click on boxes with gray text. On this page they might try to click since there's nothing else to do on the page, but it's not going to be nearly as clear as just labeling the darn fields.
I'm kind of confused why you wouldn't just go with a normal field-labeling convention here. You've got plenty of space on the page and it's a one-time use form. The argument for text-in-the-box-that-disappears is that in space-constrained layouts (like a searchbox in a header bar) which the user will use frequently and thus learn, you don't want to permanently take a line of vertical space.
There's just no argument in defense of that UI.
Have you tested it with any users?
It is an usability and accessibility issue. I recommend using labels and hiding them with CSS if JS is enabled (moving them off-sreen, not display: none), that way you ensure they are there for the all users, search engines and those without JS. I prefer always using the correct semantic markup in forms and then hiding them with CSS if needed.
I used this solution onces, it goes like this:
- Without JS: A fully working static form with labels
- If JS is enabled, move the labels off-screen by adding a class to them.
- Take the contents of the label and put in the corresponding input (found through the labels for-attribute).
- Insert the label text with extra help if needed (such as prepending "Enter your") into the title-attribute of the input-element.
- Put the new title-attribute text into the value attribute (and this is important:) IF ITs DEFAULT OR EMPTY. If you do not check if the value-attribute is default or empty you might replace cached values that the user has previousely entered.
- Use JS to remove the text onBlur if the value is default (= help text from the label not cached user input)
This way you have a fully working form without JS and a robust JS-enhanced version for those that can take it.
Labels are very important especially for screen readers. I use
text-indent:-9999px to hide labels but still have them accessible for screen readers.
Here's a great article on creating accessible forms.
FYI - your tabs are out of order. It tabs down the right column and then the left.
This sample form is a good example of usable, accessible form.
If you need to know how accessible your form is, you can check it out in the browsers listed here
I would strongly recommend using a fieldset and labels for a form.
Labels add some semanticness that's nice. Also, clicking the label selects the input if
for is specified which gives a bigger click target.
I think labels are important personally.
I would say this has a few usability issues, although I think it's mostly related to person preference (I haven't seen any specific data about it).
There are a few problems I see with this method: because of the number of fields you have, people may get confused as to what they should enter in a field after they have entered a few; "Have I entered that data already?" If there were fewer fields (only username and password) then I wouldn't see a big problem with it because it's quite obvious what should be entered.
Clicks in the first field, fills it out and then moves to the second one using tab, the "instructions" for they are to enter will disappear before they see it. Also, right now on your form, using tab keeps the text in the fields (other than password).
Recently I started using lists for form layout after going through wufoo forms. But is it semantically correct to use lists?
I guess really the point is how does the user know what to put in the textbox. If you've got the text inside as a value saying 'address' etc, then you could use the apple approach of having a label inside the text areas.
You could try with progressive enhancements -- have labels in the beginning, then on DOM ready copy the value of the labels in the box (if it is empty), set it as a "default on empty blur" value and remove the labels.
Something like this (written here in prima vista and not checked if actually works) :
Of course, this one uses Prototype, but easily make it work with MooTools or jQuery on any other FW. Additionally you could go further and add the title as a hint on focus.