 |
 |
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. > > >