A List Apart Comments for Article: Making Compact Forms More Accessible

Another great article

Tue, 19 Dec 2006 06:10:17 GMT

Great article, Mike! Although it has some problems with the password field in FireFox 2.0

Great Article

Tue, 19 Dec 2006 06:52:38 GMT

Very useful and it works great. RE: Comment #1, What problems does it have?

Firefox 2 Issue

Tue, 19 Dec 2006 07:21:33 GMT

In Firefox 2 (OS X), the password field isn't rendering properly. It simply shows a password field with asterisks "********"

No Javascript Error

Tue, 19 Dec 2006 07:32:31 GMT

If you turn off JavaScript the labels remain in place over the fields causing an overtype effect. Wouldn't it be a better solution to set the position of the labels using a JS function or even use JS to: a. Hide the labels and... b. Determine the text for each label, and finally... c. Use that text as the default value for the appropriate field?

The value of the password field

Tue, 19 Dec 2006 08:15:53 GMT

Where do you set the value of the pasword field to be "password", and how ??

Why nog use the default value instead?

Tue, 19 Dec 2006 09:01:47 GMT

It's a great concept, but I do agree with Sean: wouldn't it be much easier (and probably safer) to just get the value of the associated label and set this as a default value vor hte input field? I'm not sure about using CSS and the overlay technique for this.

Is this design pattern usable?

Tue, 19 Dec 2006 09:01:55 GMT

Great technique and works on Windows (some issues apparently on OSX) but in my opinion should designers be using this pattern to design forms in the first place? It would always be more usable to provide the label above the field if there is horizontal restriction of space, if the space is restricted vertically, use a horizontal layout. If it is a really small screen, use the first option with a scroll. Why resort to this?

No Javascript and Default values

Tue, 19 Dec 2006 09:08:46 GMT

Sean is right that turning off JavaScript would break this. But the proposed solution doesn't work - you can't present a default value in the password input (without changing it's type). But using this concept, you'd better add the overlabel class to the labels with Javascript.

Untitled

Tue, 19 Dec 2006 10:14:50 GMT

Is there any reason you're giving the divs their own ids? They all seem to perform the same functionality in the CSS so can't you just use them as a container with no id and no class and reference them from within the form id, i.e. #formname div. Sorry if I've missed something, it would just seem to clean up the CSS and markup a lot that way?

Untitled

Tue, 19 Dec 2006 10:15:58 GMT

..and then he notices the submit div being different. But still most divs will be exactly the same and you could just override this one as necessary?

Firefox not an issue

Tue, 19 Dec 2006 10:21:23 GMT

The 'issues' some people are having with Firefox is that it is pre-filling the password field with your saved ALA password. I'm not sure why it isn't doing the same with the username field. Also, a simple solution to cope with browsers that support CSS but not JavaScript is to dynamically add a class to the body such as 'hasJS' then prefix each CSS rule with '.hasJS' so it only fires when JavaScript is available and enabled.

ist this old stuff?

Tue, 19 Dec 2006 11:22:52 GMT

Why dont we just use the excellent script by Aaron Boodman? It's nearly perfect and addresses the same issues (unobtrusive, doesnt send label value if empty, etc). And even better, since it's 2001... so old he just archived it as "boring" :) http://boring.youngpup.net/2001/labels

Div Names

Tue, 19 Dec 2006 14:25:56 GMT

Paul - you're right, the DIVs could have been given any class name, ID, or none at all. These DIVs only provide an example of how the form could be styled. Certainly, your own implementation of this technique will have different styling requirements.

Thanks! More work!

Tue, 19 Dec 2006 16:19:00 GMT

Now I have to rewrite Payraise Calculator! :) http://www.payraisecalculator.com I utilized this same approach but my code was rather inefficient. Thanks for the great tip!

re: Firefox not an issue

Tue, 19 Dec 2006 17:41:38 GMT

Thanks, Tamlyn! That's very useful information. (And thanks, Sergei! It's always helpful to offer links to great similar techniques so that future readers can choose exactly what they need.)

Why not labels instead of Divs

Tue, 19 Dec 2006 17:44:04 GMT

Seems like it'd be easier/lighter to simply parse the input in the label element instead of using a div. Doing this creates an even tighter association and saves some mark-up. Nice topic, though. It's good to see this sort of thing.

put label under & remove div…

Tue, 19 Dec 2006 18:23:07 GMT

…using z-index, negative margin, & transparency, setting backgroud of input to white on blur by JS, if value is not empty the label is unobstusive, then, and degrade more gracefully if no JS (show label as /background/). LABEL.overlabel { z-index: 2 ; color: lightgray; } input.username { z-index: 1 ; background-color: transparent ; position:relative; left: -10em; width:10em; } input.username:focus { background-color: white ; } with included input into label tags (better for buggy browser for the « for » attribute) : , allow easy relative position and no div.

A new idea

Tue, 19 Dec 2006 19:51:37 GMT

Thanks for the article. I think that maybe you could be interested on this: Greenpeace presents a new website in Web 2.0 where people can give ideas to improve the next expedition to Antarctic. You can post your idea or comment and vote other s ideas The whaling fleet has left Japan, and is headed directly to the Southern Ocean. 945 whales will be killed - unless we do something to save them. http://whales.greenpeace.org/global

Unobtrusive Javascript

Tue, 19 Dec 2006 20:58:25 GMT

Nice article. I especially liked the idea of 'floating' the label over the text field and the fact that labels will 'link' to the text field if clicked, allows a user to get at the text field that is under the floated element. However... I have to agree with Sean Foushee in post #4. This current example fails the 'unobtrusive JavaScript' ideal. Should JavaScript not be available, this solution does not breakdown nicely. Instead, I would consider using JS to add the CSS that 'floats' the labels, thus, if JS is not on, the design can still be user friendly. Though, this can effect the design on a whole if the small form is now 2x as long. Cheers, John

I like the concept, but....

Wed, 20 Dec 2006 00:47:09 GMT

I like the concept, but as other commenters have said, it's a bit shaky with the javascripts and floats. I would definitely prefer the label method. I have seen this implemented on a few sites, but the worst examples don't replace the text values back into the fields once the user clicks off of them. For example: username appears, user clicks, clicks to another field, what was in the original field? Whoops. I'll stick with label and input thank you. Call me old fashioned Web 2.0 :)

FIELDSET should be used instead of DIV!

Wed, 20 Dec 2006 01:19:25 GMT

I would advise using valid markup by using FIELDSET element instead of non-semantic DIV element. Please note: FIELDSET element is required in forms in XHTML 1.0 Strict.

Re: Daniel D

Wed, 20 Dec 2006 07:39:52 GMT

Sir, if you'd like to detail a particular bug you've discovered, and to to so in a civil manner, your input would be welcome. I have deleted your comment with the enormous screenshot posted directly to the thread. Unfortunately, I also managed to delete your third comment, which I hadn't intended to do. I believe it went something like: "As you see, this is bad. These methods are terrible and not recommended." You're welcome to repost that one if you feel my paraphrase is insufficient. As you _seemed_ to be pointing out a JavaScript degradation problem, we'll look into that. See how easy that is? Easy! Civil! Yay!

bug

Wed, 20 Dec 2006 09:07:37 GMT

I am sorry for the misunderstanding, but was outraged to see that you recommend something that is not accessible. (and with the Javascript off, it wasn't even usable at all). I am also very sad to see that A List Apart have been ignoring semantics of XHTML (HTML) all these years. Solutions you recommend are often very bad practice of HTML development recommending non-semantic elements. This is the case with DIV used here instead of FIELDSET used properly, but there were many cases of the same style in past. Maybe some of your authors are not keeping up to date with internet semantics, but A List Apart should at least check the semantics and other errors occuring all over the place. Otherwise we can see lot of people ending up using your solutions that are sometimes very clumsy regarding semantics. I am sure you understand this is not the best case for web standards advocacy. Thank you.

Untitled

Wed, 20 Dec 2006 10:14:23 GMT

How about this? http://www.sitepoint.com/article/behaved-dhtml-case-study

Useful Technique

Wed, 20 Dec 2006 13:14:05 GMT

Thanks for this useful article, it came at a perfect time. Our designer put together a login form concept that used the exact example you give. I attempted a 'default value' solution (the traditional method), with an extra type change on the password field. This didn't work in IE6 so I used another method which swapped in an additional form field - but was never happy with it. The only change I have made to your concept is to have the labels next to the fields by default, and then switch the class using the Javascript to move them over the fields. As for using fieldsets rather than DIVs, my fields are both in a single fieldset, but I have also retained your DIVs for the exact reason you described - browser default styles will render the form much more neatly with them in. Thanks!

When in XHTML act like XHTML says

Wed, 20 Dec 2006 13:35:44 GMT

Well, ALA definitely makes me sad lately :( If you choose to use XHTML for your example, then please, make sure it works as XHTML. Save your example with an .xhtml extension and try to open it with Firefox or Opera. See what I mean? Problems with your current implementation: a) CSS won't work. XHTML is case sensitive so none of your CSS rules will apply if document gets parsed as XHTML (e.g.served with apropriate MIME type. See http://www.w3.org/TR/CSS21/syndata.html#q6 ). b) Javascript won't work. "In XHTML, the script and style elements are declared as having #PCDATA content." (http://www.w3.org/TR/xhtml1/#h-4.8 ). This means that any "&" or "<" will result in "yellow page of dead". Best way to avoid this is to keep all scripts in external files, but this is not so convenient for the example page, so you have other options: escape offending characters; wrap evertyhing in CDATA (but this will bring headache in HTML mode); or, best of all — stick to HTML4.01 I am embarassed to point to this article at ALA, but do I have a choice? So: http://lachy.id.au/log/2005/12/xhtml-beginners

Issues with the example

Wed, 20 Dec 2006 19:13:57 GMT

Daniel, Rimantas, et al: Thanks for your comments! As is probably clear, when we describe a technique and provide a demo, we're rarely recommending that you go out and put the demo itself into a production environment. That said, we definitely want to fix actual errors, like the apparent JS degradation glitch, which we're working on. I'll discuss the doctype question with Mike and see what he says. As for philosophical disagreement with our editorial line, I can only note that when our authors deviate from the path of semantic chastity, we ask them to explain _why_ so our readers can make informed decisions. We provide this forum so that you can propose alternative methods, and we invite you all to consider writing for us. And we honestly appreciate all your comments, because your passion is what makes the magazine tick.

Kicking myself

Wed, 20 Dec 2006 21:35:33 GMT

There's a "simple" form on my work site that has irked me for months now. And despite deducing your technique at a glance, brilliant me, I never once thought of this on my own. Your article exemplifies the beauty of this site. "Why default to a value that isn't a valid value?" Simple, excellent point. And kudos on the illustration that accompanies it--my favorite so far!

Fieldset Requirements

Wed, 20 Dec 2006 22:20:48 GMT

Just a couple of comments: bq. I would advise using valid markup by using FIELDSET element instead of non-semantic DIV element. Daniel - as used in these examples, the

is being used in a reasonable way. In fact - if you were to simply replace them with a

you'd be going too far. The

is to group related controls, so to be used properly in this case it would need to be around both input fields and/or the login button. And if that were done, you'd still need another container around the form controls for a style hook. bq. Please note: FIELDSET element is required in forms in XHTML 1.0 Strict. Daniel - can you point to where this requirement is spelled out? I'm reading the DTD for XHTML 1.0 Strict and I see that a form must contain one or more block level elements (of which

is one) but I don't see a specific requirement for it to be a

. Finally, if you can clarify one thing: bq. I am sorry for the misunderstanding, but was outraged to see that you recommend something that is not accessible. What _exactly_ is the accessibility problem with the examples? are you simply referring to the use of

instead of

? Or are you referring to something else?

i was refering to disabled JS

Wed, 20 Dec 2006 22:49:07 GMT

with JS disabled, example is not accessible or usable anymore because of the overwritten text. this could be handled by JS applied only after CSS formatting (i.e. change the CSS via JS).

re: When in XHTML act like XHTML says

Thu, 21 Dec 2006 00:07:25 GMT

After our re-review of the example file, we added a missing character encoding declaration, but we're disinclined to change the doctype. The file validates as is and works perfectly well in its current form (with the exception of the degradation glitch mentioned above). The file is clearly an example, which is why the JavaScript's not pulled out separately, and we're confident that no kittens will die if it remains as is.

Following up

Thu, 21 Dec 2006 02:33:37 GMT

Daniel: bq. with JS disabled, example is not accessible or usable anymore because of the overwritten text. this could be handled by JS applied only after CSS formatting (i.e. change the CSS via JS). Absolutely - agreed. What of the the other points I made, though? In particular, the *requirement* for a

in a form? I am asking seriously because if you've read that somewhere then it doesn't match what I'm seeing in the DTD and that should be pointed out to the incorrect resource.

Modifications and a Few Thoughts

Thu, 21 Dec 2006 05:17:59 GMT

First, I'd like to thank everyone who has been participating in the discussion. There have been some important details brought up, especially related to the initial state of the form if JavaScript is disabled. A modification has been submitted that addresses this issue. A couple other details were brought up related to script included within the HTML file and the omission of FIELDSET elements. I suspect that this makes easy sample for readers to download and review -- one file, simple, neat. bq. As is probably clear, when we describe a technique and provide a demo, we’re rarely recommending that you go out and put the demo itself into a production environment. I don't think I can put this any better than Erin did. I'm demonstrating the idea that LABELs can be used appropriately in these compact forms. If you use this in your own site, you'll certainly make your own decisions on markup, layout, class names, etc. Lastly, I appreciate Navneet's comment (#7) and want to reiterate a point I made in the article. I don't condone this sort of layout at all. But anyone who has earned a living in client services knows, there are some arguments that you just can't win. So why not make the most of it!

fieldset vs. div

Thu, 21 Dec 2006 11:13:51 GMT

You can use DIV as it is block element as well. But FIELDSET is much more correct for this purpose. IMHO, using non-semantic elements for any purposes is not way to advocate web standards. As for the argument that FIELDSET should group similar form fields, username and password are of one group (e.g. login fields).

What about error message?

Thu, 21 Dec 2006 12:32:09 GMT

How would You handle an error message? (eg. The email adress entered is not valid.)

RE: Fieldset vs. Div

Thu, 21 Dec 2006 14:32:12 GMT

I agree that a FIELDSET could have been used in this form to wrap all of the form elements as a group. I don't think that this would have added to the demonstration of how LABELS can be used in place of default values within INPUT tags to describe the fields. Also note that one of my intentions was to show a vertical form layout in the absence of CSS (perhaps a handheld device). I'm confident that ALA readers will adjust this example to fit their own specific requirements. Thank you again for your enthusiastic comments.

Works well!

Thu, 21 Dec 2006 17:19:38 GMT

Thanks for a good article! It's a good technique, and it works well. I've just tested it on several mobile devices using a couple of different browsers and it degrades beautifully. It also works just fine-and-dandy with JAWS 8.0... ... that makes it pretty accessible in my book! ;)

JavaScript update II

Thu, 21 Dec 2006 18:47:26 GMT

The demo now degrades as intended with JavaScript turned off -- thanks to our comenters for catching the glitch, and to Mike for the speedy fix!

I know of no "requirement"

Thu, 21 Dec 2006 19:51:15 GMT

I'm not aware of a requirement for a fieldset, but I do feel it would have been better to use it in lieu of a div in the example and in a real world implementation. One could style the fieldset element however one wishes to the best of my knowledge, to include making it so it's not be seen at all.

My final post on this issue

Thu, 21 Dec 2006 20:55:21 GMT

Daniel - thanks for responding... bq. You can use DIV as it is block element as well. But FIELDSET is much more correct for this purpose. IMHO, using non-semantic elements for any purposes is not way to advocate web standards. bq. As for the argument that FIELDSET should group similar form fields, username and password are of one group (e.g. login fields). Yes, a

is appropriate to use in a form. Yes, username and password are of one group. However, to simply use a

instead of

as the examples are coded, you'd have a

around each label/input pair and that would be next to useless as you're not grouping _anything_. You'd then need some other styling hook (like a

) around each pair to properly apply the styles (as coded). And Mike Cherim is right - there is no requirement for a

as any block level element will do. But, as a straight replacement for the

s used to wrap each label/input pair,

could very easily be seen as inappropriate as it is not grouping any related controls. If anything, the

should go around both the username and password fields to group them, not around each individually. I'm done now. :)

cursor:text

Fri, 22 Dec 2006 10:16:08 GMT

I think that you should add cursor:text; to the label.overlabel-apply{} because the default cursor may confuse a little the users.

This technique appears to be lacking in the accessability market.

Fri, 22 Dec 2006 17:43:48 GMT

You need to degrade gracefully this of course doesn't work however I would recommend something more along the lines of: Bold Internet

Element.type

Sun, 24 Dec 2006 08:19:18 GMT

@Barry Rader As far as I know _type_ is a read-only property, at least in IE.

Too Much Code

Wed, 27 Dec 2006 00:22:34 GMT

Why don't we just position the labels off the page? ( position: absolute; left: -9999em;) that way the screen readers still read it but no one else sees it. It also shows up for everyone with css and js off ( because it doesn't really need js) The only JS you could use if you decide to still use default values is a clear on focus or click to get rid of the default values or validate the information. Sorry but this solution is unnecessary and impractical. Remeber the more code you right the more you maintain.

Great Article

Wed, 27 Dec 2006 05:35:30 GMT

Just wanted to say that it is a great article. I think I read it 4-5 times now. Hopefully one day I will understand it all.

even smaller

Wed, 27 Dec 2006 20:09:57 GMT

This is really good for saving space, but it can be even smaller if "Go" button is replaced with "Sign In" - this way no title raw is needed

Element.Type

Tue, 02 Jan 2007 21:23:13 GMT

@Sander Aarts Your right it is a problem in IE although it is visually intuitive regardless of this problem since UserName is almost always paired with a password field, I doubt too many people would get confused on this one. However, I guess I could go with backgrounds on the fields themselves and turn those off and on. If it is a requirement of a clients that is. @Nick Morgan Clients do not always see it that way.

Brilliant

Mon, 08 Jan 2007 14:35:32 GMT

A really really nice one!

Thanks!

Tue, 23 Jan 2007 06:50:28 GMT

Great article! Very useful.

Curor Default?

Mon, 12 Feb 2007 23:33:14 GMT

I've taken the suggestion here and applied to my site (thank you). The problem I have is that IF I add document.forms[0].elements[0].focus(); To focus the curor then the userid field does not clear the label placed inside the field. If I don't apply that code then the curor is not focused on teh log in. Also (an issue with ie 7 I think) when you click REFRESH or BACK the user field does not clear (password field clears though). My javascript knowledge is limited and I took the form from horizontal to vertical design, so maybe I've missed an element?

break: hitting back button

Tue, 12 Jun 2007 14:00:12 GMT

When you hit the back button on the browser you can have the label and the text box on top of each other, the only fix I see is to just have the label hide the text box Anyone have a better idea?

Can this be applied to other form elements?

Wed, 11 Jul 2007 06:54:16 GMT

Such as

?
</article>
<article>
<h1>What happened to "Prettier Accessible Forms"?</h1>
<p>Fri, 10 Aug 2007 13:51:46 GMT</p>
I am somewhat disappointed that the techniques of the article "Prettier Accessible Forms":http://www.alistapart.com/articles/prettyaccessibleforms weren't used.
Wouldn't a <fieldset> tag and a set of <li> tags have made this more semantically correct?
</article>
<article>
<h1>Similar script using prototype.js</h1>
<p>Wed, 15 Aug 2007 18:12:41 GMT</p>
Back in 2001 Aaron Boodman wrote Labels.js, an impressive first-take on this concept. Updating this idea, I wrote a script that uses the prototype.js library and unobtrusively  crawls the page for input labels and places them inside the form elements. It might be of use to readers here:

"Stereolabels":http://blog.stereodevelopment.com/code/stereolabels/
</article>
<article>
<h1>Great article but Bug with IE6</h1>
<p>Fri, 07 Sep 2007 06:31:11 GMT</p>
there is a bug with IE6 when this form is in a content with a position:relative. When rollover, input field stay fixed !
Too bad, can't use it.
If somebody as an idea ?
You can also see : http://www.bossanoza.net/articles/formes_accessibles_et_compactes_avec_mootools
</article>
<article>
<h1>Untitled</h1>
<p>Fri, 28 Sep 2007 21:06:20 GMT</p>
(I also posted this exact comment on the author's personal blog where he mentioned the publishing of his article on this site.  But I thought I would post here in case anyone would be interested in lending a hand to me)

Great tutorial.  Newbie to web design here (CSS, JavaScript, etc.)

Background:
I wanted to make a search-box for the main page of my site that is sleek-looking with the label within the search field.  When I did a simple google search, I saw something about using 'onfocus'.  This simple solution worked fine in Firefox, but when I tried that in IE6, a warning came on and I had to select "allow" to get the proper effect.  I didn't want to force my users to have to do that.

So I searched again.  I saw in another forum that someone said to do a google search for "compact form" and that brought me to this article.

Using the techniques published, now IE6 fires up the form just fine without having the user select to "allow" the interactive functionality.

I was wondering about how to go about two things:

1) I would like the value that's in the field to say "Please enter anything (name, city, zip, etc.) to get started" (I will make the field long enough to accomodate this).  But I don't think I want this sentence to be a label should JS be disabled.

Right? Or maybe it would be ok to let the label be this sentence, but wouldn't it be too long with spaces and everything to be used correctly with the code?

Any advice on this?

Also, 2) What if I wanted two different submit boxes - one for "find" and one for "add" depending on what they wanted to do with what they entered.  What's the best way to go about this?

Any ideas would be much appreciated.
</article>
<article>
<h1>I find this better</h1>
<p>Wed, 20 Feb 2008 05:52:55 GMT</p>
<pre>
form#login {
  position:relative;
}

div#username,
div#password {
  position:relative;
  float:left;
  margin-right:3px;
  z-index:1;
}

input#username-field,
input#password-field {
  width:10em;
  background:transparent;
}

input:focus {
  background:white !important;
}

label.overlabel {
  position:absolute;
  top:3px;
  left:5px;
  z-index:-1;
  color:#999;
}
</pre>
</article>
<article>
<h1>Auto Filled Inputs</h1>
<p>Tue, 01 Apr 2008 20:03:30 GMT</p>
I'm encountering the problem that when the password field is automatically set based off of the user name value the label is not being removed.

Has anyone else encountered this?

It ends up with the starred password overlaying on the label that says "password".  I've tried to modify the script in various ways to correct for this, but have had no luck.

Can anyone help?
</article>
<article>
<h1>This form is not accessible</h1>
<p>Wed, 28 May 2008 13:39:37 GMT</p>
Accessible means "no loss of information for everyone".

Here, when a text field has the focus or when it has a default value, how can the user know what he is supposed to enter? The label does not appear: information is missing. Not accessible. However, this is accessible for blind people, with a screen reader that doesn't care about where is the label, visually speaking.

Please remember that accessibility is not only clean and well-formed XHTML code. And remember that blindness is not the only disability in the world.
</article>
<article>
<h1>Great idea</h1>
<p>Wed, 18 Jun 2008 12:36:59 GMT</p>
Have to say this is a great idea.. Top Job!  Only thing I would have said but has already been mentioned is the use of a fieldset and list to lay it out.
</article>
<article>
<h1>RE: Auto Filled Inputs</h1>
<p>Mon, 30 Jun 2008 20:35:46 GMT</p>
Westbrook, having the same issue with auto filled password field here. I haven't found a reliable solution to fix this, unfortunately.
</article>
</main></body></html>