Fancy Form Design Using CSS Article

By Cameron Adams

Every day this week, we’ll be publishing an article that’s been hand picked by our editor, as part of CSS Theme Week.

Forms. Is there any other word that strikes as much fear into the hearts of grown web designers?

I think that the reputation of forms as an untamable, ugly necessity has arisen for two reasons:

  • Form elements are derived from native operating system widgets, which makes them particularly difficult to style.
  • Forms are often critical to the function of a web site — they’re most often employed as search boxes, inquiry forms, or shopping cart checkouts — and need to function as smoothly as possible in order to meet user expectations.

However, it’s still possible to incorporate both these points into designing a form tailored to the style of the rest of your site. This chapter, which is fresh from The Art and Science of CSS, will explore the ways in which you can design a great-looking form, and provide you with the necessary code, which we’ll work through together. You can also download this article as a PDF.

Accessible Form Markup

Before we can begin to look at form layout, we need to craft some really solid markup that will provide us with a framework to which we can add some style.

Forms represent the one area of your web site where you absolutely must commit time and energy to ensure user accessibility. Even though forms represent some of the most complex interactions that can occur on a web page, in many cases these interactions are only represented visually — via the proximity of a form element to its label, or grouping by borders and background colors. Users of assistive technology such as screen readers may not be able to see these visual clues, so it’s vital that you support these users by ensuring accessibility. The key concept behind providing an accessible form is to have descriptive labeling of all its sections and input elements.

In particular, this means the proper usage of two elements: label and legend.

There’s also an improperly held belief that the only way you can guarantee that a form displays properly is by using tables. All of the code reproduced here for forms is standards-based, semantic markup, so you’ve got no excuse for relying on tables now!

Labeling Form Elements

No matter how you style a form element and its label, it generally conforms to a certain pattern:

  • the form element itself
  • a text label for the element
  • a connection between the element and its textual description

This connection is made either through visual alignment, visual grouping, or some other visual indicator. In Figure 1, you can see that the form on the left makes a connection between the field element and its label purely through alignment, whereas the form on the right indicates a more explicit connection via the use of color.

Figure 1: Visual connections in forms (See larger image in new window.)

When accommodating users of assistive technology in the creation of your forms, there’s one main question to consider. How can a user who’s unable to see a web page create the connection between a form element and its text label, without the visual cues of proximity or grouping?

The answer is the label element. label is a special element applied to a form element to allow its textual description to be semantically linked to the element itself, so any assistive technology such as a screenreader can read out that text when it encounters its partner form element.

In order to use a label, wrap the textual description in a pair of label tags, then add a for attribute to the label. The value of the for attribute should be the id of the form element with which you want to create a connection:

<label for="firstName">First name</label>
<input id="firstName" name="firstName" type="text" />

Now, when a screenreader encounters the firstName field, it’ll also read out the text “First name” to the user, so he or she will know what to type into that field. The label doesn’t have to be near the form element and neither of them have to be in any particular order — as long as the label‘s for attribute contains a valid reference, the relationship will be understood. However, having the label right before the form element in the source order generally makes the most semantic sense.

A label should be applied to any form element that doesn’t automatically include descriptive text, such as:

Submit buttons and submit images don’t require label elements, because their descriptions are contained, respectively, in their value and alt attributes.

Of course, you can easily style the text inside the label using CSS, so you can format the label text in your forms in the same way as if you were using a span, p, or div, but using a label has the benefit of being much more accessible than any of those elements.

Grouping Related Elements
legend goes hand in hand with fieldset. In fact, the only element of which a legend can be a child is a fieldset. A fieldset groups a series of related form elements. For instance, “street address,” “suburb,” “state,” and “zip code” could all be grouped under “postal address.” You could create a fieldset that groups all of those elements, and give it an appropriate legend to describe that group:

<form action="example.php">
<legend>Postal Address</legend>
<label for="street">Street address</label>
<input id="street" name="street" type="text" />
<label for=" suburb">Suburb</label>
<input id="suburb" name="suburb" type="text" />
<label for="state">State</label>
<input id="state" name="state" type="text" />
<label for="postcode">Postcode</label>
<input id="postcode" name="postcode" type="text" />

Now that legend is associated with all those form elements inside the fieldset, when a person using a screenreader focuses on one of the form elements, the screenreader will also read out the legend text: “Postal Address; Suburb.”
The benefit of the screenreader specifying both legend and fieldset becomes apparent when you have two groups of elements that are very similar, except for their group type:

<form action="example.php">
<legend>Postal Address</legend>
<label for="street">Street address</label>
<input id="street" name="street" type="text" />
<label for=" suburb">Suburb</label>
<input id="suburb" name="suburb" type="text" />
<label for="state">State</label>
<input id="state" name="state" type="text" />
<label for="postcode">Postcode</label>
<input id="postcode" name="postcode" type="text" />
<legend>Delivery Address</legend>
<label for="deliveryStreet">Street address</label>
<input id="deliveryStreet" name="deliveryStreet"
type="text" />
<label for="deliverySuburb">Suburb</label>
<input id="deliverySuburb" name="deliverySuburb"
type="text" />
<label for="deliveryState">State</label>
<input id="deliveryState" name="deliveryState"
type="text" />
<label for="deliveryPostcode">Postcode</label>
<input id="deliveryPostcode" name="deliveryPostcode"
type="text" />

As Figure 2 shows, with the fieldset‘s legend elements in place it’s quite easy to determine visually which fields fall under which group, even on an unstyled form.

Figure 2: Unstyled form using fieldset and legend elements for grouping (See larger image in new window.)
But, you ask, couldn’t the same visual effect be achieved using h1 elements instead of legend elements?
Yes. However, the point of using legend is that without proper semantic grouping and labeling, a screenreader user would become confused as to why he or she was required to enter “Address 1” twice. With the legend included, the user will know that the second “Address 1” actually belongs to another group — the group for the delivery address.
So, by combining label and legend, we give visually impaired users the ability to navigate and fill in our forms much more easily. By using this combination as the basic structure for your forms, you’ll ensure that not only will they look fantastic, but they’ll be accessible as well!

Form Layout

There are several different ways in which you can lay out a form. The method you choose depends upon how long the form is, its purpose, how often it will be used by each person who has to fill it out, and, of course, the general aesthetics of the web page.
It’s generally considered most efficient to have one form element per line, with the lines stacked sequentially one on top of the other, as most Western-language web pages are designed to scroll vertically rather than horizontally. This allows users to follow the path to completion easily and focus their attention on entering one piece of data at a time.
For each form element in a left-to-right reading system, it’s logical to position the corresponding label in one of three ways:

  • directly above the form element
  • in a separate left column, left-aligned
  • in a separate left column, right-aligned

Each of these approaches has its own advantages and its own look, so consider these options when you’re deciding how to lay out a form for a particular page.
Labels that are positioned directly above a form element have been shown to be processed most quickly by users. The compact grouping between label and element reduces eye movement by allowing the user to observe both simultaneously — here’s an excellent article published by UXmatters. However, this type of positioning is rather utilitarian, and isn’t the most aesthetically pleasing layout. It also has the disadvantage of occupying the most vertical space of the three layouts, which will make a long form even longer. Generally, top-positioned labels work well for short forms that are familiar to the user — see the comment form in Figure 3, which is from a previous incarnation of the Dress For Dialogue web site.

Figure 3: Labels positioned above form elements
Labels that are positioned in a column to the left of the elements look much more organized and neat, but the way in which the text in those labels is aligned also affects the usability of the form.
Right-aligning the text creates a much stronger grouping between the label and the element. However, the ragged left edge of the labels can make the form look messy and reduces the ability of users to scan the labels by themselves, as Luke Wroblewski argues in his article on the subject. In a left-aligned column, the labels instantly become easier to scan, but their grouping with the associated form elements becomes weaker. Users have to spend a little more time correlating the labels with their elements, resulting in slower form completion. An example of left-aligned labels can be seen in Figure 4.

Figure 4: Labels positioned in a column and aligned left — The Man in Blue
The right-aligned column layout shown in Figure 5 allows for quicker association between label and element, so again it’s more appropriate for forms that will be visited repeatedly by the user. Both layouts have the advantage of occupying a minimal amount of vertical space.

Figure 5: Labels positioned in a column and aligned right — LinkedIn

Go to page: 1 | 2 | 3 | 4 | 5 | 6 | 7

Free Guide:

7 Habits of Successful CTOs

"What makes a great CTO?" Engineering skills? Business savvy? An innate tendency to channel a mythical creature (ahem, unicorn)? All of the above? Discover the top traits of the most successful CTOs in this free guide.

No Reader comments

Because We Like You
Free Ebooks!

Grab SitePoint's top 10 web dev and design ebooks, completely free!

Get the latest in Front-end, once a week, for free.