Prettier Accessible Forms

by Nick Rigby

118 Reader Comments

Back to the Article
  1. Brad: I will give you that it is much simpler to put everything into a table, but it is not tabular data when you get down to it. When you get down to it, it is essentially a “question list”, which is essentially a subset of a definition list (i.e., question : term :: answer : definition ). You’re even allowed multiple dd’s to each dt, so that allows you the ability to provide multiple answers (e.g., checkboxes) to each question.

    Copy & paste the code below to embed this comment.
  2. Is this code actually intellectual property of Cimex Media? If I develop a sweet script at work, I don’t think it is mine to distribute. Just a thought…good article.

    Copy & paste the code below to embed this comment.
  3. Jens: While I’m torn on using what type of list to use (I’m currently leaning towards a definition list, and would use an unordered list before an ordered list like in the article), the point that I believe you’re missing is not that you’re emphasizing an asterick, but you’re emphasizing the text used to indicate that it is a required field. This article is meant as a library to be used from project to project, so you’re free to use whatever text within each tag that you please.

    Copy & paste the code below to embed this comment.
  4. Could you use this for required fields: <abbr title=“Required field”>*</abbr>?

    Probably not, since it is not an actual abbreviation, but it seems like a good way to hide the bulky text.

    Copy & paste the code below to embed this comment.
  5. You’ve clearly put a fair bit of work into this, but I’m sorry to say that it’s got some serious problems, JavaScript aside:

    1. There’s just no way in hell that an ordered list can be considered semantic markup for this. (This is an ordered list, a form simply isn’t.)
    2. The colors look cool but are a form-over-function (har, har) usability problem: they give undeserved/irrelevant emphasis to the lower fields and the variable background color makes the asterisks harder to see, which seems to defeat the whole point of the exercise.
    3. I’m a big believer in TMTOWTDI, but this seems like a really complicated way to solve a problem that’s been solved for a long time. Marking required fields with a colored asterisk isn’t exactly a new concept.

    To me, this is squarely in the “because you can” bucket, not the “because you should”.

    Copy & paste the code below to embed this comment.
  6. @Nicolai Grossman

    Tell me why an ordered list can’t be used here? The form elements are presented in some kind of logical order, so it works fine. Plus, it gives additional information to users of assitive technologies, in that the number of list elements are read aloud when the list is first encountered.

    The colours have absolutely nothing to do with the method that is presented in this article. This is just my version of how the form could be styled. The cmxform.css template file contains no styling and is presented as a template to give the form it’s default properties. The styling is then down to the author that is using the method.

    Again, the asterisk is my way of solving a particular problem. If you want to use a different method, go ahead.

    I think you are really missing the point of what I am presenting here. This method has taking a huge amount of time to develop, has been testing with assistive technologies (such as screen readers) and works accross a majority base of browsers.

    Copy & paste the code below to embed this comment.
  7. I usually use definition lists when styling forms. As in the Article, fields are logically grouped using fieldsets. Then, I put the label for the field(s) that follow into a <dt>, and all fields that belong to the item are put into a <dd> each. I know that it’s not really a list of definitions, but definition lists have the advantage that they show what’s belonging together prett well. Also, you can style <dt>s to be clearing, floating left, and having a specified width, so you wouldn’t need that javascript hack of yours. Just a suggestion ;)

    Copy & paste the code below to embed this comment.
  8. There are definitely ways to achieve the same visual formatting effects shown here, cross-browser, without using JavaScript. I strongly believe if you can achieve an effect without using JS then you should.

    Firstly let’s be honest: using JS to “fix” CSS implementations is a hack, and like any other hack should always come second to seeing if an alternative, more robust ‘workaround’ approach can work. Second, given many stats seem to show around 10-15% of users with JS disabled (yeah, scary), you should surely always aim to deliver the best experience you can without Javascript.

    Bottom line is I don’t believe Javascript is necessary here (unlike “Jeremy’s image gallery”:http://alistapart.com/articles/behavioralseparation in today’s other article, for example). Like previous commenters I have had a lot of success using floats (and a smattering of positioning) to style forms, including creating table-like layouts for complex (ie multi-fieldset/legend) forms from table-free markup. Predictably I don’t have anything written up I can share just this minute (!!), but it looks like there’s scope for more work – and lots more sharing of good ideas – in this area.

    Copy & paste the code below to embed this comment.
  9. Although I think it’s quite an interesting article I always wonder what’s the idea behind all these kinds of hacks that people use in order to get rid of tables in cases like these.

    I guess any kind of list would be more appropriate than a table in this case. But if you have to use hacks like the Mac/IE5.2 CSS hack and/or use JavaScript for lay-out (not event triggered) then why not ‘hack’ the understanding that it’s better not to use a table in a case like this? I mean, it’s a ‘hack’ that has been proved to be succesfull extensively. Why introduce new, more complex hacks for an old and simple one?

    Copy & paste the code below to embed this comment.
  10. Okay everyone. Thanks for all the comments so far, although I think things are going off topic slightly.

    • The HTML has been written in a very accessible way, in order for it to be available and most usable in many different devices and environments. I am using the available HTML tags in the best possible way I think I can.
    • There may be a significant number of users that disable JavaScript, but given that JavaScript is only required in Firefox, the 10%-15% user rate that has been quoted is probably inaccurate. However, the point is that the form works without JavaScript enabled, so for me, I see absolutely no issue here.
    • It is possible to re-create this layout using many other different methods. However, this method was produced to be as portable as possible, so it could be easily plugged into any site as a library CSS item. I feel I have achieved that. Remember, this is one method, you are not forced to use it and you should use a method that you feel most comfortable with.

    This technique works incredibly well for me, and that is the exact reason why I am sharing it with the community.

    Thanks for everyones comments so far.

    Copy & paste the code below to embed this comment.
  11. I am surprised that no one has mentioned the use of the -moz-inline-box property.

    What is the point of coding to standards if we use a proprietary non-standard property to overcome a problem that could be handled properly?

    Copy & paste the code below to embed this comment.
  12. Referring to the mozilla specific extension -moz-inline-block, I find it reasonable and acceptable to use this propietary extension. Though it is non-standard, Mozilla simply created the proprietary extension to implement a feature currently only in working draft form. Therefore, the whole JS ‘hack’ will become moot once the CSS 2.1 working draft becomes a recommendation. (as mozilla will simply remove the -moz prefix)

    On a side note, I find mozilla’s approach much better as opposed to the other browsers which implement working draft features. If removed from the recommendation, these proprietary extensions will then remain as implemented properties without the proprietary prefix they should have. In mozilla’s case, it is correctly named as such, and is easily (and almost immediately) modified to remain in step with the spec (recommendation).
    Copy & paste the code below to embed this comment.
  13. Way back when I read Designing with Web Standards for the first time, I remember Jeff warning about catching “divitis” when switching from table-based design to CSS.

    Seems to me like today we’ve thrown out divs (with no semantic meaning) in favor of lists.  We markup with lists and think up a reason to justify them later.

    I loved the finished form in this example… a gorgeous product for not a lot of work; but a “list of form fields?” Come on ;)

    Copy & paste the code below to embed this comment.
  14. I think a major issue is whether the solution someone presents gets better over time. In other words will this solution require radical change in 2 or 3 years hence. Since the Javascript is easily removed the solution is good on that basis. OK, there are disagreements about whether OL is correct but this is a small point, and people no doubt can change it if they wish.

    It is clear that the author has taken great pains to test this so we don’t have to. Thankyou! Content separated hacks whether they are JS or CSS are a way of life at the moment, and they at least enable us to use the HTML we want to which is the key, and has convinced the browser manufacturers that they need better support for CSS in the future. This is a good thing.

    Can the same thing be done with floats? Perhaps, but the author and others have problems with them too so this is another solution to add to your armoury. Copy and paste some Javascript, and you are done. In the future, do a grep search to remove it.

    Thanks
    Good work :-)

    Copy & paste the code below to embed this comment.
  15. I quite like this solution, and whilst I do agree with many of the issues raised with ordered lists and the javascript, I like the ideas in play here.

    My question for Nick, is why are you using “inline-block” as the display property for the label element at the top level, then change it to block further down? I couldn’t find anything specifically addressing this in the article.

    I ask because I recently had to develop a similar form design solution that didn’t end up as clean as yours.

    “Form input
    “:http://www.cue-the-sun.com/ato/add.html

    “Form output
    “:http://www.cue-the-sun.com/ato/view.html

    “More complex
    “:http://www.cue-the-sun.com/ato/FDF_trials/fdf_indent.html

    Copy & paste the code below to embed this comment.
  16. Firstly, nice article, I like the “make it work” approach over absolute purity (javascript’s ok if it works quickly and easily in my book).

    One point of feedback, the layout doesn’t seem work on Firefox 1.5.0.4 on Linux, the form inputs are aligned left against the labels instead of sitting neatly in a row.

    Good article, got me thinking…

    Copy & paste the code below to embed this comment.
  17. I’m curious that there haven’t been more reports such as “that by Chris Leipold”:http://www.alistapart.com/comments/prettyaccessibleforms?page=1#2 indicating a problem on Firefox. Here’s a screen capture of how it renders on my FF 1.5.0.4 on Windows XP: “http://www.december14.net/bin/ala-form-ex3.png”:http://www.december14.net/bin/ala-form-ex3.png

    Copy & paste the code below to embed this comment.
  18. Nick, great article! From now on using <ol> inside my forms… As many others I’ve been using div’s inside the fieldsets to be able to style the rows.

    You could set the <label>‘s to float:left; with a certain width. Meanwhile set the ol li to overflow:hidden; which will make sure the li will stretch out. (if this doesn’t work in ie, set it’s width too…) In this case you won’t have to use a display:inline-block; ?

    Copy & paste the code below to embed this comment.
  19. Keith,

    This works fine on my version of Firefox/Windows XP. However, it looks like it’s something to do with the size of inputs/textarea. I have not explicitly defined these in the example, so if you were do do this, the problem may well be fixed. I would be very interested to know if it does fix the problem

    Thanks.

    Copy & paste the code below to embed this comment.
  20. Nick, that’s it. I didn’t realise that widths hadn’t been set in the code; I just assumed the examples would already be “tricked out” to look like the screen grab near the top of the article.

    Setting explicit widths on the inputs and textareas does fix things, but you then have to distinguish between regular text inputs, and checkbox/radio inputs as one size does not fit all.

    Interesting approach, and it’s always good to see alternative ways of doing things. Like other commenters, however, I’ve found that the same sort of effect can be achieved using only CSS and without recourse to proprietary properties. Every dependency you can eliminate opens up the number of users who will experience the form as you would wish.

    Good article.

    Copy & paste the code below to embed this comment.
  21. Keith,

    The examples should look like the screen grab. Normally you would add a size value to an input like:

    <input id=“name” size=“20” />

    When you do not specify a size, a default size is used, which is possibly different in some browsers. It looks exactly right in all the browsers I tested with, but it is obviously different on yours. The thing is, the inputs in your example look way out. Is this the same for all browsers on your machine?

    Thanks.

    Copy & paste the code below to embed this comment.
  22. I’d be the first person to emphasize that tables should not be used for layout (except with tabular data), but I fail to see how the form presented in this example is not tabular data.

    Imagine a form to collect information about your pickup basketball team. You’d have a column of row names, and then five columns with input fields. There’s the name row, followed by five name fields to fill in. Then there’s the position row, followed by five text boxes in which you put each player’s position, etc. The name/value pair relationships are clear, and each field is labeled (“Name – Player one. Name – Player two,” etc.)

    How is this not a table? And then if it only has one column of information to fill in, how is this any less a table?

    Using tables for simple forms such as the one in this example also has the benefits of lists that were outlined in earlier comments—a screen reader gets to the table, and it reads, “Table with two columns and five rows” (so, just from the structure of the table, you know how many items there are not just down, but across, too), then it reads the summary and/or caption that you’ll have added to your table, “Contact information form,” or something else equally descriptive.

    I’m open to being convinced otherwise, but to me, this type of form is clearly tabular data with name/value pairs.

    Copy & paste the code below to embed this comment.
  23. This works fine on Safari, but the form fields aren’t aligning properly using Flock’s 0.7 beta on the Mac. Same thing when using Firefox 1.5.0.2 on the Mac—the form fields don’t align evenly and are instead simply aligning left following the label for each.

    The rest of the fields, however, display fine.

    Copy & paste the code below to embed this comment.
  24. Anthony,

    I’m not able to test in Firefox 1.5.0.2, but I just tested in an earlier version (1.0.7) and it works fine. I’ve also tested in Flock 0.7b and again it works fine. I’m using OSX 10.4.6. Do you have JavaScript disabled?

    Thanks.

    Copy & paste the code below to embed this comment.
  25. I haven’t done much testing on the topic, but I wonder if styling the label element as display: compact has been given serious consideration?

    Copy & paste the code below to embed this comment.
  26. I agree with almost all comments on this article

    1. don’t use javascript for styling, unless it’s for the crappy IE browser. Let all other browsers simply use CSS
    2. don’t try and find a use for lists when there is none. Though I must agree without CSS it looks nice. But I think the main issue is that without CSS it should be usable, not nice looking. a simple break will do.
    3. don’t use -moz-inline-box, don’t use inline-block (not yet that is)

    For interested readers, I wrote an article in search of all possible float solutions for forms that have no additional markup. Let me know if you have more methods that I could include.

    “floating forms article”:http://test5.caribmedia.com/CSS/Secrets/members/michiel/floating-forms.html

    Copy & paste the code below to embed this comment.
  27. Wouldn’t the javascript be “better” (for some values of better, offer not valid in all states, some settling may occur it transit) if it looked for inline-block and replaced it with something better on broken browsers?

    I realize that the article isn’t about inline-block, per se.  But to me, it’s one of the features I wish worked in FF/IE. :-/

    Ciao!

    Copy & paste the code below to embed this comment.
  28. I appreciate the article, Nick.  Nice work.  Compelling discussions as well.

    I would like to get your – or anyone’s – thoughts about setting the size of input fields.  While it is not addressed specifically in your article, I think it has relevance given that we are attempting to make forms “prettier” and more “accessible”.

    My question concerns setting the input size to be the same length in all cases (except for input types “radio” and “checkbox”).  I grant that – when all the same size – the inputs do make a prettier form.  Your form does this, and it indeed looks great.  Yet, what about considering the input in relation to the data it expects – and adjusting the input’s size attribute accordingly? 

    A specific example is an input for Zip Code for a US address.  I feel it presents a usability issue to the user when the width of a Zip input is as long as the input for Street or City.  A US Zip is necessarily shorter and it makes sense – and is fair to the user – to indicate that visually, even at the expense of creating a “jagged right line” of inputs on the form.  Thoughts?

    Copy & paste the code below to embed this comment.
  29. This may be a bit off-topic, but what is so wrong with tables? Why is a table in a form such a “semantic faux pas?” I could draw up that form in a fraction of the time, and do it using less bytes if I use tables. All I hear now-a-days is how horrible it is to use a table. Why use a simple table when you can create a huge stylesheet file and mess with divs that never show up correctly in all browsers?

    Back on topic, nice example though.

    Back off topic, I can feel the heat from the flames already.

    Copy & paste the code below to embed this comment.
  30. Yet, what about considering the input in relation to the data it expects — and adjusting the input’s size attribute accordingly?

    That is sometimes appropriate, but in many cases you won’t know the length of the input. If you’re asking for name, or town, or email address, you have no idea how long it’s likely to be – so set a size that will be big enough for most people and others can scroll if they have to.

    A specific example is an input for Zip Code for a US address. A US Zip is necessarily shorter and it makes sense — and is fair to the user — to indicate that visually, even at the expense of creating a “jagged right line”? of inputs on the form.

    I know this is slightly off your point, but consider the possibility that people from other countries will be entering their address in your form – might it be better to have a textbox so they can enter the address in whatever format is most appropriate rather than be constrained by one that is designed specifically for US addresses?

    In answer to your question, I think it would look fine either way, whether the postcode box is the right size for the input, or lined up with the other fields. Part of it will depend on the rest of your form, and how many fields there are of the standard length.

    Copy & paste the code below to embed this comment.
  31. In the case of input fields with an expected specific length there is only one way to have the length of the field match the length of the data across browser-platform combinations:

    1. do not use CSS to set a width
    2. set the attributes maxlength and size to be equal
    3. set the font-family to a monospace font

    I have experimented with this and it was the only way, for example with a five-digit zip, to guarantee that the data input exactly matches the length of the input element. This was tested with Opera, IE (from 5 to 7 on Mac and Windows), Firefox, Safari and Netscape 6.

    Copy & paste the code below to embed this comment.
  32. Excuse the atrocious spelling errors in my previous post. I haven’t had my coffee yet.

    Copy & paste the code below to embed this comment.
  33. Nick

    [Ref comments 48, 50, 51, 52]

    As I was reading your last comment (#52) it dawned on me where the problem lies, and likely explains the similar reports you have had regarding Flock and FF on Linux.

    In your example, you are not explicitly setting the width of text input and textarea elements in the CSS, but instead leaving it to the “default” size, or, in the case of the textarea, using the cols attribute in the textarea tag to set cols=“25”. If not explicitly set by CSS, the width of such elements will be affected in Firefox and other browsers by the user’s settings for default font and font size. It appears that my (and other people’s) default settings are larger than yours, hence the observed differences.

    We have no way of knowing a user’s browser settings, so it is risky either to leave the field widths unspecified, or to use the size/cols attributes in the HTML tags. To be safe (well, as safe as we ever can be, in this game) we need to set widths in the CSS to make sure labels and inputs don’t bump into each other, or knock each other out of the way.

    Of course, every individual form will demand its own styling, including input and textarea field widths—but maybe that needs to be made clear.

    I hope this is helpful.

    Copy & paste the code below to embed this comment.
  34. Thanks to Christian Tietze in comment #3 for linking to my Awesome Form. I just wanted to note that I’ve updated “Awesome Form”:http://paularmstrongdesigns.com/examples/css/awesome-form.html

    Awesome Form is complete cross-browser compatible CSS for displaying forms using only its most bare elements. No lists, no tables, no guff. I hope others find it useful!

    Copy & paste the code below to embed this comment.
  35. I appreciate that the article you wrote does allow developers to create accessible forms, however the need for Javascript seems to be crazy in my opinion. Although the Javascript is unobtrusive, it still creates more work for the developer. It is possible to create the same form using <dl><dt>&<dd> tags for Markup and only CSS to style it. It’s still very accessible, has more semantic meaning and no need for Javascript. What would happen if the user had Javascript turned off? Answer: It would no longer be a “Prettier Accessible Form”. I really don’t want to sound like I’m moaning, as it is a step in the right direction, but I urge you all to check out Dan Cederholm’s technique for forms.

    Copy & paste the code below to embed this comment.
  36. Firstly let me say that I enjoyed seeing a form layout that took a stab at semantics and didn’t use floats, which have been plagued me quite a few times in designing over the years. There’s certainly no God-sent CSS template that addresses the form (and there may never be), but please keep exploring these new ideas as they’re always welcomed and enriching.

    In trying variations on this CSS, I discovered that if you set text-align: right; on the <li> and use padding-right to shift the inputs/labels to your liking, then you can obviate the need for js/proprietary tags. This also minimizes the need for CSS hacks. Granted, you have to be willing to deal with right-aligned label text, but the result is very clean/crisp. Here’s a very short “example”:http://www.geocities.com/pgates18/Content3.htm for your perusal.

    Of course, as often occurs in the Web Design world, solving one problem reveals at least one new problem. Inputs and TextAreas can generally be made to render equally across many browsers. The select element misbehaves in this regard, however (I’ve only tested in IE6, FF1.5, Op8.54/9). Opera is the only one of the three browsers I’ve tested (assuming the widths are equal in the CSS) that naturally renders the select the same width as the other form elements. IE and FF both render 2px shorter in the case of my experiment.

    Maybe I didn’t solve anything—just trying to follow the tradition of sharing ideas!

    Copy & paste the code below to embed this comment.
  37. I just posted another alternative solution “on my website”:http://bajooter.com/node/22 that may be viable. It uses the method mentioned on “Quirksmode”:http://www.quirksmode.org/css/forms.html plus there isn’t any javascript and only I only used one hack.

    Copy & paste the code below to embed this comment.
  38. Thanks for the great article!

    Copy & paste the code below to embed this comment.
  39. @ Kevin

    I personally find forms with equal-length fields to be pretty, but not very usable. To me, different sized fields act much the same way as whitespace in a passage of text allowing me to more easily keep my fix on whatever I should be concentrating on. Another example is the alternating colors of a check register. By providing varying visual data. Generally, I will try to change the field size after 4-5 lines.

    I also agree that the size of the field gives a hint on what it’s meant to be which means you don’t have to read all of the labels as intently. For instance, If you see the pattern:

    *************
    *************
    **********
    **
    *****

    It’s pretty obvious that the last two fields are State & Zip

    Copy & paste the code below to embed this comment.
  40. @ Kevin

    I personally find forms with equal-length fields to be pretty, but not very usable. To me, different sized fields act much the same way as whitespace in a passage of text allowing me to more easily keep my fix on whatever I should be concentrating on. Another example is the alternating colors of a check register. By providing varying visual data. Generally, I will try to change the field size after 4-5 lines.

    I also agree that the size of the field gives a hint on what it’s meant to be which means you don’t have to read all of the labels as intently. For instance, If you see the pattern:

    *************
    *************
    **********
    **
    *****

    It’s pretty obvious that the last two fields are State & Zip

    Copy & paste the code below to embed this comment.
  41. It’s my first time posting here.

    Looks like my fields turned into HRs also. Here’s what I meant (i hope):

    OOOOOOOOOOOO
    OOOOOOOOOOOO
    OOOOOOOOOO
    OO
    OOOOO

    Copy & paste the code below to embed this comment.
  42. For me the tabular data issue is moot because I prefer against using tables because of the hell involved with javascript inserting and manipulating them (which, I suppose, evokes a whole new set of complaints, but on my current particular project I’m working on an internal website which requires JavaScript anyway for remote scripting purposes).

    Copy & paste the code below to embed this comment.
  43. Shoot. Should have mentioned that I’m really digging the use of lists.

    Think beyond address forms, people—ordered or unordered lists are perfect for things like questionaire’s or any extensive forms. This little approaches being what prototype.js is for js, for css. Obviously, compliancy is an issue but in the current world of CSS compliance, it almost always is anyway.

    Copy & paste the code below to embed this comment.
  44. I echo many people’s feelings here, as soon as I saw the JS to ‘fix the layout’, it was never going to be a popular solution. The idea isn’t to bloat the code and slow down browsing running functions.

    Stick with the floats or use tables for the forms. I’ve noticed no problems with the form on my site using floats, which has been checked on many browsers Four Shapes contact form. However, that form isn’t too complicated.

    Your form is nicely designed, but I don’t think it will be used too often.

    Copy & paste the code below to embed this comment.
  45. Someone once demonstrated to me what a screenreader actually does when presented with a list element. It spoke at length about the list item at each element, before describing the contents.

    No further demonstration/explanation was necessary, and since then I’ve refrained from using lists inappropriately for nav menus (when div/span sets will do*) and never inside forms.

    *div/span groups will straight swap in CSS (with less default style removal) and can also work better on unstyled (mobile?) pages.

    Copy & paste the code below to embed this comment.
  46. I like the use of -moz-inline-block; I dislike all the javascript.  That’s alot of work to fix what in all liklihood is a non-issue.

    Copy & paste the code below to embed this comment.
  47. I do apologise in advance because I’m normally very open-minded and listen to many different sides of a discussion, but in rare occassions like this one I get really annoyed.
    In a nutshell: will all you standards-Nazis get over yourselves!

    Where ANYWHERE in this articles does it say “this process is 100% reliant on JS and CSS and it’ll all break and look rubbish without it – to hell with standards!!”.

    I’d strongly suggest you go back and read it again – this process works perfectly well without JS. The only reason JS is in there is to fix the continuing rift between CSS implementations in browsers – and here I was thinking 1997 was almost 10 years ago.

    So instead of ranting and raving about how using JS to style is the work of Satan (and the process doesn’t style through JS the code simply fixes browser errors) why not focus that energy into bullying the browser manufacturers to get their act together and implement the established, 1,000 year old specs completely and accurately.

    Only THEN when we have 100% of browsers 100% compliant can you all go off and complain about hacks, fixes and workarounds if a process or piece of code deviates from standards.

    But of course this is never going to happen because new technologies are invented and maturing all the time.

    Sheesh if you don’t like it, don’t use it!

    Personally I’m going to rectify the erratic behaviour of long labels but making sure I don’t actually have any, but I’m not going to jump down the author’s throat just because he’s said “I’m going to fix omissions in a browser through script”.

    </rant>

    Copy & paste the code below to embed this comment.
  48. I was fascinated by the article and tried to implement all into a current project and it all worked well… except in the new Opera 9.
    The word “null” is inserted before all label contents.
    I am not a DOM-specialist, so there isn’t much that I can say or do about it…

    What does: this[removed] = null; in the script really do?
    ?

    Copy & paste the code below to embed this comment.
  49. The same behaviour with the example form of the article.
    “null” before each label element.

    Copy & paste the code below to embed this comment.
  50. Forgive me if this has been discussed earlier in the threads…

    I’ve seen a host of single column form solutions but they all service very small forms. What if you have a large amount of fields that need to be collected? Are there any two column css form solutions?

    Copy & paste the code below to embed this comment.
  51. By the way…now that form behavior is being completely rewrittren by Ajax and other dynamic technologies, don’t we need a new set of rules for styling them?  For instance, we’ll need the styles for error and confirm messages that appear within the form.
    Here’s an example Ajax powered newsletter signup form.

    Copy & paste the code below to embed this comment.
  52. Hi Bernd,

    I described a fix for Opera 9 earlier in the comments. Here’s the link directly to it:

    “Opera 9 Fix”:http://www.alistapart.com/comments/prettyaccessibleforms?page=3#26

    Thanks,

    Nick.

    Copy & paste the code below to embed this comment.
  53. I normally leave my forms pretty plain – I’m hooked on pretty forms now! Thanks.
    sam

    Copy & paste the code below to embed this comment.
  54. Never assume your audience has a white background on thier browser.  I’ve got old-school grey, and it looks terrible!

    As an aside, anyone else having trouble typing in this box, or is my keyboard suddenly broken?

    Copy & paste the code below to embed this comment.
  55. Can someone explain how the stretched gradient is acheived please?  I’ve tried copying the background: url(….) CSS but I just get the 1×2 pixel image repeated across the bottom of my fieldsets.  I can’t figure out how to stretch the image to 100% of the height of the fieldset.

    Copy & paste the code below to embed this comment.
  56. Well, “David”:http://www.alistapart.com/comments/prettyaccessibleforms?page=9#86, why don’t you look at the CSS source, copy the image URL and view the image?
    > !http://www.alistapart.com/d/prettyaccessibleforms/example_3/assets/images/cmxform-fieldset.gif!
    It’s a high gradient image. No CSS magic, just images.

    Copy & paste the code below to embed this comment.
  57. Oops – my mistake.  I missed the inclusion of the larger image completely.

    Copy & paste the code below to embed this comment.
  58. Maybe this was not the point of the article, but if word “Accessible” is used in the title, I can’t understand why clicking the labels of the radio buttons doesn’t (isn’t designed to) work!? For me, connecting labels with input fields using FOR and ID attributes is a must. Unfortunately not all the web designers use this rule – see checkbox under the “Search ALA” input ;) Laziness? Unawarness?

    Copy & paste the code below to embed this comment.
  59. I really like the way it displays in Firefox but I have to say that using JavaScript for the form makes it not quite accessible in my books. I like the architecture of the form as far as the code but using JavaScript just made me go “ugh!”?. Why are tables so bad when using forms? I think forms is a good use to put a good old table”¦

    Copy & paste the code below to embed this comment.
  60. I’m intrigued by the fuss Nick has caused by using an ordered list, because I’ve seen them being used to structure forms for years. Almost all the paper forms I need to fill in for my government, my university or my workplace—in fact, even surveys—have been represented as an ordered list of fields. This structure is especially useful because it is allows one to instruct the reader to “skip” a range of fields if they are not required.

    Given that it is an established standard, how precisely is this not legitimate? The only convincing argument I can see for not using them is presented by Pid Ster, who explains that the form becomes less accessible for screen readers; and then, the impractical purist in me cries that this is surely a fault of the software, not the structure. (Incidentally, can any more experienced readers tell me if this is the case for all speech readers?)

    Definition lists I find particularly challenging, mainly because I’m not totally sure about their semantic intent. What is a definition list meant to imply? Is it really legitimate to use them merely for association? Aren’t labels and fieldsets sufficient—for forms, at least? In fact, isn’t that their explicit purpose? Tables, in my opinion, are preferable for data presentation, not data entry. I know that they often mean less markup, less complex CSS and less cross-browser hassle, but (in my opinion) they are also less semantically appropriate.

    Not that I consider definition lists or even tables to be a complete semantic faux pas, but they don’t immediately strike me as the best structures.

    As for using ECMAscript to amend browser CSS support: the form degrades gracefully and is reasonably attractive without the fix, which itself is relatively unobtrusive. Admittedly, a perfectly workable solution could be created using floats, but the author’s stated aim was to develop a solution which could be “dropped” into place, and float-based layouts are often very brittle (an issue I’ve experienced first-hand).

    I mainly use paragraphs to markup forms, and in future I may well use a few lists. Excellent work, Nick!

    Copy & paste the code below to embed this comment.
  61. Thanks Nick, I appreciate there is no magic solution to this problem. Personally, using the javascript or ol element doesn’t grieve me as much as others here, and I still think this is better than tables.

    I’m only mentioning this because nobody else has brought it up – but using the external library is a bit of a worry – it’s 10kb of extra data that needs to be downloaded. I’m sure the library does all kinds of good stuff, but only if you use it.
    I’m struggling to keep my pages looking good, functional, and less than 100kb before compression, so an extra 10kb for the form is a bit expensive.

    Is there a way you can extract what you need into a standalone piece of script? I’‘m sure you could achieve what you need with a page or so of script, rather than requiring the library with all it’s other features.

    Copy & paste the code below to embed this comment.
  62. How can anyone argue against that a form is a list of questions and answers? US residents: have you never filled out a tax form, or a DMV form, or any other kind of form? Even your W2’s are numbered!

    I number fields for everything. It makes support calls so much easier, too. “I don’t understand question 6.” I’m glad to see other developers starting to do the same. DL/DT/DD lists are good, too. As a website that supports a large number of impaired users, we get many compliments over our use of numbered lists.

    The earlier solution linked ( “Paul Armstrong”:http://paularmstrongdesigns.com/examples/css/awesome-form.html ) is far worse IMO than this form setup. You think using a list is bad form? What about changing the logical order of elements so they float correctly? Paul makes it so you have to list the checkbox first and then the label. Blind users will really enjoy that.

    I have a feeling most people that are against the JS didn’t even look at the example with JS disabled in Mozilla—it may look a little “off” but it is still usable.

    Copy & paste the code below to embed this comment.
  63. I am excited to see your use of ol to mark up form items.  I think this markup is just right.  I actually disagree strongly with the use of tables and definition lists to mark up form controls. 

    The semantic realationship between the text and its input exists already, it is created by the label tag and the input tag (with appropriate attributes, of course).  I think your use of OL is perfect for establishing the semantic relationship between the different input/label couples which compose the form.

    I had previously used a more minimal markup :

    <label><input>text text text</label>

    The problems with my method were : 1. inverted order of text and input, and 2. with CSS turned off the form was still technically useable but turned into a soup of form controls and text. 

    Javascript for layout makes me very hesitant… I don’t like the idea that it might be used to shortcut actual thoughtful CSS development.  On the other hand I’ve inherited divML projects, where more than 40 divs were used to create three boxes of equal height in a row.

    When one has tried to do CMS development on a bloated project like that it starts to be easier to see the value of using Javascript to add extras that aren’t necessary for the page to function especially when it means we can keep the markup clean.

    Nicole

    Copy & paste the code below to embed this comment.
  64. Excellent article Nick, thanks for taking the time to write up your method.

    My only concern about relying on JS workarounds for style is unforeseen collisions with Prototype or Script.aculo.us (or any other Ajax library). Have you tested this method with Rails form helpers, or other server-side solutions that dynamically generate forms and form interactions?

    Not busting your chops, just asking. This article helped me see forms in a new light.

    Copy & paste the code below to embed this comment.
  65. I’m having a different problem using this on my own page with firefox, but it doesn’t affect the examples.  I did try not including any of my normal styles (using just the example instead).  Basically firefox ignores the width’s for the labels and the form itself.  Anyone know why?

    Copy & paste the code below to embed this comment.
  66. Hi all,

    I’m trying to apply Nick’s great example into a current website … and got a really good looking/working EDITABLE form cross-browser …

    What happens when you’re not editing and want to VIEW THE FORM later?

    Currently using label and input css markup is cool … but nothing’s available for the text later when viewing only.

    What do people propose to that? The DL/DT solution would solve that … but I wouldn’t mind getting Nick’s solution working!

    Copy & paste the code below to embed this comment.
  67. the snag is … you can’t do them with the current css :-(

    I realise now why Nick’s demo shows all radio and checkboxes on single lines in their own fieldsets – I’ve just tried doing multi-column radio/checkboxes and sure enough, the
    breaks the line and wraps to the start of the next line, under the label left-aligned :-(

    Any ideas anyone?

    Copy & paste the code below to embed this comment.
  68. I am very much anti-JavaScript, but face it, it’s use here is unimportant towards accessibility, nohng breaks if it is turned off.

    I did live in Germany till recently, my wife is German and all my three girls are Half German. I do not appreciate Ross Clutterbuck’s comment (78) about “Standards-Nazis”. It is very inapropriate when “Zealots” or “Crusaders” would have worked nicely. It is time to get over yourself, the war ended 50 years ago and not even my wifes parents and kids grandparents were involved in it.

    My one important input here is less JavaScript as the use of innerHTML as mentioned in comment 26. Best of my knowledge innerHTML is not supported by XHTML when correctly served as XML, only if served as Tag Soup. Hence this would not work in my personal sites. So any XHTML conscious designers should keep that in mind when using application/Xhtml+xml MimeType.

    Copy & paste the code below to embed this comment.
  69. @ Eric Brown and further readers:
    “The earlier solution linked ( Paul Armstrong ) is far worse IMO than this form setup. You think using a list is bad form? What about changing the logical order of elements so they float correctly? Paul makes it so you have to list the checkbox first and then the label. Blind users will really enjoy that.”

    Yes they will! Checkboxes and Radio bottons are supposed to have the label after them. Anything else will confuse the issue. “Better Accessible Forms”:http://accessify.com/features/tutorials/accessible-forms/ at Accessify.com

    Copy & paste the code below to embed this comment.
  70. @ Eric Brown and further readers:
    “The earlier solution linked ( Paul Armstrong ) is far worse IMO than this form setup. You think using a list is bad form? What about changing the logical order of elements so they float correctly? Paul makes it so you have to list the checkbox first and then the label. Blind users will really enjoy that.”

    Yes they will! Checkboxes and Radio bottons are supposed to have the label after them. Anything else will confuse the issue. “Better Accessible Forms”:http://accessify.com/features/tutorials/accessible-forms/ at Accessify.com

    Copy & paste the code below to embed this comment.
  71. Hello. Opera 9.01 is inserting ‘Null’ in front of the label values for me, with the intended label then dropping down a line. Anyone got a fix for that?

    Copy & paste the code below to embed this comment.
  72. I was sure I didn’t already read an answer to my question on Opera 9.01 and Null, but it’s there on page 3.

    Copy & paste the code below to embed this comment.
  73. I know I’m awfully late to the party, but I was wondering about the statement in the article that, “forms don’t constitute tabular data.”

    I’ve heard other people say this, and I really don’t get why. Especially given the concept of label/data pairs. In fact, I would suspect that when most forms are submitted to a database the data is submitted in a near identical format (e.g. The first column being an identifying label, and the next column being the data (although, I still think it would be semantic, even if the order was reversed… just kind of whacky in L to R reading languages)).

    I’m wondering if I’m missing something.

    Copy & paste the code below to embed this comment.
  74. I dont have anything to add to the discussion. I just wanna say that the idea of using lists for structuring is very…ummm…unique.

    I won’t argue about semantics or anything. coz as long as it works, it’s totally fine by me :D

    Copy & paste the code below to embed this comment.
  75. Here is a poor attempt at re-implementing this using Prototype.js since JQuery clashes.  This requires that the form has an id=“cmxform”, I’m sure people out there that actually know what they’re doing could improve upon this.


    if( document.addEventListener ) document.addEventListener( ‘DOMContentLoaded’, cmxform, false );

    function cmxform(){ // Hide forms $( ‘cmxform’ ).hide();

    // Processing var someNodeList = $(‘cmxform’).getElementsByTagName(‘label’); var nodes = $A(someNodeList); nodes.each( function( i ){ var labelContent = i[removed]; var labelWidth = document.defaultView.getComputedStyle( i, ‘’ ).getPropertyValue( ‘width’ ); var labelSpan = document.createElement( ‘span’ ); labelSpan.style.display = ‘block’; labelSpan.style.width = labelWidth; labelSpan[removed] = labelContent; i.style.display = ‘-moz-inline-box’; i[removed] = null; i.appendChild( labelSpan ); } ); //.end(); // Show forms $( ‘cmxform’ ).show(); }

    Copy & paste the code below to embed this comment.
  76. Someone above was asking about a tableless two column css layout.

    Working for a non-profit which serves the disabled, this article was my original inspiration for developing the above. 

    I eventually found the use of fieldsets preferrable to unordered lists because of the extra junk that comes with them in screen-readers. Besides, they make natural large containers, I wish I had discovered them years ago.

    This article is right-on in promoting the use of labels, which I now use religiously. I simply happen to like the div/span approach.

    Copy & paste the code below to embed this comment.
  77. Someone above was asking about a
    “tableless two column css layout”:http://www.yeago.net/work/2006/09/two-column-css-layout.html

    Working for a non-profit which serves the disabled, this article was my original inspiration for developing the above.

    I eventually found the use of fieldsets preferrable to unordered lists because of the extra junk that comes with them in screen-readers. Besides, they make natural large containers, I wish I had discovered them years ago.

    This article is right-on in promoting the use of labels, which I now use religiously. I simply happen to like the div/span approach.

    ps: severe apologies for the double-post. forgot to Textile.

    Copy & paste the code below to embed this comment.
  78. Let me first say that this article has become a great resource for me and has changed the way I think about and create forms. But I’ve found a problem that I’m surprised that no one has mentioned here. I’m developing on a Mac, and everything looks perfect on Safari! But in the rest of the browsers I’ve seen, there are inconsitencies. I’ve done a little modification to the CSS for my own purposes, naturally, and set the label width to 33%, as I’m using them in some varying CSS column layouts and this causes the labels to collapse so that the inputs are right along the right side of them. This happens everywhere bu Mac Safari and MSIE. The only other inconsistency is that MSIE seems to give a left margin to fieldsets. I set up my Submit button like so:

    <li>
    <fieldset>
    <label><input type=‘submit’ value=‘Submit’ /></label>
    </fieldset>
    </li>

    So that it would line up with my checkboxes and other inputs, but it shift a good inch to the right. Any ideas on how to fix this situation?

    Copy & paste the code below to embed this comment.
  79. As a comment to the 2 column tableless design remark;

    you can now validate your tableless design at: http://w3tableless.com

    check if you’ve done it the right way.

    Copy & paste the code below to embed this comment.
  80. Hi,

    Both on IE 6 and Firefox on Win2k, when a legend has more than 1 line, it’s not broke but continues on a single line.

    It’s at the exact position of “Is this address also your invoice address ?” but longer.

    Even if I force the width property of the legend, it’s not working, evenwith ” !important”.

    If you have any idea “¦

    Cheers.

    Copy & paste the code below to embed this comment.
  81. Firstly, I think this article does provide a nice insight and a perfectly valid method for form layouts. I think whilst the use of Javascript to fix style hacks is far from ideal, it is a solution which should work for the vast majority of people and thus is not a big usability issue. The downside is simply the untidiness of having extra “˜hack fix’ code.

    I would, personally, disagree with your assertion that it is wrong to represent form data in a tabular form. I believe that it is perfectly acceptable to represent any data however you like providing the semantics are easy to understand, mathematically solid, and do not contravene existing standards unless there is a specific reason for doing so. In the case of forms, I would say that it’s as easy to understand the semantics of a table form layout vs. a list based layout. Because there aren’t any fixed standards in place for form semantics I can’t see why using tables can be considered a poorer solution to using lists.

    For most situations you can classify a form as a set of related fields with undefined size, and classify a field as a typical (key, value) pair. To give an example, taking the first three, fields of your form (Name, Address, City) using set notation you could mathematically represent a typical record of data as ((Name, “˜Homer Simpson’), (Address, “˜742 Evergreen Terrace’), (City, “˜Springfield’)). As the set contains pair based items only, you can consider a 2-column table where the first column represents the head of the pairs and the second represents the tail of the pairs. Clearly, it is a direct mapping between two representations and the related XHTML code would be pretty self explanatory.

    I think there is a certain hesitation to use tables in the designer world for fear of being ridiculed for being out-of-touch. I think in this case a table solution would be perfectly understandable and increase the clarity of the page’s stylesheet.

    Copy & paste the code below to embed this comment.
  82. The alternative javascript (in comment #106) for use with Prototype.js only works with one form on the page and with it’s ID being ‘cmxform’, not the class.  This alternative works pretty much the same as the original script, only using prototype.js instead of jquery.

    function cmxform(){

    // Hide forms
    $$(‘form.cmxform’).each(Element.hide);

    // Processing
    $$(‘form.cmxform li label’).each( function( label ){
      if (label.classNames() != ‘nocmx’) {
      var labelContent = label[removed];
      var labelWidth = document.defaultView.getComputedStyle( label, ‘’ ).getPropertyValue( ‘width’ );
      var labelSpan = document.createElement( ‘span’ );
      labelSpan.style.display = ‘block’;
      labelSpan.style.width = labelWidth;
      labelSpan[removed] = labelContent;
      label.style.display = ‘-moz-inline-box’;
      label[removed] = ‘’ ;
      label.appendChild( labelSpan );
      }
    } ) ;

    // Show forms
    $$(‘form.cmxform’).each(Element.show);

    }

    if( document.addEventListener ) document.addEventListener( ‘DOMContentLoaded’, cmxform, false );

    Copy & paste the code below to embed this comment.
  83. Why are submit buttons never included in fieldsets?

    Since submit buttons can have meaning themselves, it would seem appropriate to me. I’ve never understood this.

    Copy & paste the code below to embed this comment.
  84. Hi,

    bin gerade duch zufall auf den Artikel gestosen, finde den Artikel echt toll, hat mir sehr weiter geholfen.

    Danke
    :-)

    Copy & paste the code below to embed this comment.
  85. I checked the CSS and it doesnt validate.

    “See for yourself”:http://jigsaw.w3.org/css-validator/validator?uri=http://www.alistapart.com/d/prettyaccessibleforms/example_3/assets/css/_library/cmxform.css&usermedium=all

    Just something to keep in mind if you plan to do this.

    I think overall it has a nice end result without using floats, but it’s sort of a toss up between floats and javascript.

    Copy & paste the code below to embed this comment.
  86. i like the approach and want to try it in my next applications. especially the way that you use a list to define the form rows. interesting. need to check how you managed the gradient.. looks nice ;)
    you can pass by my blog http://webdevbros.grafix.at i am sure its interesting for you.

    Copy & paste the code below to embed this comment.
  87. <a href=”?http://www.urmood.com/urmood_css_tableless_forms/”>

    Nice article Nick, one of the best examples I’ve seen. I’ve been looking for a good css alternative to table based forms for a while now. I found this article along with a few other articles, all with different implementations. However, the majority of them used div, span, lists, p, br etc, which personally I don’t think is semantically correct. Javascript/css combinations like Nick’s seem to be a favourite too, which I’m not a fan of, sorry. Most of the examples I’ve seen don’t validate to XHTML 1.0 Strict, and fall apart in different browsers. They also didn’t cater for radio buttons, check boxes etc, so I’m glad to see Nick’s article includes these. ANYWAYS, as nothing else I have seen suited me I’ve been working on my own tableless form which covers all the points above and seems pretty bulletproof: Tested and working in Windows: IE 5, IE 5.5, IE 6, IE 7, FF 1, FF 2, Netscape 6*, Netscape 7*, Netscape 8, Opera 5**, Opera 6**, Opera 7, Opera 8, Opera 9 Having read the previous posts, this is a different solution that might suit some of you better. Thought I’d share it and see what you think: <a href=”?http://www.urmood.com/urmood_css_tableless_forms/”>
    Copy & paste the code below to embed this comment.
  88. I used your above tutorial, but my the list is messing with my page background (only on PCs though). Here’s the link:

    http://www.cinevegas.com/survey/non.html

    Please I need help!

    Copy & paste the code below to embed this comment.