The Fat Slogs

Earlier today I asked for some feedback on twitter on how best to markup multiple inputs in a HTML form that may theoretically/logically share a single label. The most apparent example is a date form with separate inputs for DD/MM/YYYY.

In usual, dependable fashion answers were forthcoming from accessibility stalwarts (if that is the right term) Patrick H. Lauke and Bruce Lawson who offered the following responses respectively:

@cole007 fieldset, legend “date of birth”, hidden labels “day”, “month”, “year”

@cole007 3 separate inputs, each with a unique title, no label, in a fieldset with legend “Date”

These two solutions are perfect for my example of day/month/year, but what about less obvious examples and what about inputs that might have no obvious label or title.

At Net Resources, we are currently working on a search form for a client to query against a database on tartans.

One of the criteria you can search against is ‘slog’ which is to do with the thread count of a particular tartan. In official tartan parlance, a slog comprises of two three letter groups divided by a colon, eg. BGK:WRK. The logical break in the data means that the query input should ideally be broken into two divided with a colon, eg:


<label>Slog <input type="text" size="3" /> : <input type="text" size="3" /></label>

However, these slog fields do not have obvious names that can be applied through a title or hidden label, so my question is this. How best would you mark a form with these two inputs divided by a colon?
What – in your opinion – would be the most accessible, semantic, dogs bollocks approach to marking up this particular part of the form?

Comments

fieldset
legend Slog /legend
input title=“first nbit of slog
input title=“second bit of slog”

but I’d let them type in the slog in one go and strip out the colon programmatically.

I agree with Bruce and Pat on making it one field. In my opinion, the most awesome, accessible, semantic, dogs bollocks way to do this would be as follows:

[label for=one field][concise help text]
[one field to rule them all]
[/label]

label = slog
help text = two sets of three letters
one field to rule them all = up to 7 characters and strips out anything that’s not a letter and separates six into two threes if no separator is used.

Rationale:

Explicitly associating label with field = good.

Wrapping label around field = good for people with really really old tech.

Help text = good for people who don’t understand what a slog is and helps folk figure out what to put in there.

Positioning label above field = easier to see label and text field in the same glance and allows easy adjacent placement of help text. [1] Although, if it absolutely had to be adjacent rather than above, help text could be placed below the label, both right aligned against the field.

Help text in label = good for screen reader users (so long as its concise)

One field to rule them all that accepts variations on input = good for reducing the load on the user and the number of errors. [2]

From the end users point of view, they have all the information they need and it’s easy to use. WIN!

From the backend point of view, there’s an obvious requirement for more code to manipulate the input, but I’d suggest that it’s worth it, because none of the other solutions have the same ease of use across all user groups.

[1] Interesting piece of eyetracking research on label placement: http://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php

[2] Further eyetracking research on form design which I mostly agree with, except for the placement of help text: http://www.cxpartners.co.uk/thoughts/web_forms_design_guidelines_an_eyetracking_study.htm

Apologies for length. I’m apparently feeling verbose today. On which subject – any chance of a larger text box to facilitate the leaving of such epics? I’m all for white space, but I think you’ve plenty to go round and could expand both right and left a fair bit without cramping anything.

I’ll stop typing now.

If a slog always consists of 2 three letter bits separated by a colon then I’d use 1 field and have a help text for the user stating the format. A back-end should be smart enough to separate the input on the colon and validate it. That’s what we have regex’s for :)

In the Netherlands postal codes consist of 4 numbers followed by 2 letters. A space between them is considered optional. Only the 2 bits together make a postal code, the individual bits can’t really be named. I think the ‘slog’ you’re describing is quite similar.

I have to say that there are plenty of sites where they use 2 fields for a Dutch postal code but I seriously doubt if accessibility has been taken into account there.