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?

  • Did you mean to link back to Doctype? If not, could you update the link? I'd like to see the form you're referencing. Paul Farnell over 5 years ago
  • The link does not work. joneff over 5 years ago
  • Fixed the link... sorry. Jess Sightler over 5 years ago

10 answers

2
points

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.

Answered over 5 years ago by Austin Web Design
Ellen B 35
1
point

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?

Answered about 5 years ago by Ellen B
1
point

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:

  1. Without JS: A fully working static form with labels
  2. If JS is enabled, move the labels off-screen by adding a class to them.
  3. Take the contents of the label and put in the corresponding input (found through the labels for-attribute).
  4. Insert the label text with extra help if needed (such as prepending "Enter your") into the title-attribute of the input-element.
  5. 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.
  6. 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.

Answered over 5 years ago by Jens Hedqvist
  • Maybe someone would want a working example of this? Hmm.. Jens Hedqvist about 5 years ago
Emily G 620
1
point

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.

Answered over 5 years ago by Emily G
1
point

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.

Answered over 5 years ago by Divya Manian
0
points

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.

Answered over 5 years ago by Rich Bradshaw
0
points

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).

Lastly, if the user doesn't have JavaScript enabled, they'll have to delete the text that is in the fields be default.

Answered over 5 years ago by Darryl Hein
0
points

Recently I started using lists for form layout after going through wufoo forms. But is it semantically correct to use lists?

Answered about 5 years ago by apnerve
orta 244
-1
points

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.

From a UX perspective, you can use the input title attribute and it will show up in screen readers see about half way down [this page] and that will do the job you're thinking of. 2

Answered over 5 years ago by orta
joneff 28
-2
points

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) :

<script type="text/javascript">
$$(inputSelector).each(function(textField) {
    var defaultValue = textField.previous("label").innerHTML; // of course there MUST be a label
    textField.previous("label").remove();
    textField.observe("blur", function() {
        if (textField.value != "") {
            textField.value = defaultValue;
            textField.addClassName("default-value");
        }
    });
    textField.observe("focus", function() {
        if (textField.value != defaultValue) {
            textField.value = "";
            textField.removeClassName("default-value");
        }
    });
});
</script>

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.

Answered over 5 years ago by joneff
  • With the progressive enhancement you solve the problem if the user has no javascirpt. However, a ASP.NET site is rarely usable without JS turned on ;) joneff over 5 years ago
  • Indeed... no JS would break tons of things on this site. Jess Sightler over 5 years ago