Yep, we're assuming spambots fill out any/all text fields they can find, 
so any submission that has a value in that field is discarded. 

Ideally this method comes with some kind of graceful failure message, so 
that if you're dealing with a human, that person won't be tearing their 
hair out wondering where their submission went. In the case of our 
implementation (2-question anonymous feedback form) it's a risk we're 
willing to take.

--
Erin White
Web Applications Developer, VCU Libraries
804-827-3552 | [log in to unmask] | http://library.vcu.edu/




From:   Jonathan Rochkind <[log in to unmask]>
To:     Code for Libraries <[log in to unmask]>
Cc:     Erin R White/FS/VCU <[log in to unmask]>
Date:   10/24/2011 10:50 AM
Subject:        Re: [CODE4LIB] web spam block less awful than Captcha?



Is there a particular label you give it that causes spambots to fill it 
out, or you find that spambots stick some text in any <input 
type="text"> you include?

On 10/24/2011 10:46 AM, Erin R White/FS/VCU wrote:
> I'll second Dre's method here. We've used it with great success on our
> mobile website - it adds zero effort for users and we've had maybe one
> false positive since March 2010.
>
> The field is input type="text" with CSS hiding it and its label from
> display. From my extensive googling it like as of JAWS 10 (released 
2009),
> elements hidden by CSS aren't read, but I'm not sure about support from
> other readers. I'm assuming some kind of "skip" mechanism will be built 
in
> to WAI-ARIA too.
>
> <label for="spam_city" class="hidden">Spam catcher - do not complete 
this
> field</label>
> <input type="text" name="spam_city" class="hidden" />
>
> --
> Erin White
> Web Applications Developer, VCU Libraries
> 804-827-3552 | [log in to unmask] | http://library.vcu.edu/
>
>
>
>
> From:   Ken Irwin<[log in to unmask]>
> To:     [log in to unmask]
> Date:   10/24/2011 10:35 AM
> Subject:        Re: [CODE4LIB] web spam block less awful than Captcha?
> Sent by:        Code for Libraries<[log in to unmask]>
>
>
>
> This is an intriguing approach, Dre. I wonder how to render this
> non-problematic for folks with screen-readers too. You could just say
> "leave this field blank" but that's sort of weird too. Is there a 
WAI-ARIA
> approach that would get screen readers to hide this field too?
>
> I'm looking into Mollom too -- looks like that could work in a few areas
> of our site.
>
> Thanks all!
> Ken
>
> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
> Andreas Orphanides
> Sent: Monday, October 24, 2011 10:13 AM
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] web spam block less awful than Captcha?
>
>
> Here's a method that's by no means foolproof but is practically zero 
cost
> (you may be using a version already). Disclaimer -- I have not actually
> tested this to any extent:
>
> Include a text input field in your form that needs to be blank for the
> form to validate in the back end. Keep the field hidden with CSS (or
> z-indexed behind another element, size set to zero, etc). Users will 
never
> see it, so their forms will validate; I doubt that most spambots are
> sophisticated enough to check whether a form field is hidden or 
obfuscated
> before filling it in. Then silently reject submissions with that field
> filled.
>
> I am not sure whether this would cause any problems with tab navigation,
> screen readers or other assistive technologies, but you may be able to 
do
> something to sidestep those issues.... On the other hand, captcha brings
> its own host of accessibility problems.
>
> One other disadvantage is that this might be hard to implement in a
> CMS-based form plugin. But if you're coding forms the old-fashioned way,
> it's worth a shot.
>
> -dre.
>
>
>