Form Mark-Up: Are Lists Appropriate?
Recently Mike Robinson of www.akamike.net posted a response to another article on noupe.com asking for opinions on using list with forms. I'm not trying to single anyone person out. Mike is not alone in his thoughts, and I am simply using his post Form Mark-Up: Are Lists Appropriate? as a "for example" on the kinds of articles that I am reading more frequently on various blogs. I'm not trying to pick on Mike but rather raise awareness to an increasing problem that I see.
One of the trends that I see more frequently, is to place all your content in a list. Ordered Lists, Unordered Lists, and Definition Lists. It doesn't seem to matter anymore. This "all inclusive tag" is being packaged and sold as semantic markup. Frankly I feel it's just bad marketing. Yes it does validate. So does a table. Validating is not a true measure of semantics. A list of any kind is meant for one thing. Listing content. It's not semantic to use a list for layout. This is still bending the rules for layout purposes. In fact I would say it's worse in some cases, and less semantic than using a table. I'm not saying "use tables" I am merely saying it's not any better. Lets take a look at the two practices and compare them to plain old HTML. I have laid out three forms below with the same elements. One is in an ordered list, the other uses a table, and the last one is plain old html.
Ordered List
Table Based
HTML Only
Lets take a look at the code for a moment to compare the differences between them.
Ordered List
form action="#" method="post">
<fieldset>
<legend>Your Details</legend>
<ol>
<li>
<label for="ol_name">Name:</label>
<input type="text" id="ol_name" name="ol_name" />
</li>
<li>
<label for="ol_age">Age:</label>
<input type="text" id="ol_age" name="ol_age" />
</li>
<li>
<label for="ol_location">Location:</label>
<input type="text" id="ol_location" name="ol_location" />
</li>
</ol>
</fieldset>
</form>
Table Based
<form action="#" method="post">
<fieldset>
<legend>Your Details</legend>
<table>
<tr>
<td><label for="ol_name">Name:</label>
<input type="text" id="ol_name" name="ol_name" />
</td>
</tr>
<tr>
<td><label for="ol_age">Age:</label>
<input type="text" id="ol_age" name="ol_age" />
</td>
</tr>
<tr>
<td><label for="ol_location">Location:</label>
<input type="text" id="ol_location" name="ol_location" />
</td>
</tr>
</table>
</fieldset>
</form>
HTML Only
<form action="#" method="post">
<fieldset>
<legend>Your Details</legend>
<label for="ol_name">Name:</label>
<input type="text" id="ol_name" name="ol_name" />
<label for="ol_age">Age:</label>
<input type="text" id="ol_age" name="ol_age" />
<label for="ol_location">Location:</label>
<input type="text" id="ol_location" name="ol_location" />
</fieldset>
</form>
Notice anything? Like how similar the table based version is to the list based version? Seems to me that TR's and TD' are being replaced by OL's and LI's. You are also using a list to perform a function in which it is not intended. LAYOUT!
Besides being incorrect semantically, there are accessibility issues with using a list for content in which it is not intended. Users, browsing a website with assisted technology like screen readers have to listen to additional markup being read back to them. Screen readers read out loud the list hierarchy and sub hierarchy before reading the content within. This fact alone makes this bit of code less usable. I say less usable because it's content is still there for the consuming but the person listening has to parse additional information that is not relevant to to his or her use of the form. The extra markup is there simply for the developer to have additional hooks in which to attach code. That is not semantic at all. I don't care how dice it, It's not semantic. In fact I think a div would be more semantic than a list in this case, as the meaning of div literally means division. A separation of content groups, or divisions.
Styling a form
Let's now turn our attention to styling a form. Just the very nature of changing the way a form looks outside of alignment is horribly wrong for many reasons. On the wrong website it could be disastrous, costing a client money, leads, or as in the case of service or government related sites, may cause a user to be incapable of using the service.
Depending on your audience, changing the UI form elements of your page could be the worst thing. Not all of us work in this environment, and I am sure many of you are designers or developers. Your personal site is your playground, your own lab of sorts. Do yourself a favor, and your clients a favor. Keep experiments reserved for those sites where it's appropriate. But then I digress.
Back to styling. Under most circumstances, all three of these forms can be styled the exact same way. The later is perfectly suited for many of the sites that you may build for our clients. There are enough hooks to get most forms to look the same with half the code, twice the usability, and all the semantics. It's a win-win situation. Yes it's true— in some cases, it may not be enough hooks for the really complicated layouts. However I have to wonder then. If there are not enough hooks to style your form you may want to stop and ask the questions: Are you approaching it the right way? Are you over complicating it unnecessarily? Is there a problem with the UI design? Is it an IA problem that needs to be addressed? These questions are often overlooked. As a result more code is tossed in to help a developer cobble it together and make something work.
if I can accomplish one thing with this article, it would be to make people stop and think about what they are reading. Not all articles claiming to be "semantic" way of doing something really are semantic. Do your own research, learn, continue to make improvements, and repeat the process. I think its great that people are thinking ahead and striving for for semantics and standards. But we do have to be cautious and not get to caught up in the moment and accidentally take a step backwards.
Now it's your turn, Comments are open.
Tags: Accessibility · CSS · usability
8 comments so far ↓
I would like to say that I don't feel my article is quite like the others. The objective of my article was to not say "use any list" but to explain which list would be most appropriate in theory, in this case ordered lists -> field order.
In the absence of an argument against this, other than "because I think it's wrong", I didn't see the holes in my article until later. I realized was that even without lists the form has order and can be styled well enough to negate the need for extra elements.
You are right, if you need the extra mark-up then you probably are over-complicating things. I'll be sure to post my own follow up to this to make sure my readers see this!
Thanks again for this response :)
Using extra markup around label+input sets is not just people's attempts at adding hooks for styling a form but also necessary when you think about how the markup might be rendered in all manner of devices/situations.
Your last example would not look good in lynx, or on some mobile browsers or when CSS is disabled. It also makes it difficult to style forms that have extra information eg. extra help text that does not belong inside the label. Lastly when you want to indicate an error with a certain field, there is no single parent for the label and input that you can append error text to or apply styling to (unless you wrap form controls inside labels which could work with short error messages - but this method is not without it's problems).
In the wild most people use a paragraph or div to wrap label+input combinations as it offers the most flexibility and is not detrimental to the purpose of the form.
Using extra markup in a form for the sake of styling, is in effect anti-semantic by it's own definition. Proper markup of a page will both increase it's usefulness and it's semantics. Looking good to users and being semantic are two completely separate issues not to be confused.
Granted the last example may not look good to sighted users if it's un-styled, but that will rarely be an issue. If your a sighted user and you are surfing the web with css turned off, then that is your prerogative and are probably used to sites not looking the same as they do with css turned on. Same is true if you choose to surf the web with a browser that is over 10 years old or by some obscure developer or platform, again your probably used to sites not looking the same as they do in FF or IE. The form will be 100% accessible to all people and though may not look as good serves all of the functionality it was intended without infringing on any one users ability to use a form. The people that need it to work the most for them are those with disabilities. Be it a keyboard user, a screen reader user or any other person using an assisted device. Placing a form in a list is both a problem for these people, but it's also not semantic markup. It is not unusable but certainly unnecessary given the options that developers have.
Many mobile browsers will in fact display the form with a reasonable amount of formatting. I have done testing with several mobile platforms on various sites, and even some of my early devices would display content in a linear fashion and with minimal formatting. There is no possible way to make any site look exactly the same on all platforms. How gracefully it degrades from one system to another and from one user to another is a true measure of success. If you alienate an entire group or groups of people for the sake of aesthetics thats your choice. But Don't operate under the false concept that your code is semantic, accessible or useable. It's just pretty.
Using a paragraph tag or a div is more appropriate than a list for sure. It's in my opinion that a div is the better choice than a paragraph as semantically the form does not contain any paragraph information. It too is using a tag for a use it was not intended.
In regards to error messages, that is a whole other topic that I would like to cover in a full article later. Perhaps sooner than latter. My short response is, only sighted users will benefit from any sort of extra markup used to hide or show a message. A screen reader may not pick up on those changes and therefore provide no valuable feedback to the user thereby rendering any fancy formatting useless to them. Alternately, it may provide an error message to them before they enter form data, causing confusion. I have a whole set of issues to discuss surrounding people with limited vision, cognitive disabilities, limited mobility, and other disabilities and error messages. I will save that for another time when I can show markup and examples.
In closing, There are a million ways to do something on the web. It's up to us web designers and developers to at least be aware of issues and do our best to code around them and find a better solution. After all necessity is the mother of all invention. We are an intelligent species and I am confident with the right minds thinking about the problems, solutions are only a few clicks away.
In the case of using list items sure, but if using div or paragraph tags where is the evidence that not using 100% minimal semantic markup is at all inaccessible or unusable for the user?
@Mike "My short response is, only sighted users will benefit from any sort of extra markup used to hide or show a message"
I wasn't referring to any inline ajax style error reporting. I always make sure my sites provide the same error reporting with or without javascript. Don't forget that forms are greatly improved by using visual cues aswell. While it's great to make them as usable and accessible for non-sighted users as possible the vast majority will be sighted and therefore that's where the bulk of the effort goes when designing a form. Sometimes that means you need a label+input wrapper.
XForms may provide the solutions in the future but it's yet another steep learning curve.
http://en.wikibooks.org/wiki/XForms
It's not inaccessible or unusable. A div would be the obvious solution in my mind. My demonstration purpose was to show that you don't have to use the extra markup for a great many forms found on the web. I used Mikes for as an example as he was asking for feedback and it offered a baseline to compare structure and markup.
@Robert: "Don't forget that forms are greatly improved by using visual cues as well. While it's great to make them as usable and accessible for non-sighted users as possible the vast majority will be sighted and therefore that's where the bulk of the effort goes when designing a form. Sometimes that means you need a label+input wrapper."
I agree that sometimes we have to break the rules. Knowing when and why as well as the potential repercussions is the key. I cannot comment on any particular functionality as there are a million varieties out there. I can say, that I have tested a few options, and each had pros and cons. I will cover this topic in more detail if you have specific features, or scripts that you find useful. I am also sure that others reading this topic would love to find a great tool for their toolbox.
All good points. Sorry if I misunderstood, but I think on the whole we're on the same wavelength.
With regards to the tools I have used in the past it depends on the particular project. I have used code igniter (a lightweight php framework [2]) to provide both general error messages and in-situ messages (ie. adjacent to the affected field) with ease using the validation class provided.
Coupled with light use of the jquery validation plugin [2] can make for a good quality user experience aross the board although quite often I wouldn't bother with the javascript. Sometimes it's too invasive and a downright nuisance.
[1] http://codeigniter.com
[2] http://bassistance.de/jquery-plugins/jquery-plugin-validation/
There was a perfect (and intentional) illustration of this worrying trend a while back where the whole page was deliberately marked up using list items. After all a web page is 'just a list of elements' right ;-)
you mention in your post that it's easy to style the three type of forms the same. Well, aparently not, as my own testing shows of your testpage (on a WinXP machine)
- In IE6 it looks almost the same, only the legend is overlapping the left part of the fieldset;
- In Opera 9.6x the labels in the last form are all over the place;
- In FF 3.0.5 and Safari 3.1.1 all's well!;
Styling form controls has to be the most difficult job out there, just read this article (http://www.456bereastreet.com/archive/200410/styling_even_more_form_controls/) to find out just HOW hard ;-)
Oh, and please make use of CFFormProtect in Mango ;-) Recently it's been ported to BlogCFC - the step to port it to mango shouldn't be that hard ;-)
Leave a Comment