Form design - small descriptive text under label?

Am surprisingly stumped by this one.

On my forms below the actual label for text boxes, I want to add smaller descriptive text of what each field is. So something like Name < br /> Enter your username to access the site, and then to the right have the text box for the username.

Hope that makes sense :slight_smile:

Put “Enter your username to access the site” between spans and then style those spans accordingly. So like this:

<label>Name<span>Enter your username to access the site</span></label> <input name="username" type="text">

Pamela’s method is good, because it means those using a screen reader will hear the message before they fill in the field.

However, my question would be, how does this:

Enter your username to access the site

help your users? Isn’t that obvious anyway, as that’s commonly understood to be the point of a username. :slight_smile:

Another option worth considering if you are using an HTML5 doctype and don’t mind this not working in older browsers is to use placeholder text:


<label>Name</label> 
<input name="username" type="text" [COLOR="#FF0000"]placeholder="Username for site access"[/COLOR]>

but again, that seems a bit obvious anyway. For wider support, you can use JavaScript for this.

Another method, which is somewhat less accessible because it relies on a newer technology, is to have hint text under or above the input, linked to the input via aria-describedby.


<label for="username">Username: </label>
<input name="username" id="username" [b]aria-describedby="username_hint"[/b]>
<p [b]id="username_hint"[/b]>Usernames are limited to letters, numbers and underscores. No spaces please.</p>

The p could be a span if your hint is really more of a fragment or you want your label-input pairs to sit next to an inline element.

Don’t confuse aria-describedby with aria-labelledby (and note the spelling for that… that’s TWO l’s). Aria-labelledby will override your real label, which you generally don’t want. You merely want your hint to be associated with the input.

Anyway, this method is not preferred over the text-in-the-label method above, which works with older browsers and Accessibility Technology (though I would have a space character between the label text and span text there, or you’ll get “NameEnter your username…” read out), but having the hint text separate does allow you a bit more freedom in positioning, if you wanted the hint text right above or below the input, which is something I see commonly (also error messages).

Usually sites put the message under the input rather than the label which although removes it from the label does make it easier to see but of course is not quite so good for accessibility as having it in the label itself.

As Ralph said you really only want message when the input is not clear. I’ve added messages to the following example which was constructed for a previous thread as an example of something :slight_smile:

http://www.pmob.co.uk/temp/form-inline-block-errors2.htm
(View source as the code is all in the head)

To save real estate you could hide the message initially and show it on hover like so:
http://www.pmob.co.uk/temp/form-inline-block-errors3.htm

With the last example you could actually place the text back into the label in a span and hide and show it just the same- I’m not sure why I didn’t do that originally;)

The placeholder attribute Ralph mentioned is good for hints also but note that it should never be used as an alternative to the label.

Nice links, Paul I’ve just been looking at form design, with a list off error messages and links to the offending fields. One thing I notice is that clicking those error links doesn’t lead to the label or input that needs to be changed gaining focus. I’m sure Ive read how to do that … must look it up again. @Stomme_poes; Are you going to resurrect your form pages on your site?

You can use target to highlight the input but you will need js to put the focus in there.


input[type=text]:target { background:#e4f0f8 }

I’ve added some jquery to provide the focus and a scroll to the element to the demos.
http://www.pmob.co.uk/temp/form-inline-block-errors2.htm
http://www.pmob.co.uk/temp/form-inline-block-errors3.htm

Nice work, Paul. :slight_smile: It would be nice if it could work without JS. I was hoping you could go to the form element, fill it in, and press the back button to go to the next error. Seems this can’t be done with HTML alone.

I’ve been reading up, and it seems a viable alternative is to use PHP to refresh the page with only the form elements that need to be corrected, the correct answers already stored. Seems a good alternative. Presumably the user can press the Back button to see the whole form instead. (I’m about to test out this theory.)

Good luck :slight_smile:

The back button seems to break most forms or you end up paying for something twice.

Yeah, I’m just thinking of a simple contact form. You can usually click the Back button to see the form again and correct any errors.

Yeah. Still working on it; one of my last pages to redo partially because of all the new ARIA stuff coming out :slight_smile: In the meantime, Marco Zehe has some “ARIA-tips” on his English blog that are really great. Also some good ARIA stuff on Paciello Group’s blog, mostly written by Steve Faulkner.

I have had the generated error page add in anchors as destinations right above the label. You can’t know if a screen reader will read out the label when there is focus brought to the input; some do, some don’t. So I try to use something before the input when building a skip list. I think Paul’s idea could be an option, but mostly because we’d be assuming the user was on a list link which described the error and field in the first place.

Because they were evil and silly and didn’t use POST-Redirect-GET :slight_smile:

Unless I’m missing something, when I click links like that and then start tabbing, the tabbing starts from the original link, rather than the spot where I’ve jumped to on the page. Can the focus move to the element that’s jumped to?

Ralph: what you’re experiencing is a webkit bug from at least since 2008. All other browsers will move the keyboard focus to the skip area like they should :slight_smile: Of course, Hixie claims exactly the opposite (that most browsers don’t move the keyboard focus), which completely contradicts reality as usual. Also, I know Joanmarie Diggs had filed a similar bug when investigating moving Orca functionality from Gecko-based programs (Firefox, Thunderbird) to webkit-based programs (increasingly more on Gnome, such as Epiphany browser) which might have been flagged as duplicate by the webkit bot but not sure.

This does mean VoiceOver users need to use something else to get their focus directly to the inputs. The only good thing I can say is that VoiceOver users (who are pretty much stuck with Safari unless very recent versions have started working with Firefox/Mac) have always dealt with this in whatever way they do, and having the skip list above the form won’t add any additional confusion for them. Also, VO users on iThings have some kind of web page rotor something-something… you probably know what it is, it lets iThing users jump around pages… which is accessible to everyone and VO works with it as well. VO users such as Marco Zehe have commented on the usefulness of it, and likely would be used by experienced iThing users to jump to the form itself, if not the particular input in question.

Ah, thanks for pointing that out. I have recently switched to Chrome. Amazing they still haven’t addressed this.

you probably know what it is, it lets iThing users jump around pages…

Hm, no, I’ll have to check it out. I haven’t played much with it so far. Too much else to do. :slight_smile:

Apparently you have to turn it on: http://www.tcgeeks.com/ipad-ios-4-2-new-features/ search for web rotor. I thought it was something iThing people used in general since mobiles don’t have Home and End buttons.