JavaWoman considers…

Apart from the fact that practice has shown a simple, constant question can protect for a very long time all by itself (most spam scripts are very dumb), the form's spam protection is not as simple as a single anti-spam question: have a look at the source of the demo page and you can see there are other anti-spam measures in place as well. A spambot would need to know how to handle all of those, and when finally one does get through, all you need to do is change one of the elements.

Besides which, it's just source so you can extend to your heart's content (so long as you don't claim it's all yours); like adding in a little randomness - a random field name for instance can be very effective and not hard to implement with a little knowledge of PHP. No support if you change anything (of course), so you're on your own there.

Use Captcha questions - in text - only because as soon as you use a picture, the form is no longer accessible! Captcha images are not accessible for people with visual problems (not even if a sound alternative would be given, because there are people who are both blind and deaf - in which case a "call us" alternative is equally inaccessible).

The very reason I blogged about this form is not only that it's very flexible and has good anti-spam support, but is user-friendly regardless (read what it does when the Captcha isn't answered correctly!) and remains completely accessible.

Nobody gets "slapped" by accessibility - and you said yourself it's a lovely form! But if you make it inaccessible by using a graphical Captcha of some sort (or leaving out all the other accessibility features of this form) a lot of people will get inconvenienced at least, or not be able to use it at all at worst - so why would you want to do that?

Of course, there are people who can't read, not so many who can't read at all, but dyslexics have trouble reading in various gradations - but they can use screen reader software as well (there are free programs for that now), so they will hear the prompts. Many can write (never mind spelling mistakes), and will be able to copy-and-paste their email address for instance, and thus still be able to use a contact form. Except when they are confronted with a Captcha image, because a screen reader can do nothing with that.

If they speak a very rare language (and none the form supports) - then would they even land at your site and try to use a contact form?

Accessibility is not about optimizing for 1%, and forgetting the rest, it's about being as all-inclusive as possible, and not forgetting those 15% or so who need some aspect of accessibility (certainly not only 1%). And it's not hard to do if you know what to do. And get a lovely form as a result: this form script "knows" what to do already. Use the form as is, and even someone who is blind and deaf can use it, and you won't get floods of spam. So why do work to exclude those people when with no work at all you can include them?

And those who care about Google ranking - tell them that Google is blind. If you write accessibile pages, they will not only tend to be more usable as well, but search engines can "use" them better, too.

You can have it all, nice design, Google ranking, no spam, cool effects, and be accessible as well.

As to Netscape3 - no problem, any browser without CSS support will work; they can use a text browser and still be able to use this form. That is another aspect of the accessibility of this form: accessibility is about being all-inclusive (as much as possible), and that's not just people with handicaps, its also people with any browser.

Try the demo with lynx, links, or if you don't have those (you should have at least one of them), try it with the lynx viewer.

And you may want to check out my other posts relating to accessibility - more developer tools!

@Mike: Thanks for jumping in!

I found the backup you provide for those who don't know the answer to the anti-spam question very clever: rather than posing a very hard question and thus testing the "intelligence" of your readers, a simple question will do, and those who are human but don't understand the question or its intention - maybe because the language they're reading the form in is not their primary language - are not excluded immediately and get another chance. There has been a lot of discussion about whether such security questions could not themselves exclude people, but this is a very good solution for that. But bots don't come back, they just shoot off a form submission and are gone, they generally don't hang around to see if there was an error.

Meanwhile, I tried out the new WAVE toolbar on your demo form, and it spotted two (small) problems: a case of too much of a good thing. There are two locations on the form with two label elements for a single ID, and that's not valid. I'm not sure whether that would hinder usage of the form in practice, but worth mentioning, and easily fixed.