A lot of sites use forms; it's an ideal way to submit information (how else are you supposed to do it?), but how many actually use forms properly? How many have semantically-correct markup?

Let's start by looking at the elements you should use in a form:

• <form>
• <fieldset>
• <legend>
• <label>
• <input />
• <textarea>
• <select>
• <option>
• <optgroup>
• <button>

When used properly, these create forms which are both accessible and semantically correct, so other computers can extract information from the forms' markup. However, most websites only make use of a subset of this list of elements, with usually only five elements being used:

• <form>
• <input />
• <textarea>
• <select>
• <option>

You'll notice that the <fieldset>, <legend> and <label> tags are missing, and that's what makes most forms poor.

The <label> tag is the easiest to add, and solves most of the accessibility problems associated with badly-coded forms. As the name suggests, it provides a label for a form control, but this label is associated with the element through the use of the for attribute, so that when a user clicks on the label, focus will be given to the associated form control.

<label for="example_input">This is an example input, using the <tt>&lt;input /&gt;</tt> element.</label><input id="example_input" type="text" value="Example input" />

You have two options when using a <label> element. The first is to write a short label (e.g. "Example input" for the above markup), and the second is to write a longer and more informative label (e.g. what's in the above markup). As far as the specifications go, neither is incorrect. Personally, I believe the latter is the better, as it provides more help as to how to use the form control, and a simple label can be provided by the <legend> tag, which is discussed later.

One thing many web developers do when using labels is to place the associated form control inside the label, after (or before) the label text. Although this is permitted by the specifications, it provides no advantage, and just makes the markup ungainly.

The <fieldset> element is next on the list, and it's quite important. It allows form controls to be grouped together in logical sections.

<fieldset>
<label for="example_input">This is an example input, using the <tt>&lt;input /&gt;</tt> element.</label><input id="example_input" type="text" value="Example input" />
</fieldset>

How you group form controls is very much your own choice. Personally, I stray a little on the wild side and usually assign a fieldset to each form control. This is perhaps segregating them too finely, and is something I should work on to change. One example of a good group would be "Personal details".

Fieldsets by default appear without a label, which isn't very helpful to users, and isn't very good for accessibility (screenreaders don't know anything about the grouping), so you can use the <legend> element to assign a label to a fieldset, much like a <label> assigns a label to a form control.

<fieldset>
<legend>Personal details</legend>
<label for="example_input">This is an example input, using the <tt>&lt;input /&gt;</tt> element.</label><input id="example_input" type="text" value="Example input" />
</fieldset>

The <legend> tag must come directly after the opening part of the <fieldset> tag, or it is invalid.

Another little-used form element is the <optgroup> element. It's old, dating back a long time, but not many people are aware of its existence (or if they are, they don't use it). It's used to group <option> elements together logically in a selection list.

<select id="example_select">
<optgroup label="First group">
<option value="1" selected="selected">1</option>
<option value="2">2</option>
</optgroup>
<optgroup label="Second group">
<option value="3">3</option>
<option value="4">4</option>
</optgroup>
</select>

The option group's label value is required, and specifies the label to display as the title for the group.

The final element most authors don't use is the <button> element. I must confess that I didn't know much about it until I read the W3C's definition:

Buttons created with the BUTTON element function just like buttons created with the INPUT element, but they offer richer rendering possibilities: the BUTTON element may have content. For example, a BUTTON element that contains an image functions like and may resemble an INPUT element whose type is set to "image", but the BUTTON element type allows content.

Visual user agents may render BUTTON buttons with relief and an up/down motion when clicked, while they may render INPUT buttons as "flat" images.

The <button> element offers rich possibilities, but you must always remember the accessibility concerns when using it. Would a screen reader read content which is inside a button? Common sense should prevail.

The final point to make about form authoring is that of ease-of-use. It it just about always in one's interest to make a form as easy to use as possible, and just by using the accesskey and tabindex attributes a complex form can be easy to use.

The accesskey attribute can be applied to:

• <a>
• <area />
• <button>
• <input />
• <label>
• <legend>
• <textarea>

The character (from the document's character set) in the attribute value will – when pressed – give focus to the element. This doesn't have to just be used for form controls; you could give the access key of "H" to a home link. However, form controls are the main use of accesskey. In my opinion, it's best to be careful with your use of access keys, applying them only to general elements such as the "Submit" and "Reset" buttons to cut down on maintenance when you come to add to the form.

The tabindex attribute can be applied to:

• <a>
• <area />
• <button>
• <input />
• <object>
• <select>
• <textarea>

The number in the attribute specifies the tab order of the element, with lower numbers coming before higher ones (except "0", which puts the element last). Elements with identical tab indexes will be focussed in the order they appear in the markup. Usually there's no need to change the tab order of elements in a form, as it's usually calculated properly by the browser, but in some cases (especially if you're moving things around a lot with CSS) it's necessary to intervene and change the tab order manually.

That's it. If you knew how to make decent forms before, the information here should enable you to write splendid ones.