 |
 |
In addition to the methods mentioned here which I've had good experiences with, another thing that can be effective is simply checking the fields for inappropriate content. For example, bots love to try to insert links, raw HTML, things that belong in mail headers, etc. On the off chance that a human had a reason for including such content, you can tell them why their input wasn't accepted so there's no risk of a legit communication silently disappearing and they can still get help. Captcha is effective, but it sucks from the user end. I screw those up a huge percentage of the time, and can't believe I'm the only one with that problem. kyle On Mon, Oct 24, 2011 at 8:15 AM, Ken Irwin <[log in to unmask]> wrote: > Using Dre and Erin's method, I've got a fix in place. It caught two spams > in the first 10 minutes! > > I named the field <text name="confirm_email"> to see if I can trick it into > knowing exactly what to fill in. I just realized that I didn't echo the > results of that field in my notification of the possible spam; I'm going to > catch it from now on and see if that trick seems to work on them. > > It's good to hear that JAWS is respecting the "display: none" now; I'm > going to check with my usability posse and see if there are any other tricks > to know here... > > Ken > > -----Original Message----- > From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of > Jonathan Rochkind > Sent: Monday, October 24, 2011 10:50 AM > To: [log in to unmask] > 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. > > > > > > > -- ---------------------------------------------------------- Kyle Banerjee Digital Services Program Manager Orbis Cascade Alliance [log in to unmask] / 503.877.9773