Creating the Identity Contact Form

Posted: Wed 7 Apr, 2010

When our Creative Director came up with the design for our new contact form, our web monkeys cried. Supporting a form styled to replicate a traditional writing experience relies on a multitude of hacks and technologies that fall into the category of "varying browser support levels". We're proud of our record of building sites that work in IE6/7/8 and all the usual alternatives (Firefox, Safari, Chrome, Opera), but it's a long time since we've seen a contact form looking like anything other than the usual input fields and textarea.

There's a reason for this.

Accessibility is a difficult term to apply to every situation, but in this case we have to look at it in the context of two audiences - blind/vision impaired visitors and users with a limited grasp of the internet.

Vision impaired audience

• We ensured that a traditional <form><fieldset><legend><label for="fieldname">Label text</a><input name="fieldname"></input></legend></fieldset></form> structure was used, so this works in the usual screen-readers such as JAWS.
• We kept labels in dark grey and used a high-contrast colour scheme
• All font sizes were converted to %age fonts using YUI Font Reset as a base, in order to work using the increase/reduce text sizes using browser zooming features.
• We used a large font size (24px equivalent) to compensate for the reduced legibility of our chosen font (Bell MT), and a fallback font which increased legibility, as the fallback font is likely to be seen on older computers (those without Office 2003/Windows XP or later installed).

Less technical users

A contact form isn't a contact if you can't recognise it as such - and this is the big reason that contact forms have majoritively turned back to default or system-based styling from the 2003-2005 options of changing border, font and background colours. Usability guidelines show us that the more familiar something is to people the easier it is to use, and our target audience is one that grew up with pen and paper. So having an underlined area to write in and an indication of what should go there works even more intuitively than something we've only been looking at for the last fifteen years or so.

Technical implementation - CSS:

We used:

@font-face {
font-family:'BellMTItalic';
src:url('UserSubmitted/Fonts/belli.eot');
src:local(':)'),url('UserSubmitted/Fonts/belli.woff')format('woff'),
url('UserSubmitted/Fonts/belli.ttf')format('truetype'),
url('UserSubmitted/Fonts/belli.svg#BellMT')format('svg');
}

to import Bell MT Italic, which was appropriately licensed under the terms of both Microsoft Office and Microsoft Windows 7 for use on the web. The order is based on Microsoft Internet Explorer 7 & 8 requiring the font used in .eot format, with other desktop web browsers requiring the font in .ttf format, and Apple's iPhone (and iPad) using Safari Mobile, which will only take a SVG version of the font. To make this easier, we used Font Squirrel's @font-face generator to transcode the font according to the settings shown on the right.

input[type=text], textarea { 
font-family: "BellMTItalic", "Bell MT";
font-size: 200%;
filter:progid:DXImageTransform.Microsoft.AlphaImageLoader
 (src=UserSubmitted/fonts/hIEfix.png,sizingMethod=crop);
zoom:1;
} 

This sets the text area and all single line non-password text fields to use the font-family specified in the @font-face declaration, with a font-size of 200% - in this case 24pixels or equivalent. If for any reason the @font-face imported font doesn't work, it falls back to Bell MT regular if installed (approx 47% of Windows PCs will have this font). The filter is a Microsoft Internet Explorer 7 & 8 specific hack which you may or may not want to use which turns off ClearType (the automated font smoothing used by the IE rendering engine), which with this font causes poor quality blurred and jagged edges (compared to using the hinting information integral to the standard font). The hIEfix.png is a blank, 1px x 1px transparent png image, used to create an invisible background with minimal page load impact, while the reason for using crop is that the filter has to do something (anything) for ClearType to be turned off, and crop is CPU light and doesn't change anything else. Internet Explorer is clever enough to recognise that it needs to do nothing much to something that's a 100% crop of itself. 

The zoom: 1 fixes an IE7 hasLayout bug. hasLayout is an IE7 rendering engine specific occurence, which governs which elements are rendered by their parents, and which render themselves. Obviously, if our special font rendering hack isn't handled by the place we're hacking it, it's not going to work. Microsoft thankfully got to grips with how stupid this was in IE8, and removed hasLayout altogether. 

textarea { overflow hidden; resize: none; }

Safari & Google Chrome both allow you to resize a textarea, and so we can set max-width & max-height to prevent an infinite resize. In this case, we prefer to use resize: 0; as it removes the drag handle from a form which looks like it shouldn't have one. Likewise, Internet Explorer shows a disabled scrollbar on all textareas by default, to prevent the page jumping if content should end up overflowing the window and causing a scrollbar to become needed. Here, we hide it by governing how content overflows it's container - in this case it doesn't. Longer messages instead cause the top of the content within the textarea to scroll off the top of the page.

Next, we prettied up the form:

{ border: 0; background: transparent url() repeat left -3px; line-height: 25px;  }

Firstly we remove the border, and then we create a 1px x 25px tiling image containing a dark grey 1px x 1px dot, and tile this horizontally and vertically. We offset it vertically to provide a visually appealing baseline across all modern browsers by manually checking in each target browser (Safari renders the background image one pixel closer to the baseline than the other browsers). Then we use the line-height property to make sure text remains aligned to the baseline. While we wouldn't usually use pixels for anything, in this case it's imperative as Mac Safari and Mac Firefox both handle em or % based resizing of Bell MT badly, and round sizes up enough to cause visible issues within 3-4 lines.