Easy Form Validation alternative to Captcha

[whatachamp]

Hello,
I like to put some sort of validation on my contact forms, I have used recaptcha and a math question in the past with no problems.
I am now building a site for which the client's service is helping people with literacy and learning difficulties. While its most likely its their carers that will be visiting the site, I would like to make my form as easy to use as possible, while still having the form validation on there.
Any suggestions? I like the idea of the switch you have to toggle before sending the form but I'm not sure how effective that is.
Thanks

[ralph.m]

What you could do is just have a hidden field (a "honeypot") which causes the form to be aborted if filled in. If you set it to display: none, I gather most screen readers won't see it. In any case, you can include a message not to fill in the form if you wish, or a simple instruction like enter "4" here ... but most people are never going to see the field anyway.

This way, you don't trouble legitimate users but trip up the spam bots. The only fish through the net will be individual spammers, but they are relatively few.

[whatachamp]

Thanks Ralph, I have never heard of doing that before. I'll give it a go because it definitely sounds like what I need.

[Mat30]

Ralph, don't you find that most (perhaps all, I'm not sure) of the ATs that have form modes ignore display none when in that mode, so that all form elements get announced? NVDA and, I think, Orca did that when I tried them.

[ralph.m]

Ralph, don't you find that most (perhaps all, I'm not sure) of the ATs that have form modes ignore display none when in that mode, so that all form elements get announced? NVDA and, I think, Orca did that when I tried them.

I'll defer to your judgement and experience on that. I heard a long time ago that screen readers etc. tend to ignore elements set to display: none, but I have a sneaking sense that may not be the case for form elements, but I'm ignorant, I'm afraid! I used to have a label for the hidden input that said "don't fill in this field!" or similar, but changed to giving a simple instruction, like "type 4 here" ... and the form aborts if the field is not empty and does not contain either "4" or "four". (If someone types "for", I'm happy for the form to abort. )

[Mat30]

Yeah, I've just dug out a note that I wrote for myself ages ago and, although my list is far from complete, I got as far as checking Orca, NVDA, and VO (the free ones, funnily enough!). Orca and NVDA read out form inputs with display none, while VO continued as normal and ignored them. The 1st two also handled visibility hidden in the same way, I think.

[Mat30]

Anyway, about the main question. I often use a text-based question, among a series of measures (mostly unobtrusive server-side things and absolutely no horrible image-based tests). A question might be "type the last three letters of orange". It should be fairly understandable for most users and has only two possible answers.... Whatever you ask, always make it as clear as you can and always allow some latitude in the processing. The other measures can include things like unique tokens (if you run a database), a time check to prevent very rapid form submission, and similar tricks that the PHP gurus could tell you much more about.

[Stomme poes]

Ralph, don't you find that most (perhaps all, I'm not sure) of the ATs that have form modes ignore display none when in that mode, so that all form elements get announced? NVDA and, I think, Orca did that when I tried them.

Form controls are often exceptions to that rule (yeah, JAWS too). http://juicystudio.com/article/scree...splay-none.php For this reason, the honeypots WILL have a label that states what the user should do when they come to that field. Similar to Javascript honeypots: assume everyone without JS enabled is seeing that label-input pair.

"type the last three letters of orange"

Okay.
"ornch"
So last three letters are "nch". Your form validation should accept that. You should see the spelling on the Orca mailing list. People who learned to read while sighted spell pretty well, but esp those who learned English after going blind or born blind, the spelling is awful, even though the ability to go through a word letter by letter to see how it's spelt is possible. Either ask how to spell very basic, obvious words, or better yet, do simple math. That gets you out of the language hole.

"How much do I have if I add 3 and 2?"
accept 5, 05, five...

[Belsnickle]

I'm not sure if you're saying it will or should be set to because, at least in php, you can limit it to an exact match.

[Mat30]

Arithmetic questions wouldn't always be possible, though. For instance, if you have to work with a module that can accept only one answer (with case variations allowed), a word is a safer choice than a number. Far from ideal, I know, but real-world restrictions abound.

Thanks for mentioning the spelling issue, though, because I didn't know that. Never seen it come up anywhere.

[Mat30]

Stomme poes, I've been thinking of alternatives to word-based answers that would work in the situation that I mentioned above. Would something like "Enter the number thirtysix using digits" be more accessible? Or should it be simpler still?

[Belsnickle]

I don't know that you'd need to visibility hide it, just shift the absolute position of the honeypot item off top. Same basic effect I'd think. Unless there's some scripted spam bot issue with this I'm unaware of since I've never tried using it to stop them before.

[Stomme poes]

Mat30: I just mean it shouldn't require thinking to answer. Esp if it's like most other forms, the good ones ask for the usual stuff and we know all users get stupid just magically by sitting behind a computer and filling out a form.

Mike Cherim had a (visible) honeypot that asked "is fire hot or cold?" and accepted "hot" as the answer. It did not accept misspellings of "hot" but I believe it was case insensitive. I think he also had Askimet there too.

Fronteers.nl has signup or comment forms with a field that is hidden with Javascript, so I believe Javascript automatically fills in the answer ("nee"). Without Javascript, as I usually am, I see the field which asks something like "Are you a spammer?" and the hint on the other side of the field says "fill in no" (this is all in Dutch of course). First time I saw that I thought the hint said "don't fill in" so I left it blank and didn't get through :)


I had a client getting gobbledygook bots going through filling everything in with lskdfkjshgkjhads and I added an invisible field that the back-end script would filter out if it was filled in, while the label said "leave this field blank, spam question". Not sure how good of an idea that was, since people are trained to fill in things, but it stopped all the gobblespam.

Off Topic:

mattur?

I don't know that you'd need to visibility hide it,

The reason I tend to hide them is, the fewer humans who see that field, the less likely I'll get someone screwing it up. Since if I'm using CSS to hide it, I've limited the users who might see it to text-browser users and screen readers, mostly. And bots of course. Then I have the label to tell those humans left how to deal with the form.

So the real solution a honeypot offers is, bots don't read. People read, and so do Mechanical Turks and human spammers, but bots generally don't. It's just that, as a confusing question, I'd prefer fewer humans see it if I can hide it.

I do prefer CSS solutions to Javascript ones, unless like the Fronteers example above, they have a good fall-back. You certainly don't want people with script blockers getting kicked out as bots, and with a good honeypot there's no reason to.

[Belsnickle]

I was actually just suggesting adjusting the absolute position(so it doesn't effect the browser screen) to a point off of the screen instead of using visibility and was wondering if the bots in question are set up to ignore that too. Here's some sample code for that type of thing in-line CSS style(not that it should or need be, this is just the example I have readily available from usage on a wiki):

<div style="position: absolute; width:180px; height:75px; z-index:3; left: -220px; top: -95px; visibility: visible"></div>

[Stomme poes]

I was actually just suggesting adjusting the absolute position(so it doesn't effect the browser screen) to a point off of the screen instead of using visibility and was wondering if the bots in question are set up to ignore that too.

When I asked (on Accessify or somewhere) why display: none and visibility: hidden elements were ignored by (most) screen readers, the answer I got was something like "the browser doesn't add those elements to its rendering layer and so the screen reader software considers those elements not on the screen, therefore not copying them to the virtual buffer" or something.

However, absolutely-positioned-offscreen elements are treated like non-positioned onscreen elements (read out).

Though there have been bugs (like older Window-Eyes versions used to announce abso-po'd elements who were brought "above" the page with top: -9999px, then announce those things again when it got to where the element was in source), in general screen readers ignore CSS*. However, they are interacting with the web page through a browser, and a browser loads and renders CSS, and a browser loads and runs scripts. A screen reader gets information actually via the browser (through an accessibility layer).

* Another example: some browsers (like Firefox) when they remove bullets because you have "list-style: none" will actually not tell the screen readers using them that there are any bullets/numbers on that list, and so bullets and numbers won't be read out. So CSS can affect screen readers, in small, buggy ways. Another example: sometimes readers like JAWS would consider tables to not be tables if they were set to something other than display: table.

Bots on the other hand are usually wholly separate user agents, like wget, who don't load (or at least don't parse and render) the CSS or scripts. They just read the HTML and react to that. You can absolutely-position the whole page offscreen if you want. Won't stop a bot.

I've heard there are bots out there who do load and run Javascript, just very few in number.