W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2006

Re: a single label where multiple fields follow

From: Jon Ribbens <jon+w3c-wai-ig@unequivocal.co.uk>
Date: Fri, 22 Sep 2006 13:05:31 +0100
To: WAI Interest Group <w3c-wai-ig@w3.org>
Message-ID: <20060922120530.GN1708@snowy.squish.net>

Matthew Smith <matt@kbc.net.au> wrote:
> I find it totally ridiculous that anyone needs to insist on a certain
> presentational format, for instance breaking a sixteen digit credit card
> number into four lumps of four digits.  Entry of data like this should
> be free-form (within reason).  Any programmer can strip
> spaces/punctuation from input, or add if required.
> Users should be able to enter data as they feel comfortable, with no
> forced "artificial" formats.  Even things like British bank sort codes
> should be accepted as 309037, 30 90 37, 30 - 90 - 37 or the official
> 30-90-37.

Although I agree with your specific examples, and that credit card
numbers, for example, should be a single input field, I very much
disagree with your point in general. Data should only be accepted in a
small number of specific formats. Anything else comes under the
heading of "computers making guesses", and computers are very bad at
making guesses.

To use your bank sortcodes example, if someone were to enter
"22/09/06" in the sortcode box (easily done if it doesn't have a
proper <label> ;-) ), it is highly unlikely they meant it. The
computer can and should reject the unknown format, otherwise people
are in danger of losing their money.

A sortcode might perhaps be recognised by
  ^(\d{2})[ -]?(\d{2})[ -]?(\d{2})$
which provides a good balance between user-friendliness and error

As an aside, an anecdotal example of a bank getting it wrong in the
other direction is the NatWest, whose "find a branch" form won't
accept sortcodes in the official format "dd-dd-dd" but only as
"dddddd"! Of course, the instructions on the form don't mention this.
Received on Friday, 22 September 2006 12:05:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:34 UTC