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