With the basics out of the way, we now look in more detail at the elements used to provide structure and meaning to the different parts of a form.
|Prerequisites:||Basic computer literacy, and a basic understanding of HTML.|
|Objective:||To understand how to structure HTML forms and give them semantics so they are usable and accessible.|
The flexibility of HTML forms makes them one of the most complex structures in HTML; you can build any kind of basic form using dedicated form elements and attributes. Using correct structure when building an HTML form will help ensure that the form is both usable and accessible.
The <form> element
<form> element formally defines a form and attributes that determine the behavior of this form. Each time you want to create an HTML form, you must start it by using this element, putting all the contents inside. Many assistive technologies or browser plugins can discover
<form> elements and implement special hooks to make them easier to use.
We already met this in the prevous article.
Note that it's always possible to use a form widget outside of a
Note: HTML5 introduces the
form attribute on HTML form elements. It should let you explicitly bind an element with a form even if it is not enclosed within a
<form>. Unfortunately, for the time being, the implementation of this feature across browsers is not yet good enough to rely on it.
The <fieldset> and <legend> elements
<fieldset> element is a convenient way to create groups of widgets that share the same purpose, for styling and semantic purposes. You can label a
<fieldset> by including a
<legend> element just below the opening
<fieldset> tag. The text content of the
<legend> formally describes the purpose of the
<fieldset>. It is included inside.
Many assistive technologies will use the
<legend> element as if it is a part of the label of each widget inside the corresponding
<fieldset> element. For example, some screen readers such as Jaws or NVDA will speak the legend's content before speaking the label of each widget.
Here is a little example:
<form> <fieldset> <legend>Fruit juice size</legend> <p> <input type="radio" name="size" id="size_1" value="small"> <label for="size_1">Small</label> </p> <p> <input type="radio" name="size" id="size_2" value="medium"> <label for="size_2">Medium</label> </p> <p> <input type="radio" name="size" id="size_3" value="large"> <label for="size_3">Large</label> </p> </fieldset> </form>
When reading the above form, a screen reader will speak "Fruit juice size small" for the first widget, "Fruit juice size medium" for the second, and "Fruit juice size large" for the third.
The use case in this example is one of the most important. Each time you have a set of radio buttons, you ought to nest them inside a
<fieldset> element. There are other use cases, and in general the
<fieldset> element can also be used to section a form. Ideally long forms should be split across multiple pages, but if a form is getting long but has to be on a single page, putting the different related sections inside different fieldsets can improve usability.
Because of its influence over assistive technology, the
<fieldset> element is one of the key elements for building accessible forms; however it is your responsibility not to abuse it. If possible, each time you build a form, try to listen to how a screen reader interprets it. If it sounds odd, try to improve the form structure.
The <label> element
As we saw in the previous article, The
<label> element is the formal way to define a label for an HTML form widget. This is the most important element if you want to build accessible forms — when implemented properly, screenreaders will speak a form element's label along with any related instructions. Take this example, which we saw in the previous article:
<label for="name">Name:</label> <input type="text" id="name" name="user_name">
<label> associated correctly with the
<input> via their
id attributes respectively (the label
for attribute references the
id attribute of the corresponding widget), a screenreader will read out something like "Name, edit text".
If the label isn't set up correctly, a screenreader will only read out something like "Edit text blank", which isn't very helpful at all.
Note that a widget can be nested inside its
<label> element, like so:
<label for="name"> Name: <input type="text" id="name" name="user_name"> </label>
Even in such cases however, it is considered best practice to set the
for attribute because some assistive technologies do not understand implicit relationships between labels and widgets.
Labels are clickable, too!
Another advantage of properly set up labels is that you can click the label to activate the corresponding widget, in all browsers. This is useful for examples like text inputs, where you can click the label as well as the input to focus it, but it is especially useful for radio buttons and checkboxes — the hit area of such a control can be very small, so it is useful to make it as big as possible.
<form> <p> <label for="taste_1">I like cherry</label> <input type="checkbox" id="taste_1" name="taste_cherry" value="1"> </p> <p> <label for="taste_2">I like banana</label> <input type="checkbox" id="taste_2" name="taste_banana" value="2"> </p> </form>
Strictly speaking, you can put multiple labels on a single widget, but this is not a good idea as some assistive technologies can have trouble handling them. In the case of multiple labels, you should nest a widget and its labels inside a single
Let's consider this example:
<p>Required fields are followed by <abbr title="required">*</abbr>.</p> <!-- So this: --> <div> <label for="username">Name:</label> <input type="text" name="username"> <label for="username"><abbr title="required">*</abbr></label> </div> <!-- would be better done like this: --> <div> <label for="username"> <span>Name:</span> <input id="username" type="text" name="username"> <abbr title="required">*</abbr> </label> </div> <!-- But this is probably best: --> <div> <label for="username">Name: <abbr title="required">*</abbr></label> <input id="username" type="text" name="username"> </div>
The paragraph at the top defines the rule for required elements. It must be at the beginning to make sure that assistive technologies such as screen readers will display or vocalize it to the user before they find a required element. That way, they will know what the asterisk means. A screen reader will speak the star as "star" or "required", depending on the screen reader's settings — in any case, what will be spoken is made clear in the first paragraph).
- In the first example, the label is not read out at all with the input — you just get "edit text blank", plus the actual labels are read out separately. The multiple
<label>elements confuse the screenreader.
- In the second example, things are a bit clearer — the label read out along with the input is "name star name edit text", and the labels are still read out separately. Things are still a bit confusing, but it's a bit better this time because the input has a label associated with it.
- The third example is best — the actual label is read out all together, and the label read out with the input is "name star edit text".
Note: You might get slightly different results, depending on your screenreader. This was tested in VoiceOver (and NVDA behaves similarly). We'd love to hear about your experiences too.
Note: You can find this example on GitHub as required-labels.html (see it live also). don't run the example with 2 or 3 of the versions uncommented — screenreaders will definitely get confused if you have multiple labels AND multiple inputs with the same ID!
Common HTML structures used with forms
Beyond the structures specific to HTML forms, it's good to remember that forms are just HTML. This means that you can use all the power of HTML to structure an HTML form.
As you can see in the examples, it's common practice to wrap a label and its widget with a
<p> elements are also commonly used, as are HTML lists (the latter is most common for structuring multiple checkboxes or radio buttons).
Above all, it is up to you to find a style that you find comfortable to code with, and which also results in accessible, usable forms.
Active learning: building a form structure
Let's put these ideas into practice and build a slightly more involved form structure — a payment form. This form will contain a number of widget types that you may not yet understand — don't worry about this for now; you'll find out how they work in the next article (The native form widgets). For now, read the descriptions carefully as you follow the below instructions, and start to form an appreciation of which wrapper elements we are using to structure the form, and why.
- To start with, make a local copy of our blank template file and the CSS for our payment form in a new directory on your computer.
- First of all, apply the CSS to the HTML by adding the following line inside the HTML
<link href="payment-form.css" rel="stylesheet">
- Next, start your form off by adding the outer
- Inside the
<form>tags, start by adding a heading and paragraph to inform users how required fields are marked:
<h1>Payment form</h1> <p>Required fields are followed by <strong><abbr title="required">*</abbr></strong>.</p>
- Next we'll add a larger section of code into the form, below our previous entry. Here you'll see that we are wrapping the contact information fields inside a distinct
<section>element. Moreover, we have a set of two radio buttons, each of which we are putting inside its own list (
<li>) element. Last, we have two standard text
<input>s and their associated
<label>elements, each contained inside a
<p>, plus a password input for entering a password. Add this code to your form now:
<section> <h2>Contact information</h2> <fieldset> <legend>Title</legend> <ul> <li> <label for="title_1"> <input type="radio" id="title_1" name="title" value="M." > Mister </label> </li> <li> <label for="title_2"> <input type="radio" id="title_2" name="title" value="Ms."> Miss </label> </li> </ul> </fieldset> <p> <label for="name"> <span>Name: </span> <strong><abbr title="required">*</abbr></strong> </label> <input type="text" id="name" name="username"> </p> <p> <label for="mail"> <span>E-mail: </span> <strong><abbr title="required">*</abbr></strong> </label> <input type="email" id="mail" name="usermail"> </p> <p> <label for="pwd"> <span>Password: </span> <strong><abbr title="required">*</abbr></strong> </label> <input type="password" id="pwd" name="password"> </p> </section>
- Now we'll turn to the second
<section>of our form — the payment information. Here we have three distinct widgets along with their labels, each contained inside a
<p>. The first is a drop down menu (
<select>) for selecting credit card type. the second is an
<input>element of type number, for entering a credit card number. The last one is an
<input>element of type
date, for entering the expiration date of the card (this one will come up with a date picker widget in supporting browsers, and fall back to a normal text input in non-supporting browsers). Again, enter the following below the previous section:
<section> <h2>Payment information</h2> <p> <label for="card"> <span>Card type:</span> </label> <select id="card" name="usercard"> <option value="visa">Visa</option> <option value="mc">Mastercard</option> <option value="amex">American Express</option> </select> </p> <p> <label for="number"> <span>Card number:</span> <strong><abbr title="required">*</abbr></strong> </label> <input type="text" id="number" name="cardnumber"> </p> <p> <label for="date"> <span>Expiration date:</span> <strong><abbr title="required">*</abbr></strong> <em>formatted as mm/yy</em> </label> <input type="text" id="date" name="expiration"> </p> </section>
- The last section we'll add is a lot simpler, containing only a
submit, for submitting the form data. Add this to the bottom of your form now:
<p> <button type="submit">Validate the payment</button> </p>
You now have all the knowledge you'll need to properly structure your HTML forms; the next article will dig into implementing all the different types of form widget you'll want to use to collect information from your users.