Making Compact Forms More Accessible

by Mike Brittain

56 Reader Comments

Back to the Article
  1. 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.

    Copy & paste the code below to embed this comment.
  2. How about this?
    http://www.sitepoint.com/article/behaved-dhtml-case-study

    Copy & paste the code below to embed this comment.
  3. 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!

    Copy & paste the code below to embed this comment.
  4. 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

    Copy & paste the code below to embed this comment.
  5. 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!

    Copy & paste the code below to embed this comment.
  6. Just a couple of comments:

    I would advise using valid markup by using FIELDSET element instead of non-semantic DIV element.

    Daniel – as used in these examples, the <div> is being used in a reasonable way. In fact – if you were to simply replace them with a <fieldset> you’d be going too far. The <fieldset> 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.

    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 <fieldset> is one) but I don’t see a specific requirement for it to be a <fieldset>.

    Finally, if you can clarify one thing:

    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 <div> instead of <fieldset>? Or are you referring to something else?

    Copy & paste the code below to embed this comment.
  7. 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).

    Copy & paste the code below to embed this comment.
  8. Daniel:

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

    Copy & paste the code below to embed this comment.
  9. 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.

    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!

    Copy & paste the code below to embed this comment.
  10. 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).

    Copy & paste the code below to embed this comment.
  11. How would You handle an error message? (eg. The email adress entered is not valid.)

    Copy & paste the code below to embed this comment.
  12. 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.

    Copy & paste the code below to embed this comment.
  13. 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! ;)

    Copy & paste the code below to embed this comment.
  14. 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.

    Copy & paste the code below to embed this comment.
  15. Daniel – thanks for responding…

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

    Yes, a <fieldset> is appropriate to use in a form. Yes, username and password are of one group. However, to simply use a <fieldset> instead of <div> as the examples are coded, you’d have a <fieldset> 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 <div>) around each pair to properly apply the styles (as coded).

    And Mike Cherim is right – there is no requirement for a <fieldset> as any block level element will do. But, as a straight replacement for the <div>s used to wrap each label/input pair, <fieldset> could very easily be seen as inappropriate as it is not grouping any related controls. If anything, the <fieldset> should go around both the username and password fields to group them, not around each individually.

    I’m done now. :)

    Copy & paste the code below to embed this comment.
  16. I think that you should add cursor:text; to the label.overlabel-apply{} because the default cursor may confuse a little the users.

    Copy & paste the code below to embed this comment.
  17. You need to degrade gracefully this of course doesn’t work however I would recommend something more along the lines of:

    <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
    <html xml:lang=“en” lang=“en”>
    <head>
      <title>Bold Internet</title>
      <style type=“text/css” id=“MasterStyle” >
      form#SignIn fieldset{ border:0 }
      form#SignIn fieldset legend{ display:none; }
      form#SignIn fieldset ol{ list-style:none; }
      form#SignIn fieldset ol li{ list-style:none; display:inline; }
      form#SignIn fieldset ol li em{ text-decoration:underline; }
      form#SignIn fieldset ol li label{ display:none; }
      </style>
      [removed]
      function populate_SignIn()
      {
        document.getElementById(‘txtUserName’).value = “UserName”;
        document.getElementById(‘txtPassword’).type = “text”;
        document.getElementById(‘txtPassword’).value = “Password”;
      };
     
      function switch_Password()
      {
        document.getElementById(‘txtPassword’).type = “password”;
      };
     
      function check_SignIn()
      {
        if(document.getElementById(‘txtUserName’).value “UserName” || document.getElementById(‘txtUserName’).value “”)
        {
          alert(‘You must enter a valid UserName.’);
        }
        if(document.getElementById(‘txtPassword’).value “Password” || document.getElementById(‘txtPassword’).value “”)
        {
          alert(‘You must enter a valid Password.’);
        }
      };
      [removed]
    </head>
    <body >
      <form id=“SignIn” acti method=“post”>
      <fieldset>
        <legend>Sign In</legend>
        <ol>
          <li><label id=“lblUserName” for=“txtUserName” title=“User Name” accesskey=“U”>User Name</label><input id=“txtUserName” type=“text” title=“User Name” value=”” maxlength=“20” tabindex=“1” /></li>
          <li><label id=“lblPassword” for=“txtPassword” title=“Password” accesskey=“P”>Password</label><input false;” id=“txtPassword” type=“password” title=“Password” value=”” maxlength=“15” tabindex=“2” /></li>
          <li><input id=“btnLogin” type=“submit” title=“Sign In” value=“Sign In” tabindex=“3”  /></li>
        </ol>
      </fieldset>
      </form>
    </body>
    </html>

    Copy & paste the code below to embed this comment.
  18. @Barry Rader
    As far as I know type is a read-only property, at least in IE.

    Copy & paste the code below to embed this comment.
  19. 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.

    Copy & paste the code below to embed this comment.
  20. 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.

    Copy & paste the code below to embed this comment.
  21. 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

    Copy & paste the code below to embed this comment.
  22. @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.

    Copy & paste the code below to embed this comment.
  23. A really really nice one!

    Copy & paste the code below to embed this comment.
  24. Great article! Very useful.

    Copy & paste the code below to embed this comment.
  25. I’ve taken the suggestion here and applied to my site (thank you).
    The problem I have is that IF I add

    document.forms0.elements0.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?

    Copy & paste the code below to embed this comment.
  26. 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?

    Copy & paste the code below to embed this comment.
  27. Such as <SELECT> or <TEXTAREA>?

    Copy & paste the code below to embed this comment.
  28. 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?

    Copy & paste the code below to embed this comment.
  29. 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/

    Copy & paste the code below to embed this comment.
  30. 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

    Copy & paste the code below to embed this comment.
  31. (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.

    Copy & paste the code below to embed this comment.
  32. 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;
    }

    Copy & paste the code below to embed this comment.
  33. 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?

    Copy & paste the code below to embed this comment.
  34. 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.

    Copy & paste the code below to embed this comment.
  35. 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.

    Copy & paste the code below to embed this comment.
  36. Westbrook, having the same issue with auto filled password field here. I haven’t found a reliable solution to fix this, unfortunately.

    Copy & paste the code below to embed this comment.