[thelist] Fomated tet box question

Chris Heilmann lists at onlinetools.org
Wed Mar 9 09:08:12 CST 2005

> Designing with accessibility in mind, but for the majority of users is not
> a
> bad thing. Drop down lists are not wholly inaccessible, especially when
> labelled correctly. Also, the system need not be all things to all men -
> display page output according to the user agent.

I never claimed dropdowns are inaccessible, I consider them inflexible and
harder to use even with a mouse and the newest browsers.
Checking the user agent is finicky at best. We tried that before during
the browser wars and failed miserably. What a system can do is build up
gradually, for example a simple text box getting a popup calendar when
JavaScript is available or staying a simple box when it isn't.

> When the subject of
> accessibility comes up, many people seem to forget that the group to which
> accessibility issues apply the most are the tiny minority. By all means
> make
> sites accessible, but don't lose sight of the fact that for the most part
> the vast majority of users will *not* be using a screen reader.

But a keyboard for example. I spend about £300 a month online and book
flights for the company worth £2k. I use a laptop and a trackpointer. Most
of the time I use the keyboard though. I am not part of a "disabled
minority", but cannot be bothered to use three dropdowns.
Good accessibility most of the time also means good usability, the other
way around is trickier (a drag and drop interface is highly usable to a
mouse/visual visitor, but useless with a keyboard).
http://www.expedia.co.uk/daily/home/Default.asp?CCheck=1& for example
features a great example of a usable and accessible date box (sadly enough
on IE only).

YMMV though.

> The "extra" logic referred to is to handle the fact that 02/03/05 and
> 02/03/05 are totally different dates depending on whether you hail from
> the
> US or the UK. If you have a seperate form field for each date part, then
> no
> *extra* logic is required on the server to figure out which is which.

Ah, true, however shouldn't the form tell me the expected format in the
label? Clever systems change the date format according to the
language/locale you selected. When I offer an English site for American
users I allow for American dates, for the English, I offer English. We
developed a 18 languages portal for the UK here, most of these issues are
dealt with by a good CMS/Templating solution.

>> Validation is partly our problem, we shouldn't share it with the user.
> Surely if validation is our problem, then the average user will be less
> inconvenienced with a select box date input than a text field input?
> Regardless of labels or other instructions, if you allow a user free input
> they *will* make errors - even the user most attentive to instructions
> makes
> typographical errors every now and again.

The process is entering some digits into a field or selecting from three
different dropdowns. One is a string to type in, the other involves
tabbing or moving the mouse to select the different dates. Depending on
the range of dates available that can be quite an inconvenience. The text
field allows for errors, true, that is why popup calendars for high level
environments are the most clever way of dealing with it.

The only argument I heard in favour of selects I heard so far is that it
is harder for scripts to simulate these entries, and therefore harder to
spoof a real user signing up for something.

More information about the thelist mailing list