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