pennypacker.net: Bulletproof Web Forms Part One: Content

Bulletproof Web Forms Part One: Content

A web form is most often the core of a web site. Every e-commerce web site and every community or social web site relies on forms to succeed, yet forms are so often neglected. I've spent some time lately working with forms, and I'm pleased to share my findings in a series of articles where I will cover form content, accessibility, presentation, and behavior of bullet-proof form design.

Setting the scope

All projects large and small have a goal. This project is no different, so let's begin by setting the bar for our form:

• The mark-up will be semantic and it will validate XHTML Strict.
• The form will be accessible to all and meet WCAG.
• The form will be intuitive and easy to use.
• The form will be presented in an orderly grid-like design.
• The layout will not break if either the text labels or form elements are sized differently.

With clear goals in mind, it's time to start building the page.

Content comes first

When building any web page or site, the most important ingredient is the content. In our example we'll be designing a simple form that collects input from the user. At this stage, we aren't terribly concerned with anything beyond the content, so let's begin by determining what information we are going to collect, and build the mark-up based on that. We're going to collect the user's name, e-mail address, web site address, and a comment they'd like to share. In the interest of diversifying our form, we'll also throw in a checkbox, a select menu, and a few radio buttons.

Form, Fieldsets, and Legends

The parent element for a form is <form>, that's pretty straightforward. It has two attributes that you should be concerned about: method and action. Action tells the browser where to go after the user submits the form. That's usually a script that does something with the data submitted. If it is left blank i.e. action="" then the form will post back to itself. Method tells the form how to submit data when the user submits it, and it may possess one of two values: "get" and "post". The get method will append form values to the URI of the action, and these values will be exposed to the user. Post will send the values over http invisibly to the server. As a best security practice, I recommend using post at all times unless you have a very good reason for allowing your users to see (and potentially edit) the information passed in URI.

The <fieldset> element is used to logically group sets of form elements. It helps to group sections of a single form in an intuitive and semantic way because the form is easier for the user to comprehend. We'll divide our form into two fieldsets, one for the information about the user, and a second fieldset to group the form elements that are more survey related. You can have as many fieldsets in a form as you'd like, and using fieldsets intelligently will help users navigate sections of your form more quickly.

A <legend> is a fieldset's built-in headline. It is a little bit of text that describes the section of the form, and it's useful not only to describe the section of the form, but it's a convenient location to embed page anchors for longer forms. Since we're focusing on accessibility, we'll be sure to smartly use <fieldset> and <legend>, and we'll also be sure to add page anchors to our legends so that we can link to specific sections of the form if need be.

Conventions

Before diving into the mark-up, it'll save you (or whoever is developing the back end of the form) a little time and effort to establish a naming convention that makes sense. Use simple and descriptive names that are unique for your <input> name attributes. Wherever possible, assign an id to input elements as well as a name and use the same value for both attributes. A notable exception is on radio buttons that share the same name, in that case, I make the id the same as the value attribute.

I apply a class name to button elements — In particular the submit button. Forms with multiple submit buttons cannot all have the same id attribute, so I use a class instead to distinguish them from other <input> elements. I have used class="submit" but using an additional class can often be more helpful e.g. class="submit button". Note: using a class on buttons is an allowance made specifically for styling, and I'll discuss that in Bulletproof Web Forms Part Three: Style.

Required Fields

I've chosen to add a bit of markup to each <label> that reads: <em>Required</em> to appropriately mark required fields in plain text. It is the most semantic solution to demonstrate which fields must be filled-in, though it's not visually appealing and it takes up a lot of space. Commonly a form will use a system of footnotes with an icon to show which fields are required, and we will too for users who are browsing visually. But the presentation of our form is what CSS is for, so when it comes time to style the form we'll address the look of marking fields required.

So let's take a look at some bare bones mark-up:

<form action="" method="post">
<fieldset>
<legend><a name="whoareyou" id="whoareyou"></a>Who are you?</legend>
Name: <em>Required</em><input type="text" name="name" id="name" />
E-mail: <em>Required</em><input type="text" name="email" id="email" />
Web Site: <input type="text" name="website" id="website" />
Your Comment: <em>Required</em><textarea name="comment" id="comment" rows="5" cols="10" /></textarea>
</fieldset>

<fieldset>
<legend><a name="aboutyou" id="aboutyou"></a>Tell us about yourself</legend>
Do you like checkboxes? <input type="checkbox" name="check" id="check" />
What is your favorite primary color? <select name="choose" id="choose">
<option value="red">red</option>
<option value="blue">blue</option>
<option value="yellow">yellow</option>
</select>
How did you find out about this form?
Search Engine <input type="radio" name="how" value="searchengine" id="searchengine" />
Friend <input type="radio" name="how" value="friend" id="friend" />
I don't know <input type="radio" name="how" value="dunno" id="dunno" />
<input name="submit" id="submit" value="submit" type="submit" />
<input type="submit" name="submit" id="submit" value="submit" tabindex="10" class="submit button" />
<input type="reset" name="reset" id="reset" value="reset" class="reset button" />
</fieldset>
</form>

I've provided a page that uses this mark-up as an example.

Now that we've completed the bare bones of our form, let's move on to solving accessibility issues and compliance with Section 508 and WCAG in Bulletproof Web Forms Part Two: Accessibility.

under:

Web Development

Posted on

2006-04-03