Unfortunately neither of those pages show real-life forms with sometimes very short and other times very long labels. They made it very easy on themselves by having all short labels. As if almost to prove it can't be done with real forms.
*edit the howden one has two longer labels, though one has a text-area with a row number higher than the line-height of the label
I struggle with this almost daily, Bram. You get a few options, but may need to use one or the other per form depending on what you've got. I've scoured various CSS sites looking for "real life" forms and haven't found many that were all CSS and accessible. But this doesn't mean it can't be done.
One thing you can do is set a width for the labels. Yeah, I know you said you don't want to but in the example you posted, if they all had a width of "howeverman y" em you needed to accommodate the longest label, the inputs (naturally inline) would be kept at bay so their left sides all line up nicely as your image shows. So long as the form is wide enough to do this, of course.
I usually need something to wrap the labels and inputs to make them a unit, so that when longer labels are floated, the inputs of the following labels can't ride up too high.
I usually use a div for this, though I've seen p's used. I don't think they're paragraphs so I don't use them.
If you use divs and float the labels, you'll need something to make them enclose their floats. I'm currently using display: table just for them, but it makes firefox do the first render goofy (a refresh always fixes it). If my form is too long, Opera also starts having rendering issues with display: table so you may need something like overflow: hidden or the clearfix to do this instead. I had CSS tooltips so overflow wasn't an option for me... when there are no tooltips overflowing, then I use it as it's very easy. (hint: while building your forms, give the divs/whatever, the labels or whatever's floating and the fieldsets al ugly background colours so you can see who is where).
However if there are no help-text spans in your forms you can use the label itself as the wrapper, which can work very nicely. I saw this done by some crusty gurus at another forum:
-
<label for="name"><span>Name:</span><input type="text" name="blah" id="name"> </label>
-
See the form.
If the label is set to display: block, and clear: left just to be safe, the spans inside can be floated left (again, if they all have the same width then the inputs will be pushed the same distance away) and the inputs stay in the vicinity of their labels.
For a multi-input, there are a few options:
I often use a fieldset with the class of "access" for things like dates, because I'm forced to have three separate inputs for each chunk (day, month, year) and so I want a label for each (if you can't, using the title attribute on the inputs will work great in screen readers) but don't want visual surfers to see the labels.
fieldset.access has the border gone, the legend off-set by -9999em (watch out, firefox needs some extra code for this), has a p as a first child with the text for the long question (for the visual people) and then a traditional label-input setup, with the labels also offscreen by -999em.
-
<fieldset class="access">
-
<legend>Insurer birth date</legend>
-
<p>Birthdate of insured:</p>
-
<label for="day">Day: </label><input type="text" name="birthdate1" id="day" maxlength="2" size="2">
-
<label for="month">Month: </label><input type="text" name="birthdate2" id="month" maxlength="2" size="2">
-
<label for="year">Year: </label><input type="text" name="birthdate2" id="year" maxlength="4" size="4">
-
</fieldset>
-
Visual people will see the p as a question (and gets the same styling as regular labels, so it looks like a label), and then three inputs. Screen readers will of course ignore the p but will state the legend before each question, and the label before each input. So far has worked for me.
For radios and checkboxes, I often have a div or something with a class of "checkradio " so the labels in there don't inherit the styles of a regular labels (remain inline). This could also be in a fieldset instead, whatever works for you.
-
<div class="checkradio">
-
<label>How many oreos do you eat per day?</label> <--don't use a non-form control here or screen readers will miss it
-
<label for="none"><input type="radio" name="oreo" id="none"> None</label>
-
<lable for="some"><input type="radio" name="oreo" id="some"> A few</label>
-
<label for="lots"><input type="radio" name="oreo" id="lots"> A lot</label>
-
</div>
-
I've also seen where just checks and radios get their own box with a left margin equal to the width of the labels, or each label-input pair gets the margin... this is only safe when they don't have Layout in IE, otherwise IE will have the margin start in the wrong place while modern browsers do it correctly.
The css needs to have different styles for these different types. It starts out being more coding, but if the same css can work for many forms, it ultimately is faster as any new form can be created and will automatically get the styling you want, without anything more than form controls, possibly a few containers, and 2 or 3 classes (no more are really needed).
Tabled forms are always more HTML than necessary, and it uses the HTML to set the styling, mixing content and presentation. Also, if done incorrectly (as I usually see it) people with multi-column tabled forms often make the questions go in a strange source order. Using CSS can cure all this, if you're willing to spend a lot of time getting familiar with how browsers treat these form elements.
There are also some great styling forms tutorials out there, each with specific solutions to problems like the FireFox legend bug. Google "style forms css". The two Doc mentioned above will also appear, so look carefull at the code they use. I was very much not impressed with some of the forms listed on the silverback site, many using non-form controls like p's and otherwise inaccessible practises. Always look closely at the code, and avoid JS or Flash for the forms whenever possible.
8
