|
Fancy Form Design Using CSS
:
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 article, 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.
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:
· checkboxes
· radio buttons
· textareas
· text fields
· select boxes
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">
<fieldset>
<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" />
</fieldset>
</form>
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">
<fieldset>
<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" />
</fieldset>
<fieldset>
<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" />
</fieldset>
</form>
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.
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.
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.
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.
Rock-solid CSS Layouts:
This article is excerpted from SitePoint's HTML Utopia: Designing Without Tables
Using CSS, Second Edition, which provides a complete introduction to CSS and
shows you how to build rock-solid CSS-based web sites from scratch. By the end
of the article's 12 articles, you'll understand the ins and outs of CSS, and
you'll be able to create robust, standards-compliant site designs that degrade
gracefully in older browsers and are easy to maintain.
You can download this article in PDF format, along with the first three articles
of the article, if you'd prefer to read it offline. Now, let's get started
building your CSS-based page layout!
We now have some sound theory under our belts. The rest of this article will
concentrate on how you can put CSS into practice when developing your own sites.
Along the way, we'll be learning how to lay out pages using CSS—moving from
simple layouts to more complex ones—and how you can combine some of the concepts
you've already read about to create great-looking sites.
This article will start with the creation of a simple two-column layout. Along
the way, we'll discover how to use absolute and relative positioning, and see
how margins, padding, and borders work together. Then, we'll get an
understanding of how all these tools can be used together in practice by
creating a two-column layout that uses many of the techniques we have discussed
already in this article.
While the layout we'll create in this article is a relatively simple one, it's a
structure that's used by many web sites; the layout we'll develop here could
easily form the basis for a production site.
The Layout
Many web site designs start life as mock-ups in a graphics program. Our first
example site is no exception: we have an example layout or "design comp" created
in Fireworks as a starting point.
Figure 8.1. Creating the layout as an image file
Starting out with a visual like this enables us to think about the way we're
going to build the site before we start to write any XHTML or CSS. It gives us
the opportunity to decide how best to approach this particular layout before we
code a single line.
This layout divides the page into three main sections: a header, which contains
the site logo and some main navigation; a main content area comprising a large
image above a list of news stories; and a sidebar, which presents some
additional items.
This layout could be described as a two-column layout with a header area. Being
able to visualize a design as being a combination of its main sections eases the
process of deciding how to approach the page layout.
Creating the Document
Having decided what the basic components of our page will be, we can start work.
The first thing we'll do is create an XHTML document that contains all of the
text elements we can see in our layout image, marked up using the correct XHTML
elements.
Working this way might seem a little strange at first, particularly if you have
been used to working in a visual environment, such as Dreamweaver, and simply
concentrating on how the design looks. However, one of the advantages of using
CSS for layout is that we're able to separate the structure of the page from its
appearance. This allows us to concentrate on building a good solid document as
the basis of our site, before adding the design using CSS.
We start out with the basic requirements for an XHTML Strict document. As we're
going to use CSS for all of the presentational information on this site, there's
no reason not to use a Strict DOCTYPE. The Transitional DOCTYPEs (for both XHTML
and HTML 4.01) allow you to use attributes and elements that are now deprecated
in the W3C Recommendations. The deprecated elements and attributes are mainly
used for presentation, and as we're going to use CSS—not XHTML—for presentation,
we won't need to use these anyway.
Example 8.1. index.html
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Footbag Freaks</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1" />
</head>
<body>
</body>
</html>
Declaring the Character Set
In our pages, we've used the meta element with the http-equiv="Content-Type"
attribute to declare our document's character set. This makes it easy for
browsers (and the W3C validator) to determine which character set is being used
in the document. If this information was missing, a browser could misinterpret
the characters in your page, which could see your pages rendered as
unintelligible garbage.
All of the examples in this article use ISO-8859-1 encoding, which is the
default for most popular text editors and programs such as Dreamweaver. If
you're dealing with a different character set, such as Unicode, you'll need to
change the meta elements accordingly.
The Header
Let's start to add the content of this page to our document. As we do so, we'll
split it up into the various sections identified above, containing each page
section between <div> and </div> tags. We'll give each div an id to identify
that section; we'll use these ids to address each section and style it using
CSS.
After the <body> tag, add the following markup:
Example 8.2. index.html (excerpt)
<div id="header">
<p>The Home of the Hack</p>
<ul>
<li><a href="">Contact Us</a></li>
<li><a href="">About Us</a></li>
<li><a href="">Privacy Policy</a></li>
<li><a href="">Sitemap</a></li>
</ul>
</div> <!-- header -->
|
BE
COMFORT