Blog

Contact Form Experiment

Yesterday, I saw this tweet from Smashing Magazine:

Tweet from Smashing Magazine

Tweet from Smashing Magazine

I took a look at the form, and I must say I was impressed too.  Unfortunately, I was using TweetDeck on my iPhone… as a result, I didn’t see the contact form at all because the background image didn’t load very fast.  That prompted me to post this reply:

My reply on Twitter

My reply on Twitter

Being a social media junkie, this tweet was then cross-posted to my Facebook, prompting this reply from a web developer friend of mine:

...the resulting Facebook conversation.

...the resulting Facebook conversation.

As you can well imagine, I could not let this stand.  So I decided I would refactor the form to prove that, with a few tweaks to the CSS and markup, this form could avoid the problems I pointed out.

First, let me preface by saying that I am not saying the code is bad… on the contrary, I really like the concept.  I just want to:

  1. Dispel my friend’s poor logic, and
  2. Raise awareness about accessibility.

That said, I tried to minimize my changes to the original code as much as possible; there are certainly improvements that can be made to the CSS and to the markup, but that was not my goal.

For reference, here are the before and the after demo pages.  I’d load them in separate tabs; you’ll see they are identical, almost to the pixel.  I’ve also added a scripted link to allow you to hide the background image.

The Accessibility Problem

First, let’s define the problem. In the existing CSS, the labels are completely hidden and the background is applied to the form.  As a result, here are screen shots of the contact form, with and without its background image, (notice the dotted lines for each form field):

The contact form with images on and fully loaded

The contact form with images on and fully loaded

The contact form without the image loaded

The contact form without the image loaded

Without the image, the form becomes unusable.  So how can we edit the HTML and style the form to avoid this?

The Approach

In short, we need to add labels to each field and have the image hide them if present.  This can be accomplished with z-indexing:

A diagram of the layout

A diagram of the layout

The Solution

First, I refactored the original form into something a bit more manageable, such as adding a fieldset element to the phone number, adding a header element and consolidating the label and input fields, (and thus removing the pesky “for” attribute):

...
<h3><span>Contact Form</span></h3>
...
<fieldset id="phone-el">
    <legend><span>Phone</span></legend>
    <p id="phone-ac-el">
        <label>
            <span>Area Code</span>
            <input id="phone-ac" class="text" maxlength="3"
                name="phone-ac" size="3" type="text" />
        </label>
    </p>
...

Since the legend for the phone fieldset wasn’t being displayed, I decided I would forgo the addition of any empty element and just use it for the contact form.  A bit of positioning based on existing CSS and some negative text-indent and we were in business:

body#contact #form legend span {
    background: url(res/contact-content.png) center top no-repeat;
    position: absolute;
    top: -199px;
    left: -180px;
    width: 750px;
    height: 786px;
    display: block;
    text-align: left;
    text-indent: -1000px;
    overflow: hidden;
    z-index: 50;
}

The Result

Now, when the page loads and no images are present, the form looks like this:

My refactor of the contact form without the image

My refactor of the contact form without the image

With a few simple changes, the form is completely usable… bulletproof… regardless of the user’s situation.

A Few Closing Remarks

I hate the oft-uttered mantra of, “those folks aren’t in my demographic.”  That is a dangerous and amateur view of an audience for your website.  You should always be looking to make your forms as simple but as accessible as possible, because, frankly… your demographic is anyone with a web browser.  Discounting any percentage is not only a disadvantage for your business, but a disservice to all users.

2 Awesome Comments So Far

Don't be a stranger, join the discussion by leaving your own comment
  1. Mike
    October 22, 2009 at 2:49 pm #

    Well presented Clint. I strongly agree with the semantic and accessible approach. At first I did it because it was right; now I do it because it performs better, its easier to read, easier to maintain, and easier to style.

  2. Patrick Denny
    October 22, 2009 at 5:56 pm #

    Hi there,
    I’m the original site owner. I appreciate the work you did on this, and will probably recode my form to include a variation of your solution on my site (I’ll leave credit and a pointer back to this post in the HTML source when I’m done).

    However, I feel I must explain my initial design decisions, at least partially.

    First off, yes. I did justify my decision to hide the labels behind a “know your target audience” excuse, but – as your facebook friend mentioned – I knew my site visitors would be individuals looking for a web developer/designer, and expect to see graphic heavy content (it is a portfolio site). It was a decision I made only due to the fact that many other fairly prominent designers and developers had decided to use similar graphical text replacement techniques despite this short coming.

    That said, I used the screen media type so that mobile browsers (other than iPhone) got straight up html, with text labels intact, and the labels were hidden in a manner that made them accessible to screen readers. Also, while the page linked to by Smashing didn’t have any other contact info, the form was originally for my contact page. That page does also list several other ways of contacting me – email, phone, snail mail, twitter – so that even if someone couldn’t use the form for what ever reason, they would still have other options available to them. You see, accessibility isn’t always about limiting yourself (or jumping through crazy hoops) so that everyone has the exact same access to an interface. Sometimes it’s about offering a reasonable (if somewhat clunkier) alternative when non-accessible techniques are utilized.

    However, I admit that the image is large and slow to load. I’m still trying to find a way of compressing it that keeps its fidelity and alpha channel intact. I also think that I could have added title attributes to the form elements to allow someone a method of deducing the use of each field without the graphic available.

    Again,
    Thanks. I like the solution you came up with.

Leave a Comment

Remember to play nicely folks, nobody likes a troll.